This is particularly useful for ESB, as it allows it to mediate messages from and to an MQ queue using JMS bindings. You can find more information on how to set up an MQ link in the Infocenter.

ZDNet Asia recently discussed SOA. I noticed that they mentioned that SOA was built on Web Services. This is often true, but the IBM product I work on, WebSphere ESB, allows one to build an SOA entirely without Web Services if desired – for example, you could use it to build one based on JMS messaging. A wide and generous definition of SOA is probably the only one that makes any sense. Some of IBM’s recent SOA products are built on SCA, which allows for a clearly-defined component model for SOA, but this doesn’t have to be used either: you could build an SOA with Visual Basic, a printer, and a minimum-wage employee to enter data, although your response time might suffer somewhat. The only requirement is that the architecture has to be oriented around services (hence the name).

Some might argue that this model is so simple as to be useless, and that might be true if organisations stuck to the widest definition, but if you’re able to adopt a particular type of technology (for example, going the WebSphere/SCA route), there is the possibility to begin to reap the benefits of reuse, adaptability, etc.

So be generous with the definition, but specific in the implementation.

This is significant as IBM gets ready for our big SOA announcement on 3rd October. Whether you believe the hype or are cynical about SOA being the next big thing, you can find out more details on the IBM website here and register for the webcast.

I’m not sure I can comment that widely on the state of current SOA projects, and I would agree that SOA may suffer from similar management problems to that of object-orientation: if developers of SOA systems aren’t rewarded for saving time with a reuse strategy, they won’t be enthused to do so. This is an important part of any software project, and encouraging reuse is a best practice that shouldn’t be restricted to object-orientation or SOA.

However, whilst I agree that SOA has other benefits apart from encouraging reuse, I have a fairly high opinion of its potential in that respect. It’s important to understand what we mean by reuse. Reuse rarely means using an object or service as it is. There is often a mismatch between the interface offered by the service (object) being consumed, and the service (object) that needs to call this interface. Expecting anything else is unrealistic (even if future reuse plans are made). This is often solved using something like a façade pattern in object-oriented languages, and some form of mediation with services (such as that offered by WebSphere ESB). The latter is often easier, because there is a lower degree of coupling than inside a single programming language, and because programming code is not often needed, and this is why I believe SOA reuse is simpler – if done well. Of course, some work is still required, but this greater ease of reuse makes it a realistic strategy for more scenarios.

I would agree, however, that, as is often the case, the project management problems here are the greatest ones.

Of course IT fads come and go, and many people have been saying that SOA is another one of these. In fact, many of these fads do last – they just lose the buzzword feel (e-business being a striking example). SOA certainly has some of the hype associated with a fad, but the book does highlight one of the key points that could play in its favour and allow it to persist – that keeping old IT infrastructure is A Good Thing, and that SOA is iterative and about reuse. This is a more realistic business IT model than throwing everything away and starting again, and thus it may see more practical success than some models that have been consigned to the dustbin because they demanded too much up-front.

Of course SOA still has some way to go, particularly with some of the -ies: scalability, security, usability, reliability, and so on. This special edition doesn’t really delve into those topics. But it’s a good start. I’d encourage anyone interested in SOA to read this book – it concludes with an promising example of how Delaware Electric are using WebSphere ESB to build an SOA.

Update 2006-09-22: I’ve been informed that we’ve run out of copies of the IBM special edition of this book – sorry! You can still pre-order a copy of the full book on Amazon by using the first link above, however.

As an aside, I found this article as part of the WebSphere ESB support RSS feed. For those that aren’t aware, there are support RSS feeds for several IBM software products, which provide new information on documentation, fixes, and other issues. Find the product you’re interested in on IBM’s website, and click on the ‘Support’ link. Then look for the orange RSS logo for the feed.

- Your friendly editor

But what do we mean by the phrase ‘business logic’? Ultimately both business logic and technical logic come down to the same thing; instructions executed by the machine. I can implement both in mediation flows, Java, Perl, assembler, or shell scripts. So why the distinction? It really depends on one’s perception.

For example, let’s imagine we are developing an integration system for a peanut factory, and we are developing a system to handle the orders. A typical way we might encourage someone to use WebSphere ESB is at the boundary, to convert between the protocol used by the web-based bulk order system (say SOAP/HTTP) to the one used by the back-end production system (say JMS). The distinction between these isn’t important to the business; it doesn’t matter what format the message is in; it just has to be in a certain format because we need some integration and don’t want to change everything.

By comparison, we might encourage someone to use a business flow to model (say) the approval of orders of peanuts. The process might follow a number of steps, some of which might involve human intervention, to modify the order (message) accordingly – i.e. adding ‘approved’ or ‘denied’. This would be based on the size of the order, that customer’s past history, whether they were salted or (urgh) dry roasted – all things that are at the business level – things that we find interesting (assuming we like peanuts).

Therefore, let’s characterise the difference as follows:

• Technical logic: Stuff we don’t want to do, but need to in order for everything to work.
• Business logic: Stuff we do want to do – the reason we’re doing all this. We can not only decide on how to implement this (as we can with technical logic), we can also decide not to implement it all, or to implement different logic.

Therefore, these two types of logic are at different abstraction layers – the technical layer we’d love to make as simple as possible and hide away (and I’d like to think WebSphere ESB does a good job of helping IBM’s customers do that), whereas the business layer we find interesting and want to spend some time on. I mentioned something similar before as a best practice – I could rephrase that best practice here as: ‘Spend as much time as possible on the business logic, and as little time as possible on the technical logic’. It seems sensible, then, that to keep them separate (and there are plenty of patterns for doing just that) is a natural thing to want to do.

I’d love to hear some comments from my consultant colleagues on this: do you think this distinction is important? Does it impact the way you work day-to-day?

There is an alternative. You can create your own first-class mediation primitive that has its own icon in the WID mediation flow editor and can have custom properties. This is more work, as you are essentially creating a mediation equivalent to those supplied by WebSphere ESB, but it is thus suitable for re-using in many mediation flows. Confusingly, these are sometimes called custom mediations also (probably because they don’t really have a name). For example, you might write a generic mediation primitive that could do arithmetic on an incoming message, according to a set of parameters you specify. There is a document on the IBM website that describes how to create them.

To clarify, WebSphere ESB can be used to construct SOA architectures that are based around Web Services or JMS, or a combination of both. Simple-to-implement SCA default bindings can also be used within the scope of an ESB cell. In fact, because it is built around SCA, the invocation mechanisms are partly abstracted away: when you construct mediation flows in WebSphere Integration Developer, all these types of ‘bindings’ appear very similar. All of this makes WebSphere ESB a powerful tool for linking together traditional messaging systems, based around JMS, with synchronous Web Services, as well as other types of services and systems using WebSphere Adapters.

For more information on SCA and why it’s useful, please see Richard Brown’s excellent posting on this topic.

As with many of my other postings about WebSphere ESB, most of what I said above also applies to WebSphere Process Server, as it is a functional superset of WebSphere ESB.

However, I feel this is one area where products such as WebSphere ESB can help. ESB builds on top of WebSphere Application Server, which is IBM’s primary implemention of a J2EE-based server. ESB allows mediation – i.e. modifying the content of Web Services, JMS-based messaging, and so on – without having to worry about a lot of the J2EE world. In fact, under-the-covers, ESB mediation modules are EJB applications that are Web Services clients, JMS clients, and so on (and this is easy to see if you know something about J2EE), but normally this is all handled by WebSphere Integration Developer and ESB without the need for understanding the nitty-gritty or doing any programming.

So it will be interesting to see software like ESB, which is enabling the development of SOAs without fully understanding J2EE, will affect the J2EE landscape. Perhaps it will be able to stay as-is and will become another layer that many people don’t want to concern themselves with. Time will tell.

• ESB SCA-based mediation modules, which can contain ESB mediation flows (and Java components).
• Process Server SCA-based modules, which can contain Process Server SCA components such as business processes (using BPEL), human tasks, business state machines, business rules, and selectors.

(see this posting for more information on SCA modules and components)

WID, like RAD, is Eclipse-based, and provides the same flexible, customizable development environment. For example, one can customize the Eclipse Capabilities provided by WID so that the Process Server and/or ESB development functionality is hidden (once loaded, go to Window / Preferences / Workbench / Capabilities / Integration Developer / *). This is useful if you know you want to target a particular type of server.

Although WID is often used with WebSphere ESB or Process Server, it is not supplied in the box with them and must be obtained separately. However, it does contain a version of Process Server that can be used for testing modules before deployment – commonly referred to as the Integrated Test Environment (ITE) or Unit Test Environment (UTE). During installation of WID, you can create an ESB or Process Server profile against this for testing with (or both). This is possible because Process Server contains a superset of the functionality of ESB. See this Developerworks article for more information on testing this way, as well as some more information on WID.

You can find more information in this article on Developerworks.

It’s worth adding that there also two other types of bindings that I didn’t cover before:

• Enterprise Information Systems (EIS) – Integration with WebSphere JCA adapters.
• Stateless session bean – Integration with stateless session beans.

I plan to cover these more in later posts.

• Phone call – synchronous. You are engaging in an ongoing conversation with the other party. The flow of conversation goes back and forth at a high rate, and you have to be present when the phone call is occurring to participate (ignoring voicemail, recordings etc.).
• Email – asynchronous. You can send someone a message and it doesn’t matter when they read it – it could be in 2 minutes, 5 hours, or 3 days. The message can get to them via a number of ‘store-and-forward’ hops, rather than directly. When and if they reply, the same rules apply.

Text messaging, in many ways, is technically similar to email. It has different protocols, is typically used with different types of software, and has different formats. But it’s still store-and-forward and is still technically asynchronous.

However, I would assert that in many (although not all) situations, text messaging is, from a usage point-of-view, synchronous. The stories about teenagers who rack up £1000s in phone bills or develop RSI from text conversations across the classroom attest to that. Although they are using a mechanism which is by nature asynchronous, they are actually able to use it in a semi-synchronous way because it is reliable and fast. Whilst most adults’ use of text messaging isn’t quite so dramatic, text ‘conversations’ of 3 or 4 messages in fast succession each way aren’t uncommon (I have done this, although rarely, because I have large thumbs and find phone keypads awkward – don’t laugh!). Also, though, text messages are still used asynchronously in many situations (I don’t have any statistics on this but would hazard a 50:50 ratio as a not unreasonable estimate).

In many ways, this isn’t anything new – it has always been possible to emulate synchronous messaging with fast asynchronous messaging (arguably, this is what voice-over-IP systems such as Skype do, for example). But what I do find striking about text messaging is its dual usage role – sometimes synchronous, sometimes not. Often the difference is only in the perception of the sender – some people expect prompt replies, others perhaps not for days, and it all depends what one’s sending anyway.