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 (2)
  1. James Speer says:

    Interesting post Don:-)  I think the essence of your post here is that different team members have a different perspective of the tasks that need to be completed to build services.  IMHO I think the Solution Architect is responsible for both the baseline & the factory.  But I also think that the factory originates at the organisation level to a high degree because choosing an accelerator like Service Factory is likely to be a strategic decision that applies to several projects making up a one or more programmes.

    But…Before you get this far I think "the team" needs to answer some big questions before you can right click and select "Service Factory" though…

    In my experience one of the most difficult tasks is actually deciding how many services you need and what the rolesresponsibilities of each of the services is.  In other words – you’re not taking a statement of requirements and turning it into a service or two – you’re looking at the bigger picture; the enterprise and the overall vision for the organisation and trying to distil that into services each with very clear roles and responsibilities.  Over time I think we will see proven patterns to accomplish this.

    I think the Service Factory does an excellent job once you’ve got to the point of identifying the services you’re going to build btw.

    The other challenge which is related to P&P is choosing appropriate bindings for the platforms you’re going to integrate with – whilst WS-RM et al look very appealing for Indigo->Indigo scenarios you need to know a bit about your service consumer to keep the bar as low as possible.  You also need to think about message exchange patterns and sync vs. async – especially when the service consumer could be some kind of web site.

    I’m looking forward to the day when the lessons learned from these situations are reflected as patterns & practices in the toolset.

  2. LockSmithDon says:

    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!

Comments are closed.

Skip to main content