Editor's Note

A Service-Oriented Editor's Note

Howard Dierking

The term "service" has come to mean many different things to different people. We have seen software characterized as a service or as something that requires services in addition to the main product. Within our applications, we have domain services and externally facing services. We call our user interface "presentation services" and our data access code "data services." And one of the more recent architectural trends is to plan for and implement service-oriented architectures.

While services and distributed applications are related, they are not equivalent. Most services, particularly those built on a framework like ASP.NET or Windows Communication Foundation (WCF), naturally lend themselves to distribution across the network. Conversely, distributed applications are best understood and maintained when they are composed from services. That said, distributed applications are a technical solution for solving problems such as scale, whereas services are more semantic in nature and exist as a way to decompose and manage the complexity of systems.

The question of services is something that I continue to grapple with in my own journey as a developer as it seems to require a paradigm shift in the way that I translate business domain concepts into technology artifacts. I have spent a great deal of energy thinking about and developing my skills in topics like object-oriented heuristics and design patterns. An idea that is generally accepted within this school of thought is that of the rich domain model. This is a class model that is very closely bound to the language of business, is independently testable without needing a user interface or database, and that encapsulates all of the operations that are required to address the problems of its business domain. To this day, I start all of my development work with two projects: a domain model class library and a domain model tests class library.

Initially, to enable services in my work, I simply decorated my domain classes with serialization attributes and sent them out over the wire via an ASP.NET or WCF service. Then I realized that this created unintentional side effects, as the public data interface of my domain objects made an implicit assumption about the logic behind the contract—and this became apparent only when testing based on the generated service proxies. As a result, I changed my approach to use a data container object, also known as a data transfer object (DTO), for passing the data across my service boundaries. This worked pretty well for a while as the semantics of my domain layer and the way that I created applications didn't really have to change all that much.

Then came Windows Workflow Foundation—and about the same time, I also started dabbling in Office Business Application (OBA) development. Add data warehousing along with a couple of other technologies to the equation and that brings us to today—and gives you a framework for how I'm trying to define services in the context of my development efforts. Now I am dealing with questions like how logic is factored between my workflow instances and my domain classes and how I can unit test my workflow services in a test-driven fashion.

I mention my own journey here because I imagine that many of you have had similar experiences in understanding how services fit into your applications and processes. If you have insights on how you have dealt with the challenge of service orientation in your work, please write and tell us about it!

Finally, I want to welcome Mike Calligaro and the Windows Mobile team to MSDN Magazine and introduce their new column "Going Places," focusing on all things mobile. As we continue to service-enable systems, those systems can reach far beyond the traditional network boundary, and Mike and his team will show us how to best leverage those capabilities on all sorts of platforms.

Thanks to the following Microsoft technical experts for their help with this issue: Tim Cahill, Barak Cohen, Alex DeJarnatt, Steve Fox, Matt Gibbs, Scott Hunter, Albert Kooiman, Steve Maine, Faisal Mohamood, Laurence Moroney, Mark Rideout, Stefan Schackow, Don Smith, Ed Triou, and Robert Wlodarczyk.