SOA, CORBA and Web Services

Note: At some point I will address the REST based Web Service pattern and it's various incarnations and permutations but until then when I say Web Service here I mean a WS-I Basic Profile 1.1 based Web Service.

Over the past few months I have been reading everything I could get my hands on as we embark on our SOA journey towards happier customers, mind-numbingly productive developers, un-precedented vendor cooperation, lightning quick business agility and magically lower costs. Somewhere along the way we also thought everyone would get a pony in the deal but we have since found that to be an exaggeration. The three books I have found particularly useful have been:

• Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology by Eric Marks and Michael Bell. Get this book if only for the Governance section (chapter 7). There is no peer level of information or thought anywhere on this topic of SOA governance.
• Service-Oriented Architecture (SOA): Concepts, Technology, and Design by Thomas Erl. This is actually my favorite of the whole lot but it is rather a bit too large to put in my bag to carry to and from work. There are many sections in this one that I found to be BIA (best information available). Notably in the analysis and design sections.
• Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services by Thomas Erl. This is a pale third of the bunch but it is still better than all of the others that focus on Web Services. The author does go on to the level of annoyance about XML databases. Yawn. If you just cut out that part of the book or give the book to your children one evening and let them color lovely pictures on those bits, then the rest of the book is mainly quite good.
  

Sadly I have read or skimmed every book published and available through Amazon as of today - whether it is specifically about Service Oriented Architecture or Web Services. I say sadly because there are some real poorly done books out there in this area.

My background for the past 10 years has been in the CORBA environment so, when I first looked at Web Services I don't remember much but I was apparently seen giggling for a day or two. The WS/RPC model is identical to the CORBA model right down until you start talking about taking a reasonably sized message and bloating it up to monumental size through the dubious use of XML.

There is a slight difference though in the way you develop CORBA systems and Web Services. In CORBA you develop your interface (IDL), use a tool the generate the stubs and skeletons and then implement the server. With Web Services you typically develop your POJO (or equivalent in whatever language you are using) and then you use a tool to develop your stubs and skeletons and your interface (WSDL) and then you implement the server. The whole "XML is great because humans can read it" is IMHO a crock when you start talking about WSDL of any complexity. Give me a complex CORBA IDL any day over a simple WSDL and I can read and comprehend the CORBA IDL in minutes while you are still trying to figure out what name spaces are declared in the WSDL. This is really just a frustration with the hype around SOAP based Web Services. The part of the hype that "SOAP and WSDL is simpler because it is human readable" is just stupid and anyone who repeats this as a primary benefit should be ashamed of themselves and possibly taunted.

The interesting distinction between CORBA and SOAP based Web Services boils down to this -

• In CORBA you write the IDL by hand because frankly it is probably the most important part of the whole system to get right.
  

• In SOAP based web services the standard way of development seems to be to write something in your language of choice that then in turn can be turned into your interface of dubious quality by a tool from a vendor who really does not have a lot of motivation to make your service accessible from other languages / platforms. Most Web Service developers could not read their WSDL if there was money on the line much less know if there is anything about it that is less than optimal or that might cause problems down the line.

Most of the good SOA or Web Services books tell you to use document based web services (originally the Microsoft model) rather than the RPC based web services (originally the IBM model) but none of the tools we have actually go to the logical consequent of why you would do document based web services over RPC based web services. To get to the goal of loose coupling you need to define your XML Schema (multiple) and WSDL by hand, then use the tools to create the stubs and skeletons and create the server implementation. You have to control your interface and not have it auto-generated from vendor tools.

It seems I am back where I started 10 years ago, coding the service interface by hand without fancy tool support or anything more than some color coding of the dialect in your editor. The main difference is that instead of 25 lines of readable CORBA IDL we are going to have multiple XSD files and a WSDL that will be taller than my oldest child if it were printed out.

Oh well - apparently there is no stopping progress. Sometimes progress can look a bit wonky unless your tilt your head way over to the side and squint. Then it looks quite good and new and shiny

I do believe there are actual benefits to a well thought out and executed SOA program and SOAP based web services. However, it does get tiring to be continually bombarded with marketing and analyst drivel. It helps if you can find someone who has actually done this stuff and knows the actual costs and actual benefits - they can help cut through an amazing about of falsehood bandied about by those who, decades ago, stopped actually doing or producing anything real (yes I am pointing my finger at all of the analysts, marketing groups and mere opinion havers).