A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I've been seeing SOA all over the place recently so thought I better figure out what is was all about. After reading an article on Suns website I couldn't help thinking that SOA is another form of COM or CORBA - just happens to use XML and often the web.
Am I right? Is this holy war territory? Is it competing technology with .NET?
It's the new name for WebServices.
And since .Net does everything, everything is a competing technology.
Monday, May 09, 2005
SOA is NOT COM/CORBA.
COM & CORBA are about distributed objects. You call a method on a particular object, and you don't care about what machine the object is running on.
Except that you actually DO care about what machine it's on, since objects have identity and state. That was what really killed distributed objects on the net - the inherent lack of scalability that was the consequence of object identity.
SOA is actually a step back - you don't call a method on an object, you send a message to a service. You don't care about state: SOA messages are intrinsically stateless. In SOA, it's all about the message and the contract (what the schema of the message is, wether you expect a response, etc.) As a result, you don't care about the details of the service implementation: it could be a relay, it could be load balanced, it could print out a piece of paper that gets tied to a pigeon leg, etc.
Having said that, SOA is something kinda new to play with that gets the plumbers excited. Kind of like when Microsoft "discovered" transactions with the introduction of MTS back in the 90's. We'll need to see how well it works out in reality.
There was actually plenty of stuff in CORBA that was relevant to "service oriented" and "stateless" approaches - if you chose to architect things that way.
Incidentally, I found it interesting that when ACM were launching their "Queue" magazine, the first issue was going to include a provocative article entitled "Web Services are just CORBA with a weight problem" - a view which, although simplistic, I had some sympathy with.
However, the said article mysteriously never appeared.. perhaps because someone, somewhere had an interest in selling Web Services (surely not).
Also.. one does have have to ask oneself why we now need a binary XML standard! :)
Part of the problem CORBA has is of course that some people simply abused it by remoting large numbers of lightweight objects instead of considering what granularity was appropriate for the underlying infrastructure.
Actually SOA can be implimented without Web Services as well. Just so long as you're stateless and sharing schema you're not really violating the norms. The concept it self is not new, and has really been around since the late 90's, much like AoP.
However there is still a fundamental issue with SoA... and that is support for 2-phase comitts and long running transactions. Implementing these without violating the WS* or SoA principles when enforced strictly is still a tall order.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz