Apologies for the lack of posts recently on WebSphere ESB. I’m currently out of the office and out of ‘work’ mode, so I’m not writing many posts on that topic. I’ll be getting back to it in a week or two, though, so please stay tuned. Incidentally, if you’re not already aware, you can subscribe to RSS feeds for just a specific topic on this blog, such as SOA & ESB (feed here) - in fact, you can do this with any WordPress Blog. Just go to the category archive (select from the list on the right-hand side), then append ‘/feed’ to the URL.

- Your friendly editor

In the world of business-oriented software, we use the phrase ‘business logic’ a lot. In my particular area (WebSphere integration products), a typical pattern is to delegate ‘technical logic’ to mediation flows in WebSphere ESB, and to put ‘business logic’ in process flows in WebSphere Process Server. It doesn’t have to be that way, but that’s what many people encourage, as it seems to neatly match what the software can provide.

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?

To recap, WebSphere ESB provides a bunch of re-usable mediations out of the box that you can use in your mediation flows to alter message content (XSLT mediation), filter on it (Message Filter mediation), and so on. However, it also provides the facility to create your own mediations, called ‘custom’ mediations, in mediation flows. Typically, you’d use these when the provided mediations can’t do something you want to do. They are SCA components implemented by a Java class, so appear in the assembly diagram for a mediation module (where you’ll see that the mediation flow component references them), but they also appear in the mediation flow itself as a mediation. They provide an execute method, which has a DataObject as a parameter (message coming in) and return a DataObject (message going out). This is where your logic goes. Normally you don’t need to worry too much about all of this, as WebSphere Integration Developer makes it easy to create a custom mediation in your flow like any other mediation, and creates a Java skeleton for you - all you have to do is define the method. You can’t specify any of your own parameters on a custom mediation, so typically you’d use these where you are doing something specific that you’re unlikely to re-use. Nigel Daniels has written an excellent article on how to implement custom mediations.

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.

IBM has just announced that it has acquired Webify, a provider of ‘Service-oriented Business Applications’, which are SOA assets designed specifically for certain markets, such as insurance and healthcare. It will become part of the IBM WebSphere organisation. It remains to be seen exactly how Webify’s products will integrate into the IBM product line, but they sound like they will be a useful addition to IBM’s SOA vision, and I look forward to working with our new colleagues from Webify.

This month’s BCS ‘iT NOW’ magazine contains a short anonymous article entitled The problem with SOAs. It does a reasonable job of explaining what an SOA is at a high level, but I thought it might be worthwhile briefly discussing it in the context of WebSphere ESB. As with many discussions of SOA, the majority of the article is spent discussing Web Services as the invocation mechanism for SOAs. At the end it mentions JMS as a possible alternative invocation method, but says ‘implementation may be problematic’ (although doesn’t really explain why).

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.

Cote’ posted an article recently discussing the possible death of J2EE (Andy Piper, another blogger from here in Hursley, has noticed this too). It’s pretty hard to assess the likelihood of that happening, and I’m not sure I’m in a position to comment. However, it’s probably truthful to say that J2EE is a complex platform to get to grips with. In a sense, J2EE, although a standard and a platform, has always really been Java plus some other stuff (EJBs, Web Services, Servlets, JDBC, JMS, etc.) rather than a single entity. This means you really need to be able to claim an understanding of all of these to fully ‘get’ J2EE.

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.

WebSphere Integration Developer (WID) is IBM’s development tool for constructing SCA modules that can be deployed to WebSphere ESB and WebSphere Process Server. It is built on top of Rational Application Developer (RAD), which is in turn Eclipse-based, so it inherits a lot of functionality, including support for Java, J2EE, UML, etc. However, it also provides the ability to develop:

• 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.

After my previous post about mediation in ESB, I should add that there is a third way to modify messages on the bus, that doesn’t go by the name of ‘mediation’: using a JAX-RPC handler. It’s only suitable for SOAP messages (which can be transported over HTTP or JMS), but is otherwise most similar to Platform Messaging mediations. The primary advantage of JAX-RPC handlers is that they are conformant to a JSR specification, but they aren’t able to do a number of things that mediations can, such as modify the target of a SOAP request.

You can find more information in this article on Developerworks.

In a previous post describing SCA in WebSphere ESB / Process Server, I wrote that SCA modules have to be running in the same address space. I’d like to correct this: the restriction actually imposed on these bindings is that they need to be between SCA modules running in the same WebSphere cell (see this post for more information on cells, nodes, and servers). This is because the SCA resources that are automatically created when an SCA module is deployed are cell-scoped. Different types of SCA resources are created depending on whether asynchronous or synchronous behaviour is required, which is normally decided automatically, but in both cases the scope is the same. For more information, see this Developerworks article.

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.

Working with WebSphere ESB recently has got me thinking about synchronous and asynchronous communication mechanisms. I began to wonder about a mechanism that’s more familiar to most people - text messaging - and how it plays a dual role in usage. Let’s recap first on two other communication mechanisms that more obviously fit into one category or the other (perhaps ironically, a modern mobile phone can do all of these, including text messaging):

• 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.