Flexible Solutions on Oracle Middleware
  • A full array of business solutions
  • Intelligent telecommunication solutions
  • Area solution packages
Számítástechnika Magazine   |   2007-03-02
Services are not on their own - Service Registries

One of the major problems of service oriented (SOA) strategy-based enterprise IT infrastructures and operation models is creating and managing services property. Service registries provisioned with credentials can be well utilized in development times and for designing development projects as well as for defining dynamic services at runtime. By deploying it, information about what services we have available, what characteristics they have and where they are available can be obtained on a standard platform.

However, services to the developers and service owners are not displayed in stand-alone manner, but together with additional valuable pieces of information. Therefore we must also get an answer to questions like what rules should be adhered to when using a service, what best practices should be applied during developments or what framework systems are available. It is important to create a descriptive database, in which the deployable databases, development-and testing environments are included.
In our two-article series of articles we try and find the answer to the question of which tools can be used to remedy the above described problems, by also taking into account the different types of information.

AquaLogic Service Registry as a registry of services
An important element of a large-corporation SOA infrastructure is the service metadata repository, where we can store information required for using the services available in the system. – said Attila Horváth, Deputy Technology Director of Alerant Information Technologies Inc. The registry offers access to the data through a standard interface. UDDI (Universal Description, Discovery and Integration) is the specification that standardizes the description and publication of SOA distributed components. BEA AquaLogic Service Registry implements version 3.0 of the specification.
The tool provides a set structure for the otherwise ad-hoc process of inter-component interaction. Information needed for accessing the Web services can be written in the organization-defined taxonomy, thus ensuring that descriptions are uniform and easily retrievable. Data on the services, service-provisioning organization and technical details can be stored here. This defined way of description requires thoughtfulness equally from the company’s own developers and external vendors, which yields multiple returns later on.
Therefore AquaLogic Service Registry also functions as a service registry but it has an important role in operating the SOA infrastructure. It has the role of an intelligent routing tool in segregating the applications from one another at runtime. In the event of failure of a service, applications can have access to the replacement components through it. In addition, by its subscription and notification mechanism, it ensures that the applications using the service or the system administrators are notified about any changes in the metadata or service level of a service.

The Registry is capable of publishing a predefined stack of service metadata to any other registry, by which it ensures that new services are smoothly implemented in the production system on the basis of data stored in the test system registry. This feature is also suitable for publishing data to the UDDI register of partner companies.
An often raised concern with respect to distributed systems is security and access right restrictions. UDDI specification also had to find a solution to this issue, so it is for this reason that it supports the creation, administration and access rights maintenance of corporate, partner and public registers. AquaLogic Service Registry also caters for logging of queries from other registries and access right restrictions on data.
BEA’s Registry is integrated into BEA AquaLogic Enterprise Repository that supplements the scope of information stored with relation to the services. In development projects the repository is the storage place for collected documentation in addition to reusable products. We will have a closed look at this tool in our next article.