Well, well, if
that little chat Stefan and I had on
Guerrilla SOA
didn’t go and quite a stir (though mostly positive) out there in the bloggy
bits of the Web. I think it might be time for some further exploration and clarification.
So first up there’s the issue of how
Guerrilla SOA leads
to a bunch of disparate efforts across the enterprise brought to light by
Joe McKendrick’s colleague Tony Baer. I think it’s a dodgy implication that
a Guerrilla campaign cannot be successfully orchestrated across numerous engagement
(anyone heard of Che Guevara?) because Guerilla does not mean uncoordinated.
Tony’s assertion that “That is, too many unconnected SOA efforts will simply
lead to a lot of unconnected SOA efforts, with little to no value for the business
at large” is profoundly wrong from a Guerilla SOA perspective since it
is the business that acts as the connecting glue between all the Guerilla SOA
efforts because they own the processes that feed service development. Far from
advocating lack of governance in SOA, I’m about putting governance into the
hands of the business and then incrementally delivering to their priorities
(and if you’re sensible, letting the business stakeholders help drive out the
service architecture).
Next up there’s the
“nothing new here” response
as exemplified by Jason Bloomberg of ZapThink. I actually agree with that sentiment
very strongly, which is not surprising since both Jason and ZapThink grok this
stuff pretty well. The fact is these ideas came out of some fairly intensive
discussion between Savas Parastatidis
and myself around 2000-2004 and they’d been publicly aired while I was living
in Australia. The
Guerrilla SOA talk (warning:large video file) I’ve been giving does actually
go a step further than
ZapThink’s
ESB approach in advocating using minimal (ideally zero) middleware to implement
your SOA preferring instead endpointware like the various WS-* toolkits or the
Web. That talk also argues that shared middleware is inherently harmful to your
SOA: An ESB will give you
an ESB-oriented architecture aligned to someone else’s technical framework,
not an SOA aligned to your business processes[*]. So yes there’s nothing new
intellectually here (the Agile community has been delivering software like this
for years), but how many practitioners are actually delivering business value
via their SOA this way rather than creating nasty bottom-up services with little
or no discernable value to the business? Not too many because they’d rather
raise armies of consultants and lay siege to the problem instead.
Next we move onto
MEST, or MESsage Transfer, again a term coined way back in the early days
of WS-* by Savas and myself. There
is, as Savas already pointed out and
Neil Ward-Dutton picked up, nothing new here. MEST advocates the transfer
of a message with some business payload and processing context. Period. We never
claimed anything groundbreaking with MEST but were instead trying to encourage
a message-centric architectural style for Web Services – you know, so that Web
Services might possibly scale and be robust – in the face of an overwhelmingly
unsuitable RPC model being pushed by WSDL[**] and the vendor community[***].
It’s nice that MEST maps to SOAP very cleanly, and having been thoroughly
cheesed-off by WSDL’s inability to support message exchanges which typical business
services exposes, we (with the support of
others) created the
SOAP Service Description Language (SSDL).
SSDL is is a MESTian contract language for Web Services that makes the simplifying
assumption of SOAP and WS-Addressing bound to arbitrary transport protocols
based on URI scheme for the transfer of messages (which means it’s much less
verbose than WSDL). Even better is that SSDL can be used not just to model the
message-exchange patterns of a single service (and verify the correctness of
that protocol) but it can even be extended to support and prove multiparty,
multi-message conversations too.
Did I mention that SSDL is simple enough to be written by hand?
‘cos it is.
But I digress, the key point here is that good SOA (Guerilla or
otherwise) is about incrementally delivering business processes packaged as
services. The nice thing about this is that any duplication and refactoring
happens at the business process level (the source of truth) and the business
gets to decide what services are deployed to meet support their objectives.
At the technical level we still need to build those services, so our jobs aren’t
going away. But all that governance stuff is surprisingly as much a business
decision as it is the duty of your friendly local-neighbourhood enterprise architect.
[*] I’ll be giving the Guerilla SOA talk at
Øredev in November if you want to find out more.
[**] Remember: winners don’t use WSDL.
[***] Doc/lit doesn’t lessen your RPC-ness, because WSDL is
utterly RPC under all circumstances. Regardless of whatever wrapping convention
you employ or whichever schemas you use, you’ll still build RPC services with
WSDL.
