In this episode, I get to define SOA, instantly coming into conflict with just about everyone who has ever defined it :). Right. Onward.
First and foremost, Service-Oriented Architecture is an architectural style, not a framework. It's a design model, it's a way of thinking. I like to say it's not something you can buy or run a wizard for. I would also say that it is a Design model with a very strong emphasis on encapsulating application logic within Services that interact via a common communications protocol.
Then there is the business aspect of SOA which I think is extremely important and relevant to the definition. I said, back here, some of this which I will repeat, " any definition of SOA must encompass the business drivers and business reasons, as SOA is not really about technology. It is about a better alignment of business and IT through business processes and services. The goal is to create a dynamic, more Agile and Dynamic IT that can respond quickly to new business opportunities and threats by quickly assembling new capabilities from putting together composite applications (and even Mash-ups) from reusable business services.
Heck, people have been arguing about this definition for years, including me.
I like this definition [1]
"SOA establishes an architectural model that aims to embrace the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing." (emphasis mine)
It sounds like Thomas Erl's definition sounds more like mine. Then there is this definition:
"Service Oriented Architecture (SOA) is an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications" [2]
Or this one:
SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications. [3]
I guess it comes down to what I discussed with Michele Bustamente when we were working on her WCF book: Little SOA versus Big SOA (sometimes known as Enterprise SOA). It came down to the Little SOA definition being Arnon's architectural style while the Big SOA definition puts things in a broader sense of IT and the overall enterprise. You know which one I prefer. I like SOA being described not only in architectural terms bit in terms of the strategic goals, business aspects and creating business services. That's when I believe SOA offers tremendous value. If one blindly follows the Little SOA side and cleanly separates interface from implementation and comes out with a nicely factored set of services that don't model the business then so what? I have seen a lot of people do this and emerge with just a worse performing version of DCOM or CORBA or RMI. The business aspect has to be a first-class citizen of what we are doing. We do want to this to fit into a "SOA Initiative" that is "about a better alignment of business and IT through business processes and services. The goal is to create a dynamic, more Agile and Dynamic IT that can respond quickly to new business opportunities and threats by quickly assembling new capabilities from putting together composite applications (and even Mash-ups) from reusable business services. "
I have no great urge to argue further about the definition. In that regard, we'll let the folks at OASIS settle it, who, in August 2006, have finally come up with a "standard definition:"
“Service Oriented Architecture (SOA) is a
paradigm for organizing and utilizing distributed
capabilities that may be under the control of
different ownership domains.” [4]
SOA relies on ability to access chunks of business functionality that can be owned by different groups, companies, etc. They also state,
"In general, entities (people and organizations) offer capabilities and act as service providers. Those with needs who make use of services are referred to as service consumers. The service
description allows prospective consumers to decide if the service is suitable for their current needs and establishes whether a consumer satisfies any requirements of the service provider." [4]
One other point I need to make is that Web Services are but one possible framework to build SOA applications. Indigo is a framework too, not an "SOA" It can be used to build SOAs if you have the mind set and the architecture a certain way. SOA is not new. It has been around in frameworks like CORBA and COM to name but two. The difference now, is that the use of interoperable Internet and Web Service standards have been able to finally deliver on many of the promises of SOA, especially interoperability.
I was going to talk about the Four Tenets of SOA but we'll do that next time, along with a current discussion on whether to retire them.
[1] Erl, Thomas (2008). SOA: Principles of Service Design. Upper Saddle River. Prentice Hall. ISBN: 0-13-234482-3
[2] ^ Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0.
[3] ^ a b c Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
[4] OASIS Reference Model for Service Oriented Architecture, Committee Specification 1, 2 August 2006 http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf
Contents
ReBlogger Contents
Email TopXML