01/11/09 :: [SOA] The SOA Soup [permalink]
There is no better way to kill a SOA initiative than handing out the trilogy of the most vaporous specs the SOA community has ever produced: SOA-RM, SOA-RA and SOAML. Considering that Duane Nickull is behind the first 2 and Cori Casanave is behind the 3rd one, this should be no surprise to anyone.
It's interesting that people can still fund this participation for this kind of initiative. If SOA-RA's figure 2 does not scare you enough, you'll spend much of your time wondering whether this spec is just shallow or plain idiotic. For once I could easily side with the RESTafarians who look at this kind of work as a justification for adopting REST. Check this out, SOA-RA does have a "resource" as part of their RA. However, a Resource is the parent type of a description, as in a Service Description. This is hopeless. The saddest part of this document is fig 21 & fig 26, as they describe the relation between the information model and the service interface. Of course, SOA-RA had to have a layer of Social BS otherwise it would not be "complete". A bit of light with the action model, but that's not enough to salvage the spec. Fig 30 is really rocket science, I am glad they thought of it. Fig 31 is the pinnacle of this spec, this is service orientation at its best. Thank god, they were able to derive the W3C reference architecture (figure 37) from their RA. What couldn't we have done without the W3C vision for SOA. On the highest note of the document, they do talk about service collaborations (p72). I know now where Jim Webber got his initiation to the "Service Oriented Business Processes":
Business processes are comprised of a set of coherent activities that, when performed in a logical sequence over a period of time and with appropriate rules applied, result in a certain business outcome. Service orientation as applied to business processes (i.e., “service-oriented business processes”) means that the aggregation or composition of all of the abstracted activities, flows, and rules that govern a business process can themselves be abstracted as a service [yeah right...]
Sad.
Fig 50, 51 and 52 are hilarious. Isn't UML wonderful? Who knew SOA Governance could be defined with a handful of classes?
SoaML is not bad either. as a starter, you get that they already got the camel case a bit wrong. But if that was the only problem. You'll notice that there is a bunch of vendors behind it. Now, I like the OMG, this is a great institution and they usually come up with great specs and the SOA Consortium has published countless amounts of wisdom to help you drive your SOA initiative. So where did SoaML come from? This is back to the future XV. Already, back then, Cori Casanave was plotting to align ebXML BPSS with OMG's BOCA, even though they had nothing really in common. BOCA was a great spec, way ahead of its time, but what a stretch to extend it to B2B collaborations. No worries, the software industry loves to use one thing for another, reifying they call it. Actually, I learned this word from Cori himself (sorry in France we don't reify, this word is banished from our vocabulary). I feel sad that Fred Cummins got dragged into that spec, there is certainly a big mismatch there. So what did Cori did this time? With the help of Antoine, they plugged ebXML BPSS in the SoaML. In reality that's BOCA that he has tried to plug in. How about DCE? SGML anyone? Anyone remembers OBI?
You will notice on figure 4 how much a dead end UML profiles are or how bad if MOF, whichever you prefer. They need 2 "interfaces" to describe a "Service Interface" because of the bidirectionality. I should be happy, unlike the idiots at WS-I they support bidirectionality.
I like the hat on fig 18... LoL
Figure 22 shows again how wrong it is to go the UML / UML profile route. This is pure hand waving. Come on Fred, you can't let that pass. Can't anyone get right the relationship between an information model and a message model? You can't tell me you can't.
You see, it really takes a couple of guys here or there to screw up an entire field or even an entire country for that matter. I got an idea, you guys could spend some quality time on defining the REST-RA? you that that is a very promising field. I am sure you can get your name up high on the board and magazines. If you are lucky analysts will even ask you some questions and write about how cool your REST-RA is.
My advice is that you use the CBDI SAE and Praxeme. These guys really know what they are talking about.
The tragedy behind SOA is clear: it lacks a real RM, RA and ML/Programming model. Over the last ten years, everybody and their brothers, sisters and mothers told us what they thought SOA was. They pompously initiated debates around data, integration, JaBOWSs,... before they proclaimed their own ignorance and closed mind and told us XXX is dead (where XXX is ebXML, Web Services, SOA, ESB...). In the mean time the vendors like Cori or Duane (and frankly many many more) reified their products, thinking, programming model, databases... you name it behind the SOA banner... ah no, it was actually the other way around, they came out with their petty vision of SOA and explained us their silly product was SOA. WCF for instance came out and reified SOA behind OO, now the same team is reifying REST behind SO, i.e. OO. You take Bill Burke with REST easy and what does he do? He makes REST so easy to use that actually you add a couple of annotations to a Java class and you are done. Happy cruding ...
So I don't know what to say anymore, I don't know what the 2010s will bring us. I just know that the 2000s brought us nothing and SOA-RM, RA and ML are an excellent summary of what happened in the last 10 years.