Snakes on a Plane

This film is either going to be amazing (I’m currently guessing Mulholland Drive meets Airplane meets Gremlins) or truly awful. Why haven’t I heard of it before?

Asynchronicity and Synchronicity in ESBs

Advantages of using synchronous behaviour in an ESB (such as SOAP over HTTP):

  • You want your clients to be simple to write - with asynchronous behaviour, when a reply comes back to a client, it needs to know how to correlate that with the request it sent out (this is one reason JMS has the concept of message and correlation IDs). This probably requires it to keep some state hanging around. This isn’t necessary with synchronous behaviour, as the client thread blocks waiting for the reply.

  • You want your system to be fast (in the general case). In general, you would expect synchronous behaviour to incur less overhead.

Advantages of using asynchronous behaviour in an ESB (such as JMS):

  • You want to ‘send and forget’. Asynchronous generally makes more sense for one-way operations than synchronous behaviour, for this reason.

  • You want the system to scale more cleanly when there are lots of outstanding requests from various clients.

The above observations are drawn from work with WebSphere ESB, although the general principles probably apply elsewhere.

Dull Presentations and Organizational Change

Edward Tufte’s excellent essay ‘The Cognitive Value of Powerpoint’ contains an excerpt from Lou Gerstner’s autobiography, an anecdote from when he first joined IBM in the 1990s, when the typical method of making presentations was to use PowerPoint (or similar software of the period), often producing results with a low signal/noise ratio. Lou was less familiar with this, and after enduring a short part of a presentation from one of his senior executives using this method, Lou asked him if we could ‘just talk about your business’. This was famous within and without IBM at the time. Nevertheless, it seems to have been rapidly forgotten. IBM presentations still often have a low signal/noise ratio, with slide ‘decks’ used as a general method of information exchange (sent round in emails, used as substitutes for essays and documents). Tufte explains in detail why this isn’t an optimum method of communication.

This isn’t really a dig at IBM - it’s far from the only guilty party - in fact, at least today, these types of presentation are pretty much standard, with varying levels of quality from organisation to organisation, and also presenter to presenter. But is this an indication of how ingrained certain techniques and practices can be? Many people (including myself) realise the value of what Tufte says (and on the odd occasion I get, I try to practice it). But suggesting change is hard - people always have something else more urgent to be worrying about. This just doesn’t seem important to many - although in the long-term I feel it’s a key part of an organisation’s level of success.

It’s times like this I realise just how hard it must be being CEO - persuasion is so tough.

5-minute SOA / SCA in WebSphere ESB

SOA (Services-Oriented Architecture) is a very general idea; the notion of defining business and computing logic as interconnecting services, typically in a distributed computing environment, where some services depend on (call upon) others. SCA (Service Component Architecture) defines some terminology and standards for this, using the concept of SCA modules - you can think of each module as being a black-box service. SCA modules can import services from other SCA modules (which have corresponding exports, defining the services they provide). They can also expose (export), and call upon (import) services via other protocols.

Inside an SCA module is a similar set of constructs to that of the interconnected modules; in the ‘middle’ there are SCA components, which reference other SCA components (which have interfaces). On the ‘left-hand-side’ of the module (it is indeed drawn on the left-hand-side in WebSphere Integration Developer) are the exports, and on the ‘right-hand-side’ are the imports. The exports typically connect to some components’ interfaces, and imports connect to some components’ references.

In WebSphere Process Server and ESB, imports and exports are one of four types:

  • SCA ‘default’ binding (it is perhaps helpful to think of this as the SCA ‘native’ binding). This binding is used to link two SCA modules together. It supports all valid SCA behaviours, and its implementation is system-dependent. SCA bindings can also only link modules within the same address space (in WebSphere Process Server and ESB this means on the same server) [correction: this is not true, please see this update], are easy to set up (just specify the other module’s name on the import), and are typically high-performing.

  • SOAP over HTTP binding - A web service is invoked (import) or exposed (export). These are synchronous only, by the nature of the transport.

  • SOAP over JMS binding - A web service is invoked over JMS (import) or exposed (export). These are asynchronous only, by the nature of the transport.

  • JMS binding - Data is sent to a JMS destination - i.e. a queue or topic (import) or recieved from a destination (export). These are asynchronous only, by the nature of the transport.

In WebSphere Process Server, SCA modules typically contain some of these types of components:

  • BPEL

  • State Machine

  • Business Rules

  • Human Task

  • Selector

  • Interface Maps

  • Java

WebSphere ESB adds an additional type of SCA component, a Mediation Flow. This can only be embedded in a special type of SCA module, called a Mediation Module (which can only contain one Mediation Flow). Mediation Modules can be run on WebSphere ESB and Process Server, but ESB is only designed for mediation, and does not support Modules containing the Process Server components above (such as BPEL).

You can find out more about SCA in Process Server by reading this excellent article on IBM Developerworks.

The Morality of Updating One's Blog After-the-Fact

These are the principles I’m currently trying to follow:

  • Treat writing a blog like any other peice of published writing: spend some time on it, re-read it, correct it, don’t publish it till you think you’re done. Use the draft feature of your blog software if you need to.

  • If you spot a spelling error or any other minor non-semantic blemish in a posting, it’s OK to correct that at any time.

  • Substantially altering a posting is like trying to alter history: it’s bad. At a minimum it might be confusing to your readers. At worst, you are deliberately altering what you’ve said. Making the alteration clear (the previous version in brackets, say) is probably OK, but it might be better to add your correction as a comment. I sometimes make an exception to this rule for the most recently posted entry, but only for minor semantic improvements.

Of course, ultimately, my blog is my own, and I do have the right to do whatever I like with it. And if I decide I want to alter an entry (I’ve libelled someone, or I’ve misunderstood something which has substantial repercussions on my reputation), I probably will. But by and large, I will try to abide by the principles above - just because it seems like the honest thing to do.

subscribe via RSS