Here it is, after three long days in a Service-Oriented Architecture (SOA) course: The Rant. I probably shouldn’t do that, since I am giving a SOA course myself this semester. However, a good instructor should be sincere. SOA is not perfect. It is a good technological stack, that serves a slightly outdated methodology.
The point is that structural, procedural, top-down analysis never died. It was good for BASIC and it is still good today. A J2EE application is, apparently, just a COBOL routine with delusions of grandeur.
I’m saying this because the top of the SOA stack, the cherry on the pie, is business process orchestration, and the format of it - E.g, Business Process Execution Language (BPEL) – Is, plainly put, a flowchart. The official UMLish name is an “Activity Diagram”, but it’s actually a crossing between a Data Flow Diagram (DTD) and a simple, punch-cards-friendly, flowchart.
That’s not entirely correct. The orchestration may omit the actual binding, allowing systems to locate the best service at run-time. IBM tools can also run some simulations and statistics on the process definition. From a programming languages point-of-view, however, it’s just one level of abstraction higher then COBOL-over-HTTP.
Maybe this is the correct way. At some high-enough level you want things to stop being abstract. A business process that models, for example, approving loans, is a very bad place to introduce ambiguity. Here’s a theorem: The number of possible run-time scenarios should be in reverse ratio to the amount of money (or lives) that is at stake.
Having said that, that’s still a bit of a sour end to a very high tech stack. Do we really need HTTP, XML, DOM, XSD, XPath, J2EE, JAX-RPC, SOAP, WSDL, UDDI and BPEL (wow, these are a lot or acronyms!) just to run a distributed flowchart? Apparently we do, but something doesn’t feel right about it.
Well, that’s what happens when you have to work on top of sucky standards. You have to make up for it. Using more sucky standards. It’s one big coverup!