IBM WebSphere Registry/Repository and Interop with .NET

  • Article

What are the interop options for connecting .NET applications to IBM's registry product, the IBM WebSphere Service Registry and Repository?

I just saw a piece by Anne Thomas Manes of the Burton Group, saying that

IBM has taken a risk by releasing a registry/repository product that does not support the prevailing standard, Universal Description, Discovery and Integration (UDDI). This move implies that IBM desires to provide an all-inclusive, lock-in solution. [emphasis added] One of a registry’s primary functions is to enable information exchange among heterogeneous SOA infrastructure components. Without UDDI support, the IBM registry will only enable information exchange among products that support the proprietary WSRR programming interfaces. To make the most of IBM’s SOA governance solution, an enterprise must adopt the complete WebSphere/Rational/Tivoli product line.

Could This Be True? 

Is it really true that the only way to connect to the IBM WSRR product is through tightly-coupled approaches - programming interfaces ??  That can't really be true, right?   Surely there is a service (network) interface for this thing, and we just don't know about it.  It ought to be defined in WSDL I would hope?  In an effort to shed some light on this, I looked in the online library for IBM WSRR and found this information:

WSRR supports two kinds of API that can be used to interact with WSRR. One is Java based and the other is SOAP based. Both support publishing (creating, updating) service metadata artefacts and metadata associated with those artefacts, retrieving service metadata artefacts, deleting the artefacts and their metadata, and querying the content of WSRR.

Basic CRUD operations as well as governance operations and a flexible query capability based on XPath are provided through both APIs. When the SOAP API is used, content is communicated using XML data structures; when the Java API is used, content is communicated using SDO data graphs.

Elsewhere in the same documentation set, I found this:

The WSRR API is made available as several Stateless Session Beans, with both local and remote interfaces.

Hmm, now I don't know if you all "speak Java" but what that statement says to me is, any application can access the WSRR metadata, as long as it is (a) a Java application, and (b) is either a J2EE application running inside the WebSphere Application Server, or is a Java app (running outside the websphere container) using the IBM-provided JAR files and programming interfaces for the WebSphere client runtime. 

Still elsewhere, I found this:

In order to use either of the clients, you must add the required jar files to your runtime:

  • sdo-int.jar (this must be as high up the class path as possible to override SDO 1 interfaces)
  • ServiceRegistryClient.jar
  • A suitable EJB [or] Web services runtime

There is also some sample code which I have not shown that uses the classes defined within the WSRR jar file (ServiceRegistryClient.jar). So yes, it does appear that only Java applications can connect to this IBM registry.  Very surprising.   This is what Thomas-Manes at Burton is saying when she uses the words lock-in solution to describe IBM's WSRR.   For me, IBM's WSRR doesn't qualify as a pratically useful SOA repository, if by "SOA" we mean to imply, an architecture that supports heterogeneous applications connected loosely via service interfaces. 

Could we get there from here?

Could WSRR possibly serve as a SOA Repository, in support of the goals of heterogeneity and interoperability, of interconnecting loosely-coupled apps? Sure! But it would need to be based on standard schema and protocols.

If in the future IBM unilaterally creates and documents a WSDL/SOAP interface for IBM WSRR, it would still be an IBM-defined protocol, an IBM-defined schema, an IBM contract.  That would make it IBM's interface, not a standard one, though it may be based on lower-level standards like WSDL, SOAP and XML. 

Those in Glass Houses?....

I guess you could say, those interfaces (we are only imagining they might be created at this point) would be analogous to the web service interfaces that are defined for Microsoft Office - for example for the Research services.  MS Office defines a WSDL and Schema for any Research Service.  It is interoperable, and I have shown Java apps acting as Research Services for MS Word 2003. But the interface itself is non-standard. That is to say, Microsoft defines it unilaterally.

Somehow that situation seems ok, while the situation with IBM defining the interface for its SOA Repository seems inappropriate. HAhahahaha!  I find this very challenging terrain to travel over. (I understand my view here may be due to a biased perspective, but I am trying hard to guard against it.) The Research Service interface for MS-Word is a feature of the product. MS Word was not designed to be the center point of a SOA infrastructure, as would a SOA repository. MS Word can best be thought of as an endpoint or end-node in a SOA mesh, and the research service interface is just one small artifact that affects that end-node, not the entire mesh.   Furthermore, the Research Service interface is small and simple, in comparison to the richer interface you'd need for a SOA repository.  Because of all this, the MS-Office Research Service interface need not be an internationally sanctioned standard, while it seems to me that because a SOA Service Repository does play that central role, and is a much more complex service, it ought to have network interfaces that are based on multi-vendor standards. Is this hypocrisy? I don't think so.

No Interop Here

To get back to my original question, What are the interop options for connecting .NET applications to IBM's registry product?  -- the answer appears to be:  you cannot connect to the IBM WebSphere Service Registry and Repository unless you link in IBM's libraries and runtime, and that means the app itself must be a Java application.  No .NET, no PHP, no non-Java or even non-IBM-Java apps allowed.

Remember this is all based on my reading the docs. I haven't tried or tested the IBM product.

The lack of interoperability for chunks of infrastructure from major vendors leads me to conclude that this category - specifically, SOA service registries useful for design, deployment, management and governance - is not yet quite ripe.