Services (part 1 of many)

I not been blogging much lately because I have felt like what I have been working on is just not blog-worthy. We "outsource" most of our infrastructure services to an internal division; which was recently turned over to a large outsourcing firm. So I have been spending much of my time "training" the folks who I interact with on a near daily basis to do what I need them to do. As it turned out this was not a trivial task. And that's all I have to say about that. :-)

I am beginning to look at building out some data services. In the Investment Management business data is king; especially market data. What I am learning (or should I say re-learning or feeling pain around) is that without the data in place the service is nearly useless. So my project is really turning into data project where I am bringing in and reconciling market data vendor feeds. Oh yeah and by the way I am exposing them as a service.

Which has me questioning myself; why a service in the first place? I just want to make sure I am actually providing real value and not just overhead. I think the key reason for a service here is provide a single well define abstraction of the backend. We have so much market data and so many sources of market data; that providing a flexible abstraction makes sense. My expectation is that we will be consuming this data right from Excel (the universal financial application platform) as well as many of our custom applications.

I remember presentations back in the mid-90’s when I was a Microsoft and we were listening to the early internal presentations on Microsoft Transaction Server (MTS) by Pat Helland and James Utzschneider. They were talking about MTS interception and how you can accomplish cool things when you can get in the middle. That is exactly what we are trying to do. Once we get the abstraction of the data, we can begin to do some cool things.

My biggest concern about building a service is performance. In past lives when I have built services I would always warn people that if you need fast performance then web services you should think long and hard about not using web services. Of course there are ways that you can “cache” data outside of the service, but now you start to run into the dirty cache problem. I want to go back and read Pat Helland’s fiefdoms articles from a bunch of years ago to get my head back into this problem space. I recall Roger Sessions also doing some similar work based on Pat’s original article.

Next decision is what Framework bits to use; WebMethod (.NET 2.0) or WCF (.NET 3.0)? I know .NET 2.0 pretty well; so I feel confident I can get something done fairly quickly on those bits. But why do something on the “legacy” asmx platform? Why not just bite the learning curve now? I assume the interop between the two just works; so if I wanted to the service to be in WCF and the client to be either that would be OK.

I was just noticed the bottom the page (I write this in Word first) coming up. And I didn’t think I had anything to write about...