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.

Systinet Registry 6.0
Systinet, systinet.com
|
Very Good 8.1 |
 |
| criteria |
score |
weight |
| Interoperability |
8 |
20% |
 |
| Manageability |
9 |
20% |
 |
| Reporting |
7 |
15% |
 |
| Scalability |
9 |
15% |
 |
| Security |
8 |
10% |
 |
| Setup |
9 |
10% |
 |
| Value |
6 |
10% |
 |
|
 |
Cost: Typical installation starts at $40,000 to $80,000
Platforms: Red Hat Enterprise Linux 2.1; Solaris 9; Microsoft Windows 2003 Server, Windows 2000, Windows XP
Bottom Line: Systinet Registry 6.0 provides a solid platform for building SOA governance and establishing a system of record for enterprise
Web services. Registry 6.0 will provide ROI to organizations looking to manage a diverse set of Web services across different
groups and versions — but it’s pricey, especially for smaller businesses.
|
 |
About our Reviews and Scoring Methodology
|
|
|
|
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.
Registry Basics
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.