When I started to think about writing this month's column I looked on the Internet for a good way to define service-oriented architecture (SOA). Some of the definitions were interesting, like "A Service Oriented Architecture is basically a Collection of Services" (www.service-architecture.com/). Others were a little bit more technical, such as "SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents" (www.xml.com). The definitions varied considerably, and often included notes that SOA is not a new concept, things like DCE and CORBA had implemented them years (or even decades) earlier.

I wasn't able to come up with one concise definition of service-oriented architecture, and that's probably okay. A single definition would likely be too narrow and restrict its usefulness. But both of the definitions I quoted above seem to hit significant aspects of this type of architecture. A service-oriented architecture is a collection of services, with a service fitting the very loose definition of "something that does a significant unit of work." That unit of work can be a business-related process, like adding a customer or taking an order, or it could be a support-related process, such as processing user login or keeping track of audit information. Services can rely on one another; they can be built on one another (that's the concept of interacting software agents from the second definition); and really the main requirement for a service is that its interface be easy to use (this is where Web services comes in) and that it be well defined (this is where architectural skill and best practices come in).

Service-oriented architecture is lauded as "the next big thing" in today's IT world - a second coming of a concept that should have freed applications from duplication of effort and lead to IT nirvana. While SOA is a worthy concept in many places, it does have some issues.

Implicit in SOA is the concept that services are shared. For example, rather than have each application build its own security module, a common, shared security service is built. In practice, this is easier said than done, especially when you are trying to abstract business processes rather than support processes. Often there are differences in processes between organizational groups, and of course that doesn't take into account the political hot potato of "who owns the service." Often, SOA requires not just a change in application design, but a change in who funds, manages, and owns services as well. The technical challenges are minor compared to getting buy-in from business and other organizations that have a stake in how technology is used. Even assuming consensus among organizations, differences in business processes can make it impossible to present a single service, even when conceptually the service is identical. Some of this may be mitigated by the adoption of a business process engine that can work behind the scenes of a service to allow customization of process. Or it can be hard-coded into the service implementation in some fashion, although such approaches typically become spaghetti code rather quickly.

Another challenge is the loose coupling that is implicit with an SOA. While this is not a bad thing, and in fact has many benefits, it also has certain drawbacks when creating an application. UI developers, especially those within a corporate firewall who work with thick-client tools, are accustomed to closer integration to data than services provide. If a VB developer is to work with a Web service instead of a database, he loses all his familiar methods of dealing with tabular data sets via the common ODBC mechanisms. This can definitely impact productivity, and even to a certain extent affect the way services are designed, as things like filtering drop-down lists based on screen choices (select a state for example, and the list of counties next to it is populated and filtered with those of that particular state), which used to be performed via database queries, now have to invoke a service. In practice, this makes service invocations much more chatty and fine grained than what is usually envisioned by proponents of SOA. In a thick client, some of this can be handled by more logic on the client (which is usually something that architects are trying to get away from), but in a thin client it has to be handled somewhere on a server.

This month's focus is service-oriented architecture. It's the next new thing, but it's not nirvana. Make sure you understand the drawbacks as well as advantages when you decide to go to this brave new world.