Why most of what I read about service-oriented architecture annoys me - Part 2

The term, service-oriented architecture refers to somehow incorporating services into the design of an application. I say, somehow because there is currently no consensus on how services ought to be used in truly service-oriented solution.

Everyone would probably agree on the ideal service-oriented architecture, which was described by Guy Loewy in an excellent article called, The Integrated Services Environment, which appeared in the April 2002 issue of EAI Journal. That architecture is shown on this slide. It depicts a new application being composed from services exposed by several existing applications. That vision is the one that is causing all of the excitement about service-oriented architecture: the vision of large enterprises with data and algorithms currently isolated within a variety of existing solutions, called silos, being able to deliver new value to their customers by coordinating those algorithms and stores of data into new applications that reach into the silos through service interfaces.

Well, the service-oriented architecture depicted in that scenario is fine if one is the chief information officer of a large enterprise with a lot of legacy stuff and a board that is growing increasingly suspicious of new information technology ventures. Yet, what does service-oriented architecture mean for the rest of us? What does it mean for someone developing a new application for a new organization, where there are no existing silos of logic and data? What does it mean for software vendors whose products may or may not be deployed in environments where there are a number of applications that need to be working together?

Does it just mean that we should all be sure to slap a service interface on the outside of the software we build just in case someone should want to plug our software into something else?

A quite different view is that a truly service-oriented solution would use services to communicate across any boundary between the layers of one’s application, that services are the finest technology for implementing layers within one’s application and should be used as such. This radical view was expressed at the recent Microsoft Professional Developers’ Conference by Don Box, one of the authors of the SOAP specification and currently an architect on Microsoft’s Indigo Project. Indigo is indeed intended to be a general-purpose infrastructure for software entities to communicate with one another via services.

Between these two extreme views of service-oriented architecture is the one that I find to be presented most often, which is the view that a service-oriented architecture exposes the domain layer via a service interface. That is the view espoused in the book, Application Architecture for .NET: Designing Applications and Services, which is among the publications of Microsoft’s Prescriptive Architecture Group. The same conception of service-oriented architecture is put forward by Randy Stafford in the book, Patterns of Enterprise Application Architecture, the principal author of which is Martin Fowler. The propagation of this view is unfortunate, because it is misleading.

Let us say that you are building a Web application. Such applications tend to do a disproportionate amount of processing on the server-side, because of the limited facilities of Web browsers on the client side. So, throughput on the server-side is at a premium and most architects of Web applications would find it wasteful to have requests from the presentation layer marshaled through a service interface when they could be marshaled more efficiently via a component interface, although Indigo might make that feasible when it debuts.

Windows applications have different constraints, however. Typical line-of-business Windows applications share access to remote data stores, and having them access the data in those stores via Web services is an elegant solution. More importantly, it is not as impractical a solution as it is in the case of a Web application, because the superior capabilities of Windows clients compared to Web browsers means that some of the work of the application can be offloaded from the server onto the clients, leaving cycles available on the server to accommodate marshaling requests and responses through service interfaces.

So, while I think one generally would not want to expose the domain layer of an application through a service interface in the case of a Web application, I think is wise to do so in the case of Windows application. More importantly, though, I don’t think that service-oriented architecture is really about exposing the domain layer of an application through a service interface.

I think a better description of a service-oriented architecture is described by Roger Sessions in his book, Software Fortresses: Modeling Enterprise Architectures. According to that account, there are boundaries of trust around every store of data, like the walls of a fortress, and points of access to a data store are like the drawbridges of the fortress, and services are used to provide the drawbridge between one fortress and another. For an applications own interfaces, one would deploy the most expedient drawbridge, which, in the case of a Web application would likely be a component interface and in the case of Windows application, might well be a services interface.

While I am mostly enamored of Sessions’ approach, there is one modification that I think is important to make, which unfortunately breaks the metaphor of fortresses and drawbridges somewhat. I think that, indeed, there are boundaries of trust around every store of data, and I think that it is true that service interfaces should be in place on the trust boundaries to facilitate communication across them. However, I think that applications, including Web applications may often be considered as being within a given boundary of trust. Think of it this way: if it is my store of data, and it is my application, and my application authenticates its users (which it may do by having them authenticated by a source that I trust) and is accessing my own data store, then I trust that application and it can use the most expedient interfaces.

This model provides the fundamental tools for a service-oriented analysis of any given set of requirements . . .