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.

WebSphere ESB performance tuning redpaper

A recently published redpaper draft titled WebSphere Business Integration V6 Performance Tuning provides some useful information for people wishing to set up, tune and configure WebSphere ESB, and WebSphere Process Server. It also documents some best practices for architecting your modules to gain maximum performance. These range from deciding how to get the right granularity for SCA components and modules, through to making judicious use of asynchronous versus synchronous invocations.

The paper is written by the WebSphere Process Server and WebSphere ESB performance test teams, including Paul, Sam and Rachel here in Hursley, so this is useful information straight from the people who know.

Talking of performance, we’ve been doing a lot of work recently on a couple of performance items for the next release of WebSphere ESB and the initial results look very promising.

WebSphere ESB for z/OS Redbook residency

As I mentioned earlier, WebSphere ESB for z/OS is now released. There is an IBM Redbook residency currently being advertised to write a getting started guide for both WebSphere Process Server and WebSphere ESB on z/OS.

Residencies are open to IBM and non-IBM employees and are a great way to increase your knowledge of these products, and to get your name in print! This residency is being run in Raleigh, North Carolina for four weeks starting on 23rd October. It is being led by a friend of mine, Martin Keen. More details and the application form are can be found on the IBM Redbooks site.

What is WebSphere ESB?

A lot of people will have heard IBM talking about ESB as being a pattern rather than a physical product back before the SOA related announcements made last year, so given that, why do we now have a WebSphere ESB product?

Well, an ESB still is a pattern describing the requirements for message routing, transformation and protocol translation amongst other things. WebSphere ESB is simply a product which can help to realise an instantiation of the ESB pattern, particularly when what you want to deal with is primarily XML sent over SOAP or JMS, and maybe a bit of integration with some back-end non-XML systems via adapters.

WebSphere ESB shares a common infrastructure with our WebSphere Process Server product, namely Service Component Architecture (SCA), Business Objects (Based on SDO) and the Common Event Infrastructure. All this sits on top of WebSphere Application Server.
The main functionality in Websphere ESB comprises the concept of a mediation module, a type of SCA module, which can contain a mediation component. The mediation component allows you to build up flows to handle the mediation of messages as they flow as requests or responses over the ESB. You get a set of pre-defined mediation primitives for things like logging, database lookup, XSL Transformations and content based routing. What's more you can write your own custom mediations in Java.

You can develop mediation components and their flows in the WebSphere Integration Developer tooling, and deploy them to both WebSphere ESB and WebSphere Process Server.

There's a whole lot more to be said, and I'll weigh in with more one this blog regularly. For now however, I'll refer to you some useful articles from IBM Developerworks: