At the TheServerSide Java Symposium last week, Gregor Hohpe, co-author of the book Enterprise Integration Patterns, gave a presentation that downplayed the hype around service-oriented architecture (SOA) and provided a refreshing explanation of what the term really means. He argued that architecture should be based on patterns and intent, not technology selection.

Hohpe suggested some "alternative" meanings for SOA such as: same old architecture, some other architecture, SOAP without the P and stupid over-hyped acronym. His point was that the term SOA is overused and advised the audience to not look for one proper formula.

The main characteristic of an SOA is that of a loosely coupled, document-oriented interaction model, according to Hohpe. He didn't think that SOA is a new, life-changing architecture because XML messaging-based services have been around for a while.

Read Is SOA really just the same old architecture?

TheServerSide.NET also had a related (and heated) discussion recently:
Is SOA Really The Future or Just So Much Hype?.

Yeah.. I never really understood the hype around SOA. When the hype first began I thought, "Hasn't everyone been doing this for years?" - maybe not with the same transmission protocol or document formats, but still effectively the same old architecture.

The great amount of hype actually caused me to put in the time to read a number of articles on SOA in order to figure out "what's different?", but alas, I never found anything uniquely interesting.

SOA is nothing but powerpoint and posturing. From what I can tell it is a collection of ideas, none of them new.

you guys need to wake up and smell the coffee...the world no longer revolves strictly around Java API's

Well, maybe there's a "new standard", but my point was that there's nothing to justify all the hype, and so many people talking about SOA as if its a revolutionary idea, when in fact it is a very recycled idea.

I've been building various document exchange architectures for many years before the term SOA came around, including using protocols such as ebXML and all kinds of XML and non XML document format standards and non standards. And this in no way has made me think that "the world revolves around Java APIs", nor has it made me feel I was doing anything "ahead of the curve" - as even when I began doing that type of work I recognized that the ideas were recycled.

There's really been very few new things under the sun in the field of computer science for many, many years now. Ideas just pass in and out as fads... which is too bad because most of them (including SOA) have their place, but the hype that surrounds the ideas during the times they come "in style" cause them to be misused in places another idea's solution would be better suited.

you chain together SOAP intermediaries to acccomplish much of what you used to develop in the infrastructure...if you guys don't think that's new you're nuts

you chain together SOAP intermediaries to acccomplish much of what you used to develop in the infrastructure...if you guys don't think that's new you're nuts

SOA is not about SOAP, or any other protocol, product or technology for that matter either, it is a set of patterns and an architectural approach that reaches for some sort of higher level of reusability beyond your regular OO patterns.

The way I see it, SOA is indeed nothing new, but a rehash of old (but good) ideas that have been reshaped into a coherent and succint vision where ther has been none before. SOA is just something that has always been good practices in many instances of development, but very rarely been formulated well enough so that less experienced and skilled developers have been able to consistently follow these practices.

You also have to keep in mind, as SOA is not a protocol or product, it can exist on different levels of "SOA:ness", you might have a rudimentary "SOA" with coarse-grained services, or you might anything else all the way to dynamic service discovery with services that orchestrate processes and preserve process integrity.

So in summary of my opinion of SOA: nothing new, just formulated in a more succint and good way + someone at the marketing department accidentally heard the whole thing and thought "hey..".

... exactly.

SOA doesn't give me any "reusable infrastructure". It simply gives me an architectural pattern... which happens to be one I had already been using for many years.

As Wille posted here, the only thing new is that the architectural ideas are bundled up in a handy package of books that you can read.

It's basically like the design patterns fad of 5 years ago - none of the patterns in the GoF book were new, but what was new was the formal presentation of the ideas. Most poeple who read the famous GoF book ended up with an opinion like: "Oh yeah, I've done these things forever, but didn't they organsize, name and describe the ideas so nicely?".

SOA doesn't give me any "reusable infrastructure". It simply gives me an architectural pattern...

I wouldn't agree with you completely there, there are probably elements of an SOA that could be made into a reusable software infrastructure ("Plumbing" like service-discovery, service configuration and basic API:s) that can do some hand-holding for developers to follow the patterns and practices, however, whether what you build on top of that in terms of service-implementations can be called an SOA will come down to how well you manage to follow the architectural patterns and practices.
In my opinion the "SOA:ness" with regards to actual business value is not in the plumbing/infrastructure, but in the actual service implementations and how useful, reusable and well-defined they are.

there are probably elements of an SOA that could be made into a reusable software infrastructure

There are some great ones already, and will be TONS in the near future...why?...because the single best way to manage development complexity is to not develop high-level functions that can be relegated to infrastrucutre. That is why there has been such uptake for SOA and why standards are so important...and why the premise of this thread is so silly...

there are probably elements of an SOA that could be made into a reusable software infrastructure

There are some great ones already, and will be TONS in the near future...

Not disagreeing with you, the use of the word "probably" was due to "over-diplomacy", I tend to not outright disagree with people that disagree with me in order to ease them into my way of thinking. ;)

Also, I think whether or not you see the supporting infrastructure as SOA or a big portion of an SOA is probably down to philosophical semantics more than actual differences in the views of what reality will look like.
I tend to fall on the side of the fence saying: "well of course the software infrastructure is part of the SOA".

But then again, a failed "hack"-solution on top of the infrastructure might undermine the "SOA:ness" completely.

Of course I agree with you and the general trend of posting in this thread. There's little new about the kind of component-oriented architecture enabled in 'SOA' and the diagrams look a lot like the old high-level CORBA PowerPoints ;-)

Ont thing I cannot understand is why people talk about 'documents' in this context. No 'documents' are being exchanged. Strings go back and forth ... that's all. This bugs me a little bit, possible because it reminds me of the Microsoft 'document-view architecture' from MFC, and possibly because it tends to make some managers think that Web Services is about sending HTML 'documents' ('pages') back and forth. Another reason is that of course there ARE document management systems and technologies, which are totally different animals.

Anyway, possibly a worthless rant, but there it is. Too much marketing-speak in our world anyway ... (no offense intended to you, James, of course)

I guess it all depends on what you mean by "document".

I was using the term in the sense that pretty much any xml file (or just about any other payload file) is a document. In this sense, a document basically represents a portion of a transaction, be it a "request for info", a "purchase order", a "confirmation", an "ack", a "stock quote", or whatever. In my book all of those messages are documents that are being transmitted as services are being provided from one system to another. From my experience, programmers have been using the term "document" in this sense for decades (for example, look at the old EDI X12 specs) - this has nothing to do with marketers.

I guess it all depends on what you mean by "document".

Document is a term with specific meaning in SOAP, e.g. doc/literal versus RPC style SOAP.

SOA doesn't give me any "reusable infrastructure". It simply gives me an architectural pattern...

I think this misses the whole point...this is about standards, interoperability, and extremely broad industry support...just look at the TC members for WS-Security, for exmaple...IBM, BEA, SUN, Oracle, Microsoft, SAP...yeah...this is marginal stuff.

At least TSS

The goals of SOA are just the needs of corporate IT. This doesn't speak to what SOA is nor how the idea of SOA evolved. My vision of the evolution of SOA is to take an object-oriented computer program and to pull it apart. As a matter-of-fact, pull the elements of the program so far apart that these elements now live on different computers hosted by different companies. For this to occur, the elements of the program will have to become severely decoupled. The highly decoupled functionality is easy to envision as functional design. This evolution is greatly facilitated by XML. The use of XML allows the various elements of the highly decoupled and distributed computer program to be platform, programming language, and design methodology agnostic. Its easy to imagine structure data migrating through as distributed system, being serviced by the various elements. Brings to mind a C program with functions that process structs.
SOA seems half-baked, as it should, because it is a largely untested idea. I think SOA will just be a short stop on the journey towards well architected, distributed and decoupled computer systems.

People need to get new jobs. Companies need to find ways to increase service offering/product offering. If they didnt happen to know how to package the same wine in a new bottle, we would have just had two languages C and ADA (ok... whatever the first structural and oo ones were)

So bottomline... to keep the rythm going, one needs to sing along and just be merry.

Quote: It was created in the marketing departments of the big companies (IBM, BEA, Oracle etc). It was created so that it is easier for them to sell the same old stuff again and again. And of course the architect zombies at the IT departments will think that they have to migrate to SOA and of course Web Services.

This is in line with what I teach my customers. I also strongly agree with the poster who said that SOA != SOAP.

I feel SOA is another name given to our very old functional arctitecture.
Well methods has been the functional unit of the software now SOA makes it the distributed and specialized components.

Let's say a new version of the functions in software

SOA is potentially a
Big Thing if you are a Corporate Developer.

I thought SOA was such a hot term in the recent years because of its use of Web Services to achieve the Integration.Things like publish,discover would make it even more easier to integrate existing systems.But with SOA we atleast have a standard format for data exchange that could be widely used,of course its not a new technology(eventually every thing is TCP or IP or for that matter bits and bytes)but SOA lets you do old things in a standard way,good if some one wants to have cross compatibility or available to many more interfaces in the future.

Standard?

All it has achieved is to standardize the lexicans and the grammar of the data format, and that should be credited to XML.

You are saved from writting a YACC/LEX grammar, but you will still have to write all of the semantic mapping codes.

Again you guys are falling back into the standards surrounding SOA, that's not wat SOA is about. The standards lie with SOAP and other definitions, and have nothing to do with SOA.
There is absolutely no reason why you could not realize a SOA without any use of webservices, xml or anything else related to that. Or can anybody think of a reason why SOA cannot be implemented with CORBA?

So, it all boils down to the fact that SOA is an architectural pattern (which has indeed been used many times before over the last years) and SOAP and other technologies are just enablers to the pattern. Sounds like a good pattern; it has no assumption as to the technology used in any way.

I would have to agree that the 'newness' lies in the fact that the pattern is getting documented, and not in the way that it is implemented.

Again you guys are falling back into the standards surrounding SOA, that's not wat SOA is about. The standards lie with SOAP and other definitions, and have nothing to do with SOA.There is absolutely no reason why you could not realize a SOA without any use of webservices, xml or anything else related to that. Or can anybody think of a reason why SOA cannot be implemented with CORBA?

Real-world example: in an e-government infrastructure on which I worked in 1999-2001 we used CORBA to implement interoperability between government sub-departments. We started with some basic synchronous services that performed DB-queries with object oriented semantics, both within and outside the firewall, plus one event-driven system that exchanged object-reference-based messages, made persistent in the message repository using an OO database. As soon as XML became popular in 1999, we eliminated object references from the messaging and used XML to encode message semantics. We eventually used XML also to encode routing info in the message, though CORBA Naming was still used to locate objects (services).

The synchronous infrastructure was eventually implemented and enabled, but in the end it turned out that the customer found all synchronous services useless, especially the fine-grained object interfaces accessed through two firewalls, the performance of which really s***ed.

Instead, the hybrid CORBA/XML messaging was found acceptable and several applications were scheduled to interact asynchronously, even with transaction semantics simulated by an asynchronous OK/NOK reply (in XML pushed through IIOP).

In reality, very few applications were actually linked this way, but the system is still working although the customer uses very little of it. In the following years, many prototypes were devised that replicated the messaging system using SOAP, but the original system has not yet been replaced despite the current anti-CORBA and pro-SOAP hype.

In the end, it all boils down to abandoning stateful/fine-grained interactions in remote calls and moving to a messaging system in which the semantics is well defined. And the semantics can be easily expressed in XML whatever the transport protocol is (TCP,FTP,HTTP,ASN.1,IIOP,JRMP)

Corollary: if MS had provided a working implementation of IIOP interop instead of causing the DCOM/CORBA war in the 90s, the IT world would be a better place now, notwithstanding the fact that XML is one of the key factors to interoperability.

Standard?All it has achieved is to standardize the lexicans and the grammar of the data format, and that should be credited to XML. You are saved from writting a YACC/LEX grammar, but you will still have to write all of the semantic mapping codes.

Semantic mapping is the rub, but what could be better suited for it than self-describing XML data, transformation pipelines with declarative and procedural stages, and visual tools like BizTalk Mapper?

Standards? Perhaps XML's best advantage at semantic harmony is its industry-specific schema standardization. With XML often a custom schema is unnecessary, with dialects like RETS, FIX, etc. There's a greater likelihood that both systems independently chose the same interchange format.

SOA is potentially a Big Thing if you are a Corporate Developer.

Thanks John. Great read!