Coming to a close in Rochester

I’ve one morning of meetings left before I head back home on Friday, landing back in England on Saturday morning. It’s been a very good week. Most of it has been spent in a room with three of us, including a guy from our research lab in Haifa, Israel. We’ve been having lots of discussions about how we might want to integrate some research technology into WESB/WPS, pulling in various other people along the way to offer advice and answers to our questions, including Billy. Unfortunately, I had to be elsewhere during that meeting, so didn’t get the chance to get introduced. Things went so well that we managed to produce a pretty functional prototype.

Today I drove up Highway 52 to Minneapolis to visit a couple of customers. First up was a customer currently in the process of evaluating their needs for an ESB. I took them through a technically-biased introduction to WebSphere ESB, and some good discussion ensued. One refreshing thing about this meeting was that there was no projector, meaning I spent an hour and a half talking with them rather than presenting to them. It is surprising how much more interesting this makes the session, and certainly promotes two-way interactions. We did duck out with some of the developers in the audience at the end to another room so I could show them the WebSphere Integration Developer tooling.

The second meeting was slightly different in that the customer has another vendor incumbent, and it was more of a level-set on our SOA and ESB strategy, covering what we see as being the necessary capabilities of an ESB. For this one I did use a deck purely because there was so much more to cover in terms of introducing WebSphere ESB, Message Broker, Datapower and supporting products such as Datastage TX, WebSphere Service Registry and Repository and IBM Tivoli Composite Application Manager for SOA. This meeting was very, very interactive – probably a result of the audience having a greater business and architecture bias. We had some good discussions about some of their explicit requirements around issues such as how batch and file transfer fits into the bus, if at all.

On a lighter note, I spent a couple of hours after the meetings wandering around the Mall of America by Minneapolis/St. Paul airport. MOA is the largest shopping mall in the USA, and it’s certainly impressive. I was surprised to find a mini-theme park inside complete with a couple of rollercoasters. It also has an underground aquarium along with more restaurants than you could hope to eat in. The usual array of shops were present, including an Apple Store 😉 I resisted the temptation to buy anything, after all, I’ve got a wedding coming up!

The weather today has warmed up a bit from earlier in the week when it was colder than I’ve ever experienced before. Listening to one weather report on Tuesday morning it was -13C, which is probably not that cold, but it felt like it to me! Places in the far North of the state were -18F (-25C), which doesn’t even bear thinking about! I’m surprised at how quickly I got used to the cold though, and I suspect it is just one of those things you get used to out here.

WebSphere related posts Yahoo pipe

I’ve been playing with Yahoo Pipes again, this time for something a bit more useful.

There are a number of blogs from IBMers here in the UK which cover WebSphere related topics at varying degrees of frequency. Some are solely WebSphere related whilst others talk about all sorts of subjects including WebSphere.

The WebSphere related posts from UK IBMer blogs pipe takes the feeds from a number of these blogs and uses the content analysis module to filter only the WebSphere related posts into one convenient feed. It currently takes input from the following blogs:

This is not an exhaustive list of the possible bloggers, but is a start. If you think a blog should be added, let me know. This pipe could easily be cloned to add feeds for other IBM software brands as well.

What would be really nice (if the folks at Yahoo Labs are listening) is if the fetch module could take a URL input that pointed to an OPML file such as the one maintained by Elias Torres. Then you could imagine a configurable pipe with a text input that fed into the filter meaning you could filter on all sorts of topics such as Second Life for example.

WebSphere ESB 6.0.2 released

WebSphere ESB 6.0.2 (along with WebSphere Process Server 6.0.2 and WebSphere Integration Developer 6.0.2) is now generally available. Existing customers can learn how to download the product from Passport Advantage here (just click on the link for the platform you require.) I’ve discussed some of the new functionality on this blog before, but you can now also access the Infocenter documentation, including a section on what’s new.

WebSphere ESB 602: Administrative dynamicity

In WebSphere ESB 6.0.1, the amount of post-deployment administration you could carry out was limited to the ability to view module import and export details, and the capability to modify the target of an import with an SCA binding. Within WebSphere ESB 6.0.2 we have greatly improved the influence the administrator can have on a deployed mediation flow in two ways.

The first of these is to extend the ability to re-target endpoints to include Web Services endpoints. Thus, an administrator can override the endpoint URL for SOAP/HTTP and SOAP/JMS endpoints. This administrative capability is in addition to the new dynamic endpoint selection functionality I’ve already talked about and is more static in nature. You might ask which one takes precedence and the answer is any endpoint dynamically selected by the mediation flow.

More significantly, we’ve introduced the concept of module properties. An Integration Developer can now opt to promote certain properties of primitives within the mediation flow up to the module, where they will be exposed for viewing and modification by the administrator post-deployment. This leads to a number of interesting possibilities, from being able to make small changes to the behaviour of the flow such as whether or not a Message Logger logs within a global or local transaction, to more creative uses which can have an effect on the outcome of the flow. The combination of administrative properties, the Message Element Setter and a Message Filter primitive is a prime example of a possible application of the latter.

WebSphere ESB 602: Dynamic Endpoint Selection

Apologies for the delay in producing the next in this series of posts outlining the new functionality coming up in WebSphere ESB 6.0.2. However, I’ve got a few cycles to spare so I’m going to try and get the rest of them done in short order.

One of the big questions we get on WebSphere ESB is how can you dynamically select the endpoint to invoke from within a mediation flow? In 601 you are limited to defining imports for all the endpoints you may wish to invoke and then using the Message Filter primitive to route to one of them. Whilst this works, it isn’t very dynamic. If you want to add an endpoint then you need to go back to tooling and then redeploy.

Re-tooling and deployment may be acceptable if the interface of an endpoint has changed as you may well need to update the contents of the flow accordingly (for example by changing a transformation) but is overkill in the simpler case whereby the interface remains the same but you just want to change the endpoint the message is sent to. Just such a scenario was the basis for a Developerworks article by Greg Flurry.

The dynamic endpoint selection capability in WebSphere ESB 6.0.2 will solve this issue by allowing you to augment the Service Message Object during mediation with information on the endpoint that you want to invoke. So the next question is then how do you determine the endpoint?

Well, you could use the existing Database Lookup primitive or a custom mediation, but more interestingly you can also use a new primitive available in 6.0.2, funnily enough titled Endpoint Lookup. The interesting thing about the Endpoint Lookup primitive is that it interfaces with the WebSphere Service Registry and Repository. As such, you can configure the primitive to look up endpoints based on port types, versions and even perform more complex queries based on the ontology you’ve defined within your registry. The registry may return zero, one or more results which you can then select from using a variety of methods, for instance a combination of Message Filter and Message Element Setter.

All this works for endpoints using the SCA native bindings or SOAP/HTTP and SOAP/JMS.

WebSphere ESB 602: Event Emitter

Event Emitter primitive

The Common Event Infrastructure is a core part of the runtime that WebSphere ESB and WebSphere Process Server are based on. The CEI runtime allows you to generate business or IT level events and persistently store then for consumption by monitoring tools such as WebSphere Business Monitor. The event format is defined by the Common Base Event model.

Currently in WebSphere ESB 6.0.1 you can generate CEI events when exports and imports are invoked. With the Event Emitter primitive in 6.0.2 you will be able to generate your own events from within a mediation flow, which can embed any information from within the Service Message Object.

A typical use of the Event Emitter primitive would be in conjunction with the Message Filter primitive to generate a business event when an exceptional situation is discovered based on the content of the message being mediated.

WebSphere ESB 602: Message Element Setter

Message Element Setter icon

In the first of a series of posts on the new functionality coming up in WebSphere Enterprise Service Bus 6.0.2, I’d like to introduce one of our new mediation primitives: the Message Element Setter.

The job of this primitive is to provide you with an easy way to set a particular part of the message with a value. Previously, the only way to do this would be to utilise the XSLT primitive with a very simple XSLT function, or to use a custom mediation primitive. Both of these are pretty heavyweight for such a simple job, and so the Message Element Setter was born.

Very simply, you can configure the primitive to set any part of the Service Message Object, specified via an XPath, with a value of a particular type. In addition, there are two special types of setter: the copy and delete. Copy allows you to copy part of the SMO from one place to another, and delete obviously allows you to delete the value of the part of the SMO you specify.

WebSphere ESB 6.0.2 Announced

IBM have today announced the forthcoming release of WebSphere Enterprise Service Bus 6.0.2, along with new releases of WebSphere Process Server and WebSphere Integration Developer. All will be released electronically on 22nd December, or 19th January 2007 on physical media.

I’ll be highlighting the new features in WESB 6.0.2 in a number of forthcoming posts, but to give a short rundown you can expect:

  • Greater dynamicity – e.g. the ability to dynamically reconfigure endpoints, ability to view and modify mediation primitive properties after deployment via the admin console/commands.
  • Dynamic service selection – ability to select an endpoint based on some criteria for example by using the Database Lookup primitive, or the new Endpoint Lookup primitive which interacts with the WebSphere Service Registry and Repository.
  • New mediation primitives – Message Element Setter for directly setting parts of the SMO without the need to use XSLT. CEI Emitter for outputting Common Business Events from within a mediation flow to feed directly into WebSphere Business Monitor.
  • New bindings – Connect directly to native WebSphere MQ queues, and MQ JMS rather than using MQLink. Provided data bindings for all JMS message types.
  • Usability improvements – easier configuration and administration, especially for clusters.
  • Performance improvements – across the board performance improvements

That’s a lot of new function, and on top of all that you now also get the WebSphere technology adapters bundled in as well.

WebSphere Service Registry and Repository

Apologies for the lack of posts over the last couple of weeks, but my blogging has suffered as it’s been particularly busy at work recently.

Talking of which, IBM is gearing up for our big SOA launch and announcements on October 9th, and after that I’ll be using this blog to start to discuss some the the ESB related aspects of what we will be announcing in more detail.

One thing that sneaked out in advance of the launch is the first release of our new WebSphere Service Registry and Repository. WSRR provides the tool to tackle one of the thorny issues of SOA, namely the management of metadata. At the most basic level services require description of what they provide, and WSRR provides the repository to hold these enabling your ESB to dynamically discover and route to these services. WSRR extends beyond the like of UDDI to enable management of much more than WSDL. It can manage arbitrary XML, XSD, BPEL and SCA metadata for instance.

However WSRR provides much more than a simple repository by enabling you to define relationships and categories of services, the data they use and much more into an ontology which is relevant to your business. Features such as impact analysis enable you to quickly identify what impact changes to a service will have.

All this helps to tackle the issue of SOA governance. If you can use WSRR to hold the definition of services within an organisation and use a meaningful categorisation scheme then you can go a long way to fostering an environment in which your SOA implementation can deliver on the promise of reusable business services.