So much has been written on SOA that this blog entry apparently is redundant and futile. However I feel compelled to pen down my thoughts on this subject matter as I want to objectively critique my current views some years down the line.
The stance on SOA in the software industry and its practitioners is quite diverse. On one end of the pendulum there are people who treat SOA as nothing more than a mere buzzword. On the other end there are people who believe that SOA is the means to achieve agility of software shops thereby enabling them to keep pace with dynamically changing business requirements. The reason for this polarization of opinions in my mind is the lack of a clear definition of SOA in the industry.
What is SOA? Many people have tried to define it and still many will. Let me approach it from a different perspective. Let me first try to define what SOA is not.
SOA is not just web services. Just as Java is one of many languages which allow us to realize the principles of Object Orientated Programming, web services provide us with one of many mechanisms to realize a Service Oriented Architecture.
SOA is also not a set of expensive toolsets bloating up our IT budgets. It is not just edge devices or routers or communication channels or Enterprise Service Bus implementations or a repository of service artifacts.
SOA is not an alias for WSDL or XML. Nor is SOA tied to a specific communication(read HTTP) or messaging (read SOAP) protocols.
In the words of the famous fictional sleuth Sherlock Holmes, “when you have eliminated the impossible, whatever remains, however improbable, must be the truth”. So now that I’ve laid down what SOA is not, the definition of what SOA is should be simple right? It is infact so. SOA is just what the abbreviation expands out to be – it is an architecture pattern oriented around services.
Well that’s simple isn’t it? Yes but you might ask what do you mean be “services”? I define it in this context as a reusable software component which acts as building blocks for fulfilling end users use cases(or stories). And SOA is an architectural pattern based on these components. If we start seeing services as they should be seen – merely reusable software components then I think SOA can better marketed to its sceptics.
My appeal to SOA advocates and SOA haters alike is this – let’s not get bogged down with “implementation details” of SOA and keep an open mind around the basic problem areas this architecture pattern attempts to solve. That will lead to a more pragmatic and less buzzword driven adoption of SOA.
In the industry, quite often we meet people who think SOA is about implementing a bunch of web services and wiring them together they even go to the extent of using web services in all the tiers / layers of an application. I completely disagree on this.
ReplyDeleteI do agree on your point of view that SOA is an architectural pattern and we need to pick the right implementation tools and technologies for the problem in hand, it could be as simple as writing a Plain Java based reusable component.
As you rightly called out, SOA is an architectural pattern for building reusable software component.
Based on what both of you are saying, a Java application with re-usable components follows SOA? In what way or at what level is SOA different from functional and object-oriented programming?
ReplyDeleteI think the primary objective of SOA is to break down an organisation's business functions into atomic transactions or services and then orchestrate them to rebuild its entire business process.
For example, in a component architecture World, you would have a function called "createQuote" which would create a quote based on a customer's information.
But in the SOA World, you would have to break "createQuote" down further into its component steps such as "validate License #", "process credit card payment", "calculate premium for a vehicle and a coverage" etc.
Of these, you would re-use "validate license #" in the "add driver" business function by re-orchestrating it there.
Am I right?
Indradeep, Let me try to break down your questions and analogies and make an attempt to answer/address them.
ReplyDeleteQ."Based on what both of you are saying, a Java application with re-usable components follows SOA".
A. I would say yes.
Q. In what way or at what level is SOA different from functional and object-oriented programming?
A. SOA is an architectural pattern whereas programming languages are a means to to achieve an architectural pattern. A pattern can be achieved in any programming language e.g. MVC is an architectural pattern. It can be achieved through Ruby or Java. the language doesn't matter.
Statement: I think the primary objective of SOA is to break down an organization's business functions into atomic transactions or services and then orchestrate them to rebuild its entire business process.
Comment: I agree 100%. However the point to note would be how to build the atomic services achieve the orchestration. A "service" as per me can be POJO based,SOAP/HTTP based, ReST Based, RMI based, Hessian based etc. On the other hand the orchestration can as simple as a Service Facade Bean or it can be a Business Process which in turn is exposed as a web service using WS-BPEL. These alternatives and choices are implementation details which will be guided by several factors. But these implementation details should not the core of SOA. The main point that we should be striving for is to identify the core reusable blocks and the business processes for an organization. Once that is achieved the decision of the following factors need to be taken (not an exhaustive list):
1. What transport protocol(s) need to be supported for the service?
2. What messaging protocol(s)need to be used for the service?
3. How to manage multiple versions of the service?
4. How to enable consumers to locate released services.
5. How to administer the services?
6. how to secure the services.