SOA is often rated in surveys as being the number one initiative that CIOs plan on undertaking going forward. A number of vendors offer software tools to help "SOA-enable" existing IT applications or build new "SOA-based" applications. So what exactly is SOA? While there doesn't seem to be a universally accepted definition of SOA, there are two things that have generally come to be associated with SOA - Web Services and Business Process Management (BPM).
Read Separation of Church and State
I feel that the topic of separation of state and behavior is a little misleading.
Separation of state and behavior should be dealt with carefully. Encapsulation requires that the behavior be hidden behind an interface. Pure object oriented domain objects not only represent state (data), but also behavior.
It is necessary to identify the configurable business rules to separate them rather than saying state and behavior should be separated as a rule for SOA.
Here's a news flash, OO is just a tool, not a religion. Sometimes (often) it is not the best tool for a problem. Even if you are using Java, you are certainly not required to do everything in the most-OO way possible.
Allen Holub pointed out years ago that Mode-View-Control breaks OO by separating model and view. In a strict OO design, a model would be able to create its own view. Forcing a secondary object to do it requires the secondary object to know way too much about the model's internal structure.
That explains the drop in popularity in MVC, right? Oh wait, there's been no such drop in popularity. The reason is that MVC solves the real-world problem of developing user interfaces extremely well. It lets different people with different specialties and skill sets work on different parts (model and view) of the same problem. It's a great engineering solution, regardless of OO.
Same thing with SOA. The pure OO domain objects you speak of work great, for a single system. They don't work as well for loosely coupled distributed systems.
You missed the point.
"You should carefully choose the configurable business rules and externalize them."
Even in MVC, the model objects still encapsulate behavior. You separate the control logic in MVC and put it in the Controller. In the same way you need identify what should be externalized in the SOA environment.
Today's single system may become tomorrow's distributed application. So, separating state from behavior is not completely feasible in SOA environment; nor it is always recommended. Thinking every piece of the business logic can be made configurable is a myth.
An article appeared in DB2 Magazine (q4, 2006) says
"For example, when most people hear the term SOA, they automatically think Web services. There is a lot more to SOA than Web services, however. ..
First of all, SOA is an architectural style, not a technology. You implement an SOA architecture using technology, but too many people get lost looking for some product or technology right off the bat when SOA is primarily about a thought process. Truthfully, SOA could have been more aptly named ‘Save Our Architecture’ because its benefit is a free flow of business process data, both vertically and horizontally, from the enterprise to your supply chain and throughout your value net. "
This is all hogwash talk. A new 'thing' (we still don't what that 'thing' is!) is introduced as a panacea to solve all problems, and from day 1 and square 1, the proponents themselves complains that the rest of us have misunderstood the 'thing'!
The above article goes on to say that IBM's SOA-ized or SOA-enabled products are Rational, Tivoli, WEbsphere etc!
The author of the article concluded with "Underpinning all of these life cycle stages is governance, which provides guidance and oversight for the SOA project. This information allows IT to better align the infrastructure by defining and redefining information management rules and policies."
The more one rads about SOA from different sources, the more convinced one is that it is nothing but a marketing gimmick!
Recently I was fortunate enough to attend a Java Meeting where a couple of presentations were on SOA, as expected.
One of them put the Goals of SOA / Composite Application as
• Separation of Business Concerns into Services
• Orchestrate reusable services
Most often with BPEL and expressed in BPMN
• Include Business People in the design process
Process level, BPMN, should be understandable by both
Business and IT
• Composite Applications are a mixture of “Business
Services” and “Technical Services
Business: Home Loan Process, Customer Service, etc
Technical: Logging Service, Caching Service, Authorisation Service, etc
Another one was on Apache Tuscany - Building SOA Solutions With The Service Component Architecture. An essential characteristic of SOA is the ability to assemble new and existing services to create brand new application that may consist of different technologies. Service Component Architecture (SCA) defines a 'simple' service-based model for construction, assembly and deployment of services (existing and new ones).
SCA programming model is highly extensible and is language-neutral. SCA can easily be extended to work with multiple implementation types including Java, C++, BPEL, PHP, Spring,...
multiple bindings including Webservice, JMS, EJB, JSON RPC, ...
multiple hosting environments such as Tomcat, Jetty, Geronimo, OSGI,..
Is there anything new here, other than a lot of buzzwords and newly defined SCA as if the definition of SOA were not enough? The introduction of SCA helps the vendors to avoid any questions on the base concept SOA and its contradictory definitions and implementations. … Recall that DB2 Magazine earliet put it You implement SOA using technology
. Now what we see is SOA is being implemented using yet another architecture – SCA! If this continues the way it is going, we will end up in many more ‘architecture asteroids’ under the ‘solar system’ of SOA.
Th introduction of new buzzwords and ‘architectures’ to justify the base buzzword SOA, reminded me of a passage from Mahatma Gandhi’s autobiography. Gandhi attempted to become a perefect Englishman while he was a law student in London during 1890s. Here is the interesting chapter from the autobiography of MK Gandhi ‘The Story of My Experiments with Truth’ … slightly edited for brevity here.
PLAYING THE ENGLISH GENTLEMAN
I undertook the all too impossible task of becoming an English gentleman . The clothes after the Bombay cut that I was wearing were, I thought unsuitable for English society, and I got new ones at the Army and Navy stores. I also went in for a chimney-pot hat costing nineteen shillings an excessive price in those days. Not content with this, I wasted ten pounds on an evening suit made in Bond Street, the centre of fashionable life in London; and got my good and noble-hearted brother to send me a double watch-chain of gold. It was not correct to wear a ready-made tie and I learnt the art of tying one for myself.
As if all this were not enough to make me look the thing, I directed my attention to other details that were supposed to go towards the making of an English gentleman. I was told it was necessary for me to take lessons in dancing, French and elocution. French was not only the language of neighbouring France, but it was the lingua franca of the Continent over which I had a desire to travel. I decided to take dancing lessons at a class and paid down £ 3 as fees for a term. …..
The recluse in the fable kept a cat to keep off the rats, and then a cow to feed the cat with milk, and a man to keep the cow and so on. My ambitions also grew like the family of the recluse. I thought I should learn to play the violin in order to cultivate an ear for Western music. So I invested £3 in a violin and something more in fees. I sought a third teacher to give me lessons in elocution and paid him a preliminary fee of a guinea. He recommended Bell's Standard Elocutionist as the text-book, which I purchased. And I began with a speech of Pitt's.
But Mr. Bell rang the bell of alarm in my ear and I awoke.
I had not to spend a lifetime in England, I said to myself. What then was the use of learning elocution? And how could dancing make a gentleman of me? The violin I could learn even in India. I was a student and ought to go on with my studies. I should qualify myself to join the Inns of Court. If my character made a gentleman of me, so much the better. Otherwise I should forego the ambition.
I believe we need a Bell's book here too to stop this bizzare wastage on SOA!
It appears from the web that SOA hype is much older than even I had imagined. One web entry says
SOA: Shame on analysts
2005 Will Be the Year of SOA -- Are You Ready? (.NET Developer's Journal)
2004: The year of the SOA? (ZapThink, searchwebservices.com)
Predicts 2003: SOA Comes of Age via Web Services (Gartner)
Bowstreet Predicts 2002 Will Be The 'Year of Web Services' (Bowstreet press release)
So the thing started as early as 2002! And now in 2007 fall we are still wondering where we should go with SOA!
The big non-news for the last week of October was the demise of the Oracle attempt to atke over BEA.. The fusion which both wanted to call did not materialize...And some news analysts were shouting
"Oracle/BEA fusion would rock SOA vendor landscape"..
What has this to do with SOA? Or rather what has SOA to do with Oracle acquiring BEA? A lot of bla bla buzzwords have been vomited by industry analysts...
Bottom line is that Oracle needs to stop BEA... and BEA needs to perform and meet the ever increasing challenge from Websphere... and even other open source application servers...
These are pure sales issues and nothing to do with any architecture!
Since the last entry many things have happened... Oracle did indeed pocket BEA! And not surprisingly BEA Webpgae now claims "WebLogic Server — the foundation for SOA
Learn why WebLogic Server is the bedrock for building and deploying services in support of SOA. "!
With virtually no competition in the field, Oracle and its products have an easy time, almost like Kenyans running a 10.000 meter race! But the comparsion stops there. Kenyans have the stuff, whereas Oracle doesn't have!
Time is ripe for any company or individual to come up with a substitute for all the vapourware - including the xyz databases, application servers, platforms and even Java!
As late as Jan 2008, the financial companies were boasting about huge economic growth worldwide...(while already in July 2007, house prices were slipping in San Fransisco...noticed by a few in Palo Alto, but ignored by the rest of the world!). Well now, on 28th September the Iceland based Glitnir bank even sponsored the Oslo Marathon and had been running huge advertisements the previus week. By next week, the bank had collapsed taking the country along!!!
Software, software companies and analysts like GG, jump to take credit when everything is going alright. But hide into their holes when things go wrong! Financial experts advise others on how to manage their money! But who will advise these experts? Huge multi billion dollar companies collapsed...Industry experts were forced to commit suicides from New York to Bombay!
Utterly third rate ideas like SOA too played a role in the financial collapse. Because companies were investing on huge software projects without getting nothing in return! Not even a "Java NULL"! Unlike laymen like you and me, comapnies don't make software for fun! Software is to run their business. So if the business failed, then the software did have a role in that failure!
Unless the software industry stops playing with buzzwords like SOA, we are going to have more spectacular failures!
PS: My kindergarten son was asking why SOX Compliant Auditing did not predict / foresee the financial black hole coming? I had to reply: I don't what SOX is, son!
Let me continue here:
An article has appeared on Investing in SOA in a down economy! see at http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1334292,00.html
Quote from the article "So, you're probably thinking, now's the time to pull up the stakes and cancel your ongoing investment in SOA and related IT efforts. After all, why bother investing in something as future-looking as SOA when you can't even afford to keep the lights on? Right? Wrong."
A real investment should work in prosperiy as well in adversity. In fact, if SOA were real, it should have saved the client, now and in future! We have several examples from 1980s where IT clients stayed with some proven products and solutions, and avoided financial collapse!! But read on:
Another quote " Stop multi-year SOA efforts. Focus on iterative, process-driven SOA efforts
The business is only partially to blame for the continuous cycle of enterprise architecture non-investment. The blame lies equally with the IT organization. IT departments have inappropriately approached SOA efforts are (sic should we read as?) Web services integration projects and bought infrastructure before they figured out which services to build, and before they figured out which problems to solve. Even worse, many IT departments approach SOA as a solution in search of a problem, without crafting a business justification or proving to the business that SOA can work to solve a small problem before throwing in millions of dollars of investment to unsuitably address a large one. Many vendors are equally to blame, pushing their "SOA" products down the throats of customers without ensuring that their customers will even be successful with SOA initiatives, and often misrepresenting the capabilities of their products in the process. "
Wonderful! So why did the new concept got misunderstood in the industry? Multi-layer efforts? non-investment? Business, IT depts, wrong approach? web services? throwing millions of dollars without knowing what one is doing??? Lastly vendors pushing products down the throat of customers??
The last one sums up the whole thing about SOA! ie Vendors pushing products down the throat of customers and choke them!
"SOA has thus come to be associated primarily with integration of systems. But what if I am building a new application that has little to do with integration? Say I'm building a Business Intelligence (BI) tool for analyzing and reporting on data from a data warehouse and have no requirement to integrate any legacy systems, expose any Web Services, or provide any BPEL processes. Is SOA relevant in the design of such a system? Would I apply any SOA principles in architecting this application? Would it make sense to say that my new system's architecture is SOA-based? The answer to all of these questions is "Yes"."
The first sentence is correct IMO. The rest is frankly rubbish. What possible reason might one have to invoke a web service within one's own application?
1) Using SOAP interfaces and employing a SOA framework (e.g. an ESB) where none is needed imposes a large processing overhead that will reduce performance, possibly by orders of magnitude.
2) SOAP interfaces are much more difficult to change than Java interfaces. Say I want to change a GWT RPC method by adding an additional parameter. I simply select the method in the RPC interface in my Java IDE, select "refactor" which updates the asynch interface and the implementation automatically, and edit the code in the RPC service implementation to use the new parameter. Job done. Try doing
that sort of thing with a SOAP interface.
Against this the author puts up the (IMO extremely weak) argument that a SOAP interface + SOA infrastructure "is keeping the mode of provisioning of a service separate and independent". What on earth does he mean by that? He cannot mean the SOAP service itself because a SOAP service is a SOAP service is a SOAP service.
I think what he means is simply that "SOA infrastructure" takes care of tracking which physical server the service runs on which boils down to its IP address or DNS name plus the SOAP service call details. Big deal. Remember, the service client still has to call the "SOA infrastructure", so it will need its address, the call protocol details etc to do so anyway.....
So what's to gain doing this within your own application?
After 2 years, I see that Microsoft has gone ahead with their version of SOA! A book on Microsoft WCF says
loosely coupled and interoperable set of
Also the book says
On SOA being a collection of servcies, the same book contradict by saying >
In the end the book palys around xml, xsd, wsdl,SOAP, UDDI, html, messaging. .NET. COM, DCOM and so on...
Basically MS tries to prove that WCF and .NET are all you need to implement their version of SOA
I'm afraid you have missed the mark on this. Within an enterprise, SOA is the ability to create or mine chunks of business functionality wrapped with an API that allows a variety of applications to access that functionality through various transport mechanisms. While BI is an important and relevant topic, as is Web Services, they do not have anything inherently to do with SOA.
There is no doubt that a service must be stateless, and deal with data-only objects in communication with the outside world. Indeed, if your service is a web-service, you can't send anything but data. But this does not imply, or should not imply on how the service is implemented inside. If the service itself is just a façade (which I definitely think it should be), and delegates tasks to rich domain objects (which is not mandatory, they could delegate tasks to BusinessObjects too, for those who like it), it's none of the business of the service's clients. In case you're not dealing with XML data for client-service communication, you would then need a TransferObject for this communication. No big deal about it.
Anyway, what I'm trying to say is that you don't need to vertically apply the same design choices down to the data level. That is what coding to the interface and exposing services is all about.
i second that. Thats why we have TransferObjects in the J2EE Designpattern catalog.
SOA should really not be used to make all the old stuff new. It is no news at all. And it brings no fundamental new concepts, designs architectures. Just a new way to bring sense to the business people to start thinking the way distributed apps will be implemented anyway.
More than a decade ago IBM announced AD/Cycle and SAA - System Application Architecture. There were a few vendors who joined IBM as the co-sponsors. Soon these vendors and their products melted like thin ice and no one ever figured out what SAA was. Some analysts said SAA died even fore it was born.
SOA is the buzzword coined by som clever marketing guy when he didn't have much to do. Clevely it addressed business guys (so called managers) rather than technicians. Technically there is nothing other than what existed and what can exist without the buzzword SOA.
Are Web Services and BPMs SOA? Businesses and business processes existed all along. Dataprocessing was indeed (and still is ) processing business neeeds using the power of the machine.
SOA 's definition vastly varies and contradict each other. Some vendors are using it to brainwash and influence the CIOs.
One doesn't have to be an IT expert to predict that SOA will soon be dumped into dustbin of history. Nothing can exist without at least some content and truth. It's not even old wine in the new bottle. It's a new bottle with no wine at all!!
You said, "SOA is the buzzword coined by som clever marketing guy when he didn't have much to do. Clevely it addressed business guys (so called managers) rather than technicians. Technically there is nothing other than what existed and what can exist without the buzzword SOA."
I will disagree with you on that. SOA has gone beyond a buzzword. If you want to see SOA in action visit http://www.housingmaps.com
/ . Housingmaps.com uses SOA services from Google and Craigslist to creat its portal site.
Thanks. housingmaps.com seem to be based on Google Maps.. But I could not see what this has to do with SOA!
I think you are right saying:
Technically there is nothing other than what existed and what can exist without the buzzword SOA.
And because enterprise scale systems are big $$$, you are probably right when saying:
some vendors are using it to brainwash and influence the CIOs.
But I disagree with the conclusion.
SOA is a little bit just like a design pattern.
It incorporates old and good ideas into a set of principles that solves a real world problem. The problem of the enterprise architect – how to build and maintain enterprise scale apps in a way that will give value throughout a long period of time.
You wrote "It incorporates old and good ideas into a set of principles that solves a real world problem. The problem of the enterprise architect – how to build and maintain enterprise scale apps in a way that will give value throughout a long period of time." Is there a well-defined methodoloy how to integrate such systems, other than wonderful powerpoint presentations?
There is nothing new here. Dataprocessing has been always real world problems. We started with single user batch-file (master file, transaction files) processing, went on to databases when many people were able to look at data at the same time. Datasharing was a big pluspoint of database systems compared to files. This helped the traditional online (OLTP) systems and online query systems.
Client-server model proposed by the new vendors/technologies did not give the expected result. Demise of the old systems were predicted but never happened. Web came and changed the whole picture once again. Platforms and terminologies and even languages changed. Java took a big leap after 2000.
Back to SOA
Even on this thread there is no agreement on what SOA is! Are webservices SOA? no one knows.
Every book and article on SOA starts with the question 'SOA what?' IBM-sponsored book says 'SOA is a new approach to building IT systems...that easily enable the changes' ...
Such claims are always necessary to sell. "Easily accommodate changes, easy to maintain, easy to integrate, cost saving" etc etc. All new technologies and approaches claimed such things and only less than 10% met these claims.
When a concept is clear it is not difficult to explain it. And we need only one consistent definition. The greatest theory - Relativity - is cleanly explianed by many in 1-2 pages! Even a layman can understand what is E=mc2 or the concept that time slows down as the speed approaches that of light! And the explanations are not contradictory.
But our new wonderful SOA - we have a thousand definitions! Most of them contradict each other!! The book on my table 'SOA for Dummies' has a paragraph 'foolish assumptions'... There it says 'you are an IT person who knows a lot...but this SOA stuff is new and everybody says it's something different...Once and for all, you want the whole picture" That says it all. Everybody says it's something different!!!
Most demos come with huge diagrams and buzzwords. The inability of the presenter to explain what SOA is evident everywhere. One place, when questioned, one said 'well, our company define it this way and we go ahead with that!"
Author notes that loose coupling is a central SOA concept, but then makes a leap to suggesting that Java interfaces are an example of loose coupling. Not so. Interfaces only hide implementation. Other central SOA concepts are that services must be coarse grained and self describing. Java interfaces are fine grained specifications of result and parameter types and order. A coarse grained interface is defined by something like WSDL. Service contracts are quite different from "coding to contract" which is about tightly typed interfaces.
The common assumption that Web Services equate to and SOA architecture is a mistake. Web Services are the EXTERNAL service end points of an SOA arhitecture. The author notes that the real value of an SOA architecture is for INTERNAL service based integration of cross system functionality. SOAP and Http is a high overhead low performance way to tie together back end systems (which don't necessarily have Servlet front ends anyway).
A WSDL does not always imply a coarse grained interface either. I can still choose to expose a WSDL portType/interface that has operations with discrete message parts (parameters)and as the consumer you still have to send in right data types in the right order. Exposing a Java interface forces a certain technology choice on your consumer whereas with WSDL that restriction is not there - that's technology coupling and has nothing to do with granularity of the service interface per se.
you're absolutely right.
At VHV insurance ( Germany ) we've just creating a SOA on top of a z/OS ( ... COBOL/CICS/DB2-based business-logic ... )
Service consumers like GUIs ( Spring/Webflow ), process-engines ( IBM-WPS ) or any other propieraty systems use the exposed services the same way ( e.g. MQ-based ) and it has definitely nothing to do with WS ( -technology ).
The backbone of our SOA is a z/OS-based service-manager,
supported by MQ, CTG ( CICS TX Gateway ) and SOAP (for CICS) and a JAVA/OS-based service-manager ( for interoperability reasons..)
Consider WS when a synchronized communication-style is necessary, otherwise prefer loosely-coupled communication like JMS/MQ...
My contradiction: WS-technology is not imperative to service-endpoints... it's just an option.
Coarse grained vs. fine grained is definetly a battleground on its own. It depends on the particular business-requiremens.