Aehso’s Output

Interesting post, it’ll also be interesting to see if Sun’s strategy (especially for Java servers and tooling) ever follows this reasoning. Endorsing REST by providing the tooling wouldn’t be a bad thing.

aehso internet, java, soa

The Web 2.0 bubble continues to expand and with the hype comes the inevitable need for thought leadership. The daily arrival of “new, exciting and and revolutionary mashups/services” against the background noise of the perpetual “but what the hell IS Web 2.0?” questions from newbies is prompting the thought leaders in the arena to throw in their tuppence.

However, I got a bit worried when I read Thinking in Web 2.0: Sixteen Ways by Dion Hinchcliffe. Aside from having a real problem with #3 on Dion’s list (which is a fantasy) I couldn’t quite put my finger on why this list seemed valueless until I read Russell Beattie’s wtf 2.0? followup (great post title!). Dion’s list not only never touches on the business side of things, it never even mentions the whole reason why someone would want to provide a service – to make money. Update: There is some too-ing and fro-ing between the two in updates to their original posts but wtf 2.0 is still the more important post to read.

Besides, I’m not sure you can teach people how to formulate a good idea from a list of 16 rules for a technology domain that at worst defies definition and at best can only be defined using diagrams that contain 30-40 components.

Last year, podcasting was all the rage, destined to destroy big media. I don’t know about you but back in the real world, I still get most of my content from big media.

aehso dev, internet, soa, software

Carson Worshops have put up free podcasts of the main talks given by Joshua Schachter (Delicious), Cal Henderson (Flickr), Shaun Inman (Mint), Tom Coates (Yahoo!) et al. at the The Future Of Web Apps Summit in London a few weeks ago. Joshua Schachter in particular gave a fantastic talk on “things he learned while building del.icio.us”. Lots of practical infrastructure advice and some great interface design advice too. I’ve always considered del.icio.us to have a “nice-but-dim” interface – this talk verifies that this simple interface is the very reason why it suceeded when many others failed.

Anyone who is looking to produce software services (yes, even SOAs) could do worse than soak some of this stuff in. (hint: associated summit notes, wiki, roundup)

aehso internet, soa, software

Terry Shurter has written a piece in BPM Today that claims that the safest way to a SOA is via BPM. There are a couple of gems in this article that are worth picking out:

Because “process” can be substituted for “service,” an SOA also can be described as a “process oriented architecture.” This is a more accurate term for describing the technical aspects of the architecture than is “service.” The term “service” is used primarily to emphasize the point that one of the main goals of an SOA is the ability to switch software, Web and business functions in and out of the I.T. infrastructure with ease.

Terry, the word ‘process’ is no more relavent to the technical aspects of the underlying architecture than the word ’service’. In fact, when you talk to SOA folks you’ll realise that quite the opposite holds in their minds – a process is higher level (coarse grained) construct while a service encapsulates technical complexity. In SOA, processes consume services during their lifecycle.

SOA style languages like BPEL have constructs for defining completely abstract and executable high level processes. BPEL relies on already defined standards (like WSDL) to define services. BPEL also encapsulates all technical architecture details behind (web) services. BPEL has the particularly neat trick of allowing enterprises to expose their processes as services – BPEL processes themselves expose a WSDL interface and therefore can be viewed services. This allows you to end up with combinations like processes consuming services, serivices consuming services, processes consuming processes etc.

Here’s another:

Enterprise processes that are essential to BPM do not translate into services under the SOA design.

I wonder why Terry makes this assertion – is it not possible to express BPM processes in SOA constructs, or is it just that he hasn’t tried it yet? If it isn’t possible, then surely to whole SOA approach is is doomed from the start – after all, we’ll just end up with a series of jigsaw pieces that we cannot piece together. Maybe Terry should read the BPEL (or WS-Choreography to some extent) specifications.

…there are substantial differences between SOA and BPM

There may be substantial differences between SOA and existing BPM products but that is probably because those products are not standards based and their use of proprietary interfaces and protocols means they will never be able to natively join the SOA party. Keep an eye out for BPEL based products though, I think you’ll see BPM being subsumed into SOA then.

Yet, there will be many investments in “home grown” SOA architectures. These systems certainly will perform the operations they are intended to handle, but their competitive value will be short-lived, and replacement in the not-too-distant future will be all too common. The better bet? Take the BPM route to SOA.

This reminds me of a recent piece by the VP of Business Development at Polar Lake that stank a little of FUD. Another piece illustrates that the old proprietary BPM vendors will have to wake up to the fact that their market has shifted.

Most of all, I hope folks won’t pick up on this re-use of the acrynom ‘POA’! It already has a specific meaning when referenced to the technical types that actually have to implement this stuff.

aehso soa