SCA 1.0 specifications released

The Open SOA organisation have released Version 1.0 of the Service Component Architecture specifications. OSOA is a collaboration of a number of vendors, including IBM, who are aiming to produce a language neutral programming language for SOA infrastructures. The initial seed for the work was based on work done at IBM to produce the programming model we have today in WebSphere Process Server and WebSphere ESB, and which was then made public in collaboration with BEA and then the now 18 strong OSOA group. The work to produce 1.0 specifications represents a significant evolution of the SCA architecture in a number of areas, not least of which is the introduction of additional language/component implementations for not only Java but Spring, BPEL and C++ as well .

There have been a fair few people at Hursley working on various parts of the specifications, especially around the JMS Bindings, C++ implementation and the policy framework, so congratulations to them especially.

An important and very encouraging aspect of the news today is that the SCA specifications will be contributed to OASIS for future development. Formalising them through such a standards body will help to drive their adoption. If SCA is a programming model for SOA, then SDO is the data model, and that too has been given an (old) new home in the JCP.

More coverage at TSS, eWeek, and Dana Gardner (ZDNet).

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.

New IBM SOA book, newsletter and conference

Sandy Carter, the VP of SOA and WebSphere Strategy at IBM has a new book available entitled The New Language of Business: SOA and Web 2.0. Details are available via the IBM Press site, along with a 35% discount code. The book covers the IBM roadmap for SOA and Web 2.0, illustrated with over 40 customer case studies and interviews with analysts and industry leaders. My copy is on its way, so I’ll blog more when I’ve read it, but for now you can access a sample chapter.

Additionally, IBM have just launched a new online SOA newsletter, which will be produced on a regular basis, containing articles and case studies. You can subscribe to receive it via email. The current issue contains a link to the Impact 2007 conference, being held in Olando, Florida on May 20-25th. Impact is the conglomeration of the annual WebSphere Technical Exchange and Transaction & Messaging conferences, and also a conference for our Inner Circle customers. Impact will also be held in Europe later in the year.

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.