Exclusive: Systinet reins in Web service registries
Systinet Registry 6.0 does a good job of managing UDDI entities, but this SOA must-have carries a hefty price
At the outset, I should admit a bias: I’m a UDDI skeptic. Still, I’m willing to believe that maybe I just haven’t dug deeply enough into UDDI to see its real value. So, I was naturally eager to review the latest version of Systinet’s Web services registry.
Being a UDDI skeptic doesn’t make me a registry skeptic, however. Registries are a mandatory part of a functional SOA for three reasons. First, a registry acts as a “system of record” for the enterprise’s Web services -- the registry becomes the central reference for otherwise distributed and difficult-to-find services. Second, a registry is a place where providers can advertise services and consumers can discover them. And third, it’s a point of control for governing the availability of services, managing versioning, and ensuring compliance with enterprise and external requirements.
Systinet Registry 6.0 does all this in a platform that’s mature, stable, and polished.
I installed Systinet Server for Windows XP Service Pack 2 using JVM 1.5. The Systinet wizard makes installation painless: Out of the box, the registry uses the embedded Hypersonic SQL database to make setup easy, but it also supports Oracle, DB/2, Microsoft SQL, Sybase, and PostgreSQL for production use.
You may use Systinet Registry 6.0 in two primary ways. When developing a new service, developers can browse or search the registry to find services. This promotes code reuse and helps developers find services that are ready for production use.
Alternatively, an application can query the registry at run time to get end-point data for services it uses. In this mode, the product functions similar to a registry in any other RPC-style application, allowing services to be found by name instead of embedded end-point data.
Along with its two modes, Systinet Registry comes with two different consoles: the Registry Admin Console and the BSC (Business Service Console). The first is used to configure and manage the registry itself; for simple installations, it will rarely be used.
The second console is where Registry 6.0 provides real value to the enterprise -- and where I spent a good deal of my time. The BSC is the primary interface to the registry for developers, architects, and business users. Using the BSC, you can publish service descriptions and manage metadata about published services, indicating, for example, which are in development, which are in QA, and which are in production.
The BSC also supports the development-time activities of finding services using the console’s search and browse capabilities. As a convenience, users can register for notifications about the services in which they’re interested; when a service has been updated or its metadata has been changed, the user will receive notification either through the BSC interface, by e-mail, or via a custom call out configured using SOAP.
Systinet Registry’s reporting was adequate -- nothing eye-popping, but it gives you a good picture of registered services. Reports are canned queries on the metadata associated with services and can be customized.
Replication and Integration
Systinet Registry 6.0 can be used in a stand-alone mode, but many organizations will want to operate more than one registry in an effort to serve specialized needs.