[Service Factory] How the Service Factory Guys Think

Don Smith put a video up on the Service Factory Codeplex site about how they think about services, where they believe Service Factory is today and where they are heading. I thought the message about the different types of services was quite interesting because it is close to the way we're thinking when we're identifying service components for an enterprise. Note that the type of (web) services you may create as part of a specific solution because it may help you scale out, tier and get better availability and so on is something different to me. I'm more thinking of enterprise class services here.

Don mentions 3 types of services; Entity/Capability, Utility/Messaging and Process/Activity.

The first one is easy to understand and I think that's where most organisations start on their SOA roadmap. An Entity Service is usually very simple and may represent one or more business entities with data stored in a database or perhaps wrapped within a (legacy) system. You often se CRUD-like interfaces on these, but I recommend you to try and stay away from too granular methods. If you have an entity service for say a Person or a Customer, consider to not expose methods to get just the phone number or the email address, but rather get a complete Person or Customer object. These objects could be based on well known XML Schemas owned by perhaps information architecture group or something.

The second type of services I usually call "Infrastructure Services" and are typically Security Token Services (STS), message routers and such. Could also be metadata/taxonomy/ontology services to help out with information integration cross services and systems. If anyone was using UDDI, I think it could also be placed in this category ;) Having said that, I think this category of services are very, important. It's hard to maintain and govern enterprise class services without an STS and a proper service catalogue. Not sure I understand their view on "Message" in this type of services. "Simple" Message routing services based perhaps on ws-addressing and such could be placed here, but more complex message handling, perhaps handled by a workflow engine, I think would go into the third and final category of services...

...called Activity and/or Process Services, which usually (for us anyway) contains methods and interfaces that map to scenarios, use cases, routines/functions (depending on which methodology and terms you're using). Also good for long running processes which may involve message queues, perhaps BizTalk and Windows Workflow Foundation. These services most often use other services, like Entity Services, to orchestrate and aggregate data needed by service consumers. They may not have their own database like Entity Services, unless you need to save state for a workflow or to keep replicated and denormalized data for aggregated search or perhaps masterdata for partitioned entities. See the Entity Aggregation pattern for a detailed description. One could argue that services that implement the this pattern should go into the first category of services, but I usually put them into the Activity Service category anyway, for reasons I'll probably blog about some other time (it's getting late).

I'm happy to hear about where the Service Factory team is heading, to have better support for Utility/Messaging (Infrastructure) Services and move into support for Activity/Process Services. I wish there were some good guidance for activity and process services already. I'm quite interested in seeing what this team will do with LINQ in the near future. I'm not too fond of the data access code in current Data Access Guidance Package.

Anyway, go check out the video, it's short and the sound is a bit so, so, but it's a good message.