Bernard Wheeler's Weblog

I was in an interesting discussion with Warren Buckley, CTO from PolarLake yesterday. He was going though an update on their technology and positioning with me and a few colleagues in one of Sun's London offices. What he said prompted a number of trains of thought about SOA implementations and some potential pitfalls that are so glaringly obvious as to be easily overlooked.

One of the repeating themes in discussions about 'effective SOA' is the matter of granularity of services: make it too fine-grained and you (or rather, the business) will have a hard time threading all the many bits together in the right sequence without forgetting to add in all the key steps; make it to coarse-grained and you'll find yourself creating a new set of services for each new application variation, because the services you have are too specific to enable re-use.

But we touched on something that I don't believe has had a sufficient airtime to date.

It is generally agreed among those that participate in such conversations that the services exposed to orchestration – and therefore the main 'components' used to build up composite applications are themselves going to be composite pieces of functionality. All well and good, but what paradigm do you use for the construction of those composite services? If the answer is that you want to employ re-usable services for that too, then there's a question that needs to be asked: what mechanism are you going to use to enforce the orchestration piece not to be able to use your lower-level services and only use the composite ones that you originally intended?

I'll use an example loosely based on a real situation: a finance organisation has built up to its current size by both organic growth and a number of acquisitions. As a result, some of its business units still effectively act as autonomous units IT-wise (and financial legislation dictates that to some extent this must remain so), but the institution as a whole wants to enable its customers to see and manage their overall portfolio through a single view. To handle this situation, the institution has rolled out the concept of service 'domains', where functionality available from a business unit is formally described at its boundaries and the internal workings of how that is achieved is at the discretion of each business unit. This matches the profile of a SOA approach, so it's so far, so good. Now the Home Loan group publishes a service at this boundary point for “get loan balance”, but they also have an “internal” service (say, “get loan balance from mainframe”) that actually goes to the specific system that holds the home loan data - in the “Data” layer, rather than the “Service” layer of the typical 4-layer SOA model. A developer has been transferred out of the Home Loan group into the main corporate group and thinks he'll use the service that minimises “service-hops” and goes straight for the data-layer service. Now that may not be what's intended, but after all, it's published as a service, and who's going to spot it?

Now in the OO world (to which SOA is often likened), there are distinctions of public, protected and private. And there are things called packages that may be equated onto the service 'domain' concept that the finance institution has implemented. But at the moment, equating is all that we can do. There is currently no mechanism to enforce this model. (There are many, many other qualifiers that can be used in OO and may have a useful equivalent in SOA, but that's not the topic of today's ramblings.)

I wondered (during the aforementioned discussion) whether this is something that will eventually work its way into the policy-related specs and technologies, but these still seem to be a little way off in terms of widespread consistent adoption and implementation. And on reflection, a better way to implement this kind of control is to (again) follow the lead and place the qualifier in the declaration – which in the case of a SOA implementation based on web services would mean putting it in the WSDL for each web service. But in my (admittedly far from encyclopedic) knowledge of WSDL, I don't recall equivalents of private, public and protected. And it's not a run-time permissions thing (so it's not WS-Security, SAML, or the like), it's a define/design-time 'exposure' thing...

So since WSDL doesn't help here, a way to achieve this (in my opinion) necessary enforcement, would be to start segmenting your service 'domains' so that they each had a separate registry with different look-up coverage. But that introduces the likelihood of data duplication of service definitions in more than one look-up registry, something that would be really nice to avoid. But at the moment this is likely to be the only realistic way of managing external access to services by third-party organisations (although PolarLake discussed a case where they have essentially implemented a reverse proxy for service access which would also be effective, and possibly more heavyweight).

So SOA – even a highly standards-based implementation – has the capability for creating just as much of a 'service spaghetti' as any other kind of software construction – and doesn't currently have several of the mechanisms found elsewhere to try to encourage and enforce good discipline. Exposing data-level, platform-specific functionality as services may follow the intent of SOA to the letter and will probably allow greater flexibility, isolation and 'agility' in being able to upgrade, replace or consolidate back-end systems without affecting your shiny new composite apps. But there needs to be a mechanism or procedure that checks and enforces that these lower-level services are not being called inappropriately, causing unforeseen 'hard wired' cross-links to appear where you thought they couldn't. But there isn't (to my knowledge) any such kind of automatic mechanism or procedure.

Which means that there's likely to be some very expensive almighty mess-ups made if the right level of discipline and forethought isn't consistently applied by the design and implementation teams. But it was always thus, and as has been said about SOA before: “the rules of physics still apply”.