I've been struggling for a few weeks to perfect an elevator speech on what service-orientation is, and I think I'm starting to get close. Here goes...
Fundamentally, service-orientation represents the drive to reduce functional services to their most basic core. It's about abstracting away concerns about location, transport, programming language, and any unimportant details that aren't related to the real function the service carries out. Just as importantly, service-orientation is also about going out of your way to be interoperable. This usually means providing services in XML, which generally anyone can consume or provide.
Service-oriented models also have special intrinsic qualities which nurture the value of service-orientation. These might include a routing-centric view instead of an RPC-view, or the ability to annotate messages in a standardized way without changing them (SOAP), or layering orthogonal properties like secure or reliable operation into the service contract (WS-*). And that's what a service is, after all, a contract between a client and a supplier to carry out an exchange of information in a pre-agreed upon way. It's fair to say that service-orientation represents a very evolved and modern view for exchanging information amongst heterogenous entities.
Web services, SOAs, enterprise service buses (ESBs), SOAP, and REST all deal with the issue of service-orientation in different ways and using different methods, but they are all after the same thing: rich, dynamic interoperability. And like Keenan Newton says, SOAs do not equal web services: Despite huge advances in our shared understanding of how to create great services, we can't forget they can also still be provided by the most poorly service-oriented means imaginable. This is actually the norm today. And it's what you get if you try to build services using tools and approaches that don't understand what effective service-orientation is, which we, as an industry hadn't figured out until recently.
As most of us know, services can be provided in the crudest, most obfuscated, and tightly-coupled way and still be called a service. For example, an ungainly C++ .DLL with interfaces exposed by ghastly mangled names can certainly be considered to offer services to clients, but not in a particularly attractive or useful way. This means services can easily be services, but not be service-oriented.
Figure 1: The elements of service-orientation
Jon Udell has been
considering the definition of services lately, specifically in light of Roger Session's most recent definitions about what constitutes a service ("services cross process and environment boundaries") and how to build applications with them. Frankly, I suspect they have gone too far in genericizing the meaning of services and not appreciating the full concept of service-orientation, though their definitions are technically correct. An effective SOA is built out of services that are specifically service-oriented, meaning that they are well-documented, open, and described with a contract. SOA-friendly services are about the message and the message structure, completely apart from protocol, location, or other local idioms. I think this is the piece that SOA proponents too often forget or neglect to emphasize and which service-oriented environments like Indigo seem to fully realize,
though the jury may still be out.So, you can certainly build SOAs out of non-service-oriented services, but it will be brutal and hard and you will squander your time on interoperability. And not achieving the potential that SOAs have to offer. Sessions is correct though when he says that SOAs are architectures of intermediation, this is a phrase I think I really like, and that service-orientation delivers.
So service-orientation should be how you get basic service dial-tone in your architecture. Achieve service-orientation and you can spend the time after that reaping the promise of SOA: constructing rich environments of composite services and applications out of a vast galaxy of interoperating entities, operating transparently. In short, spending quality time with your service model will give you fairly rapid access to the real potential of SOAs including orchestration, dynamic composition of processes, monitoring, management, and most importantly, interoperability and integration with services other than your own.
Technorati: Enterprise Architecture, Computers and Internet, Programming