How Teams Build Services

With all this talk of software factories, it's important that we understand the different ways teams will use them to build services. I talk to a lot of customers and, of course, there are several different approaches a team might choose. I hope this post will be informative, but hopefully, the comments will also identify new approaches and/or confirm the ones below.

When building a solution that involves distributed services, there are a number of things the team must build: the service interface (operations and their messages), the business logic (domain model entities and processing logic), the data access layer, the proxy/service agent that consumes the service, and the client that uses the proxy/service agent. There are also several roles in the team that perform various tasks: the solution architect, the domain expert, and the developers. I understand there is often a fine line between a solution architect and a lead developer - give me some slack here :)

In every case I've seen, the team building the client application is also the team that is building the proxy/service agent. However, that's often not the case when it comes to the service interface and the business logic. There are various approaches the architect and developers might make when building the service side (they may or may not be building the consumer(s) of the service). More often than not, the architect will define what the service interface looks like and the dev team will implement the interface. The Service Factory enables at least 2 major scenarios:

1. Solution architect provides a baseline. This baseline is an executable, foundational starting point for the service that the dev team will build upon. Among other things, this baseline will include the service's operations and their messages, message exchange patterns, and possibly selected areas of risk that cross-cut all operations (i.e. instrumentation, security, exception management, etc). It's likely the factory will be used to build this baseline and the dev team will continue to use this (or a different) factory to build out the rest of the implementation based on the requirements set forth by the domain expert. This approach is common when there is a smaller team responsible for the services and a different team is responsible for the business logic.
2. Solution architect provides a factory. The factory being used (i.e. Service Factory) is modified by the solution architect to include the practices and patterns that have been identified by the organization (naming conventions, framework components, cross-cutting concerns, etc) and it is deployed to the dev team. The dev team will then use the factory to build the service's interfaces and the implementation (and all layers of the application). This approach is common when the same team is building the service and its implementation.

I suspect there are variations of these and I think they would be interesting. Think about how your team builds services today. Are you happy with how the team is structured (does it work)? Are you using some form of code/config generation? Are you building baselines or a factory today and have a sense of the best way it should be used in your team(s).

Since this post was geared toward teams, I didn't talk about the single individual who is building the whole solution. I know this is also a very common scenario and, of course, factories can still be a great productivity booster and a means to provide a lot of consistency in the services being built.

If you're building Web services and you're not familiar with Service Factory, whew ... you have some catching up to do ... and just in time. Patterns & practices should be releasing to MSDN by the end of the month. Let me know if you have questions or comments?

Comments

• Anonymous
  July 17, 2006
  The comment has been removed
• Anonymous
  July 18, 2006
  Hey James, this is an excellent response. I agree with your statements about the responsibility of the solution architect and the scope of the factory in an organization. This is comforting since one of the companies I was thinking about when I wrote this was the organization you work for ;)
  
  This isn't the first time I've had customers tell me of the difficulty in decompsing the business requirements into a set of service contracts. The best example I've seen of this so far is chapter 7 of the Integration Patterns book. Here is a link: http://msdn.microsoft.com/practices/guidetype/Guides/default.aspx?pull=/library/en-us/dnpag/html/intpatt-ch07.asp. I also suspect Microsoft (either the p&p team or the architecture strategy team) will be publishing more about this on the future.
  
  About the choice of bindings, we have some prototype ideas that I think are VERY promising in the WCF Security guidance package. You may remember it ... it's the "Configure Interoperability" recipe where you choose the target platform. Right now it's just focused on conpliance with WS-Security specifications, but it would be easy enough to extend.
  
  Thanks again!