Service Oriented Architecture
Over the last few years the acronym SOA, or Service Oriented Architecture as it stands for, has been a popular buzzword used by many people in the industry. But SOA has turned out to be much more than a buzzword and many companies are now exploring the opportunities for implementing Service Orientation (SO) in their organization.
Let’s take a look at services and examine what a service really is. For example, I recently applied for a renewal of my driving license from the Swedish Road Administration (SRA). The SRA’s whole procedure for handling this can be said to be a service. The service, in this case, being to process my application and then based on various (and for me, hidden) facts and procedures, they either issue me a new license or reject my application. I don’t need to bother about how the SRA processed my information or which routines they followed internally to process my application. In this case, my application is a request to a service which SRA exposes and its answer (whether a new license or a rejection) is the response to my request. A service in itself is no mystery. Think of it as something that encapsulates a business process or an information area in your business.
CBDI (http://www.cbdiforum.com/) comes rather close to our own definition of Service Orientation (SO), when they describe SOA as “the policies, practices, and frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published, and discovered, and are abstracted away from the implementation using a single, standards-based form of interface.” In short, we might say that SOA is the approach and that web services are only one of the implementations of SOA. Let’s see if you agree with this definition after having read the book. A lot of people, however, do think they have an SOA perspective just because they use web services. In some cases this might be true, but often theses services are not Service Oriented (SO), but rather only expose capabilities that live up to the requirements of the protocols used by the web services.
Why has SOA had such a massive impact on IT Architecture during these last few years? Almost everywhere you go you hear this acronym; at conferences, seminars, on web sites, and in news group discussions. Microsoft has also clearly shown their support for SOA, especially with their Windows Communication Foundation (formerly known as Indigo) effort.
Don Box (no introduction necessary I hope?) said it well when he claimed that even though we stretched the technologies as far as we could for distributed objects, it turned out that it didn’t quite cover everything and that we’d need something else. (This is not a direct quote, but the heart of the message is in there.) Sten Sundblad, of Sundblad & Sundblad, also agrees that this probably is why SOA seems to be springing up everywhere.
This doesn’t mean that our enterprise applications will be constructed purely by gathering services from various places, at least not for the time being. But, as you might have understood from our previous discussion about EAI and enterprises, today we most definitely use services from external sources a lot.
This still doesn’t mean we will, or should, stop building “traditional” enterprise applications that are tightly coupled within themselves—far from it. But you should keep in mind when building enterprises that in the near future you will benefit from having a service perspective when doing the architecture and design of such applications. Just remember that implementing SOA in your company means that the whole company IT strategy needs to be changed. It is not intended for single applications, so it is quite a big step to take.
The topic is so important that we have dedicated an entire chapter to SOA in this second edition of our book. In the first edition we tried to emphasize the importance of having Service Oriented thinking, but we did not use the term Service Oriented Architecture.
Before we close the discussion of SOA for now, let’s take a look at the qualities that a service should posses. Being familiar with these guidelines will help you during your exploration of the book. Sten Sundblad co-author of “Designing for Scalability with Microsoft Windows DNA” and also co-creator of Sundblad & Sundblad in Sweden (both with his son Per) describes it very well, as always, in the Swedish document “Service Oriented Architecture—An Overview” (translated from the Swedish). Unfortunately, this document is only available in Swedish, but makes a good argument for both learning Swedish as well as learning SOA. The following is what he says a service should be:
- Have a message-based interface.
- Have its own logic, which encapsulates and protects its own data.
- Clearly separated from and loosely coupled to its surrounding environment.
- Share its schema with its consumers—not with its class.
David Sprott and Lawrence Wilks of CBDI say in the article “Understanding Service-Oriented Architecture” available at http://msdn.microsoft.com, that services should have the following characteristics. Note that these go rather well with what Sten Sundblad says.
- Reusable: A reuse of service, not reuse by copying code or implementation.
- Abstracted: Service is abstracted from the implementation.
- Published: Precise, published specification of the functionality of the service interface, not implementation.
- Formal: Formal contract between endpoints places obligations on provider and consumer.
- Relevant: Functionality presented consisting of a granularity recognized by the user as a meaningful service.
At that time, we’ll also go over Don Box’s four tenets for designing services, and how his ideas fit into the scope of Sundblad, Sprott, and Wilks. Keep the definitions and characteristics we just covered in the back of your mind while reading this. It might be a good inspiration for when you start thinking about your own applications and what you can do with them.