One of the key issues with SOA is how an organisation can make the most of the reuse potential. Some commentators are already pointing out that this is harder than it seems – we didn’t always get it right with OO, so how can we make it work at the higher level of technical and business services? One project team will want a slightly different flavour of service, or feel better if they wrote it themselves; and there are issues around SLAs when services are shared between multiple consumers. These discussions are at the heart of IBM’s focus on SOA Governance. Making SOA work does require planning, and a strong degree of buy-in across an organisation.
The new WebSphere Service Registry and Repository plays a central role in the swathe of SOA-related announcements this week. The product became generally available last week, and in my days off this week I’ve been installing and playing with it to get a hands-on feel for how it all works (how’s that for commitment!).
WSRR acts as the master repository for all metadata about services within an organisation. It has features to record different versions of service metadata. Developers can discover services at build time, and applications can find updated information about services at runtime. WSRR itself is deployed as an application into the WebSphere Application Server runtime.
As a WebSphere Message Broker fan, I’m obviously particularly interested in the timely new Supportpac that provides support for WSRR. The SupportPac is category 1, which means that you will need to contact IBM to obtain it. The package provides a number of nodes and the corresponding Eclipse plugins to enable Message Broker applications to query the repository and receive event notifications. It also provides a runtime cache for the broker, which stores repository information. Once I’ve got it installed and worked with it a little more, I’ll report back.