Ten-Hove on BPM and SOA
Ron Ten-Hove has two interesting blog entries, one talking about how SOA Services != RPC and another one about the relation to business process automation. In his view, the most important difference is the separation of business process logic from the implementation of business functions.
I know this is a common view, but I disagree — to me, BPM, business process automation, and SOA are not only two, but even three different, orthogonal concepts. The value of SOA, in my opinion, is its emphasis on autonomous, language-agnostic and platform-independent services that share a common interface technology; it does not really matter whether they implement a business process or some technical function.
Stefan,
So are you saying that services really are just a form of RPC, and that their inherent value resides in being “…autonomous, language-agnostic and platform-independent services that share a common interface technology”? Isn’t that a good description of CORBA as well?
Of course it very much depends on the definition of some terms we’re using here. If by RPC you mean a programming model, I agree that it should not be used in SOA scenarios.
But yes, I do believe that a SOA landscape can be built based on CORBA; it’s just that CORBA makes it easier to violate SOA principles because it is a natural fit for a tightly-coupled client/server scenario rather than for loosely-coupled services. But Web services can be used to build tightly-coupled systems, too - in fact, this is what happens most of the time in my experience. Using XML can reduce the degree of coupling, but only if it’s used to encode documents, not if it’s used as an object serialization format. I’m a big fan of wire formats as opposed to unified programming models, too, which is also improved in WS as opposed to CORBA.
But my definition of SOA is: A cross-application, enterprise-wide architecture where functionality is split into autonomous units called services, where each service can be independently developed, deployed, updated, and run by separate organizational units or external companies. This is achievable with lots of different approaches, and I don’t see why CORBA would not qualify (although I wouldn’t recommend it).
It does sound like we are in basic agreement; we know “good” services from “bad” ones, based on SOA principles.
But how do we discover “good” services in the first place? In many enterprises, where a large chunk of IT’s value is found in business process automation and management, business process activities are a good place to look. More generally, taking a functional view of the business will yield good candidates for services.
SOA is really nothing new, and I agree it was (and is) feasible to create a SOA-based system using CORBA correctly. Feasible, but unlikely, for a host of reasons, one of which sounds a lot like the “bad” services mentioned above.
So what is different in the latest incarnation of SOA, based on XML messaging using ubiquitous protocols? Arguably the only big difference between today’s SOA technology and CORBA is that Microsoft supports the former, but not the latter :-). Other than that, the technical (and architectural) hazards are similar.
As for your preference for wire formats as opposed to unified programming models: +1! Why would we spend all this effort trying to create (and benefit from) loose coupling, and just take it away again with yet another attempt (and there have been quite a few) at the Sauron theory of programming (you know, one model to rule them all).