Things have really been underway at Bea since mid 2005. Along with the company’s new design and slogan “thing liquid”, a new product family was born with the name “AquaLogic”. One key part of it is the AquaLogic Service Registry. It is a central service registry, which is used in service infrastructures.
Service-oriented infrastructures for revolutionizing companies’ IT. SOA-based applications should no longer be individual, monolithic constructs, but rather should be able to be composed and recomposed using individual services. Besides the question as to what the motivation and modeling of the company-wide services are, the other main challenge lies in mastering the technical complexity of the project. Previously, this mostly meant finding a suitable way to interconnect services, creating new applications and supporting a loose coupling. The Enterprise Service Bus products have already assumed these tasks. Yet, they do not deal with the organization and management of the quantity of individual services. A central registry is required for doing so, which contains all of the relevant service information. Ideally, such a registry not only supports the simple finding of services, but the entire lifecycle of the services. Including the registration of functional requirement definitions to the implementation using the corresponding technical conversion details. The AquaLogic Service Registry (ALSR) will assume this task within the Bea SOA world. Technically, ALSR is merely a conversion of an UDDI (Universal Description, Discovery and Integration) registry in version 3. The UDDI specification is based on different standards (HTTP, XML, XSD, SOAP and WSDL) and describes a registry of services, including the corresponding interfaces. This enables a comprehensive description of each managed service to be stored in the registry. The so-called meta data describes the function context (“businessService”), the functional origin (“businessEntity”), as well as the actual technical interfaces to access and manage (“bindingTemplate”) the service. Additional information on the access rights, transport methods, categories and other classifications (“tModelS”) complete the description. All of the data is stored in a corresponding data model in the registry based on XML. Anyone needing the information can then retrieve it from ALSR using Web services (see figure 1).
Figure 1. Placement of the service registry in an SOA world.
The latest member of the AquaLogic family is not founded in Bea’s own development. The Systinet Registry (version 6.0) was actually purchased into the product family in an OEM contract. Which means, that users do not have to work their way through an earlier version (2.0) before using the product. Interesting as well is the fact that Systinet itself was purchased by Mercury in February of this year. This purchase does not initially affect the bundling of the product within the AquaLogic family, since Bea has been working with Mercury in the field of monitoring and profiling since the beginning of the year. Starting with JDK 5 release 26 of the Bea JRockit, the Mission Control Suite now includes a limited version of Mercury’s “Diagnostics” product. How and if the product “Service Registry” will be developed after the takeover is not clear at this point. However, the cooperation between the two companies seems to be going well.
Bea has provided developer sites for initial work with the new Bea product. These are organized in a “Product Center”, where information can be found on almost all Bea products. The AquaLogic product center can be accessed at the click of a button. However, the product center only provides direct access to a number of marketing material. Links to downloads of the developer versions and online documentation can only be found after longer searches. Providing the developer versions in such a manner is unfamiliar for “spoiled” developers. Instead of an installer for the required target platform, only a 60 MB Java archive (jar file) is delivered for the entire platform. Without additional support, the user ends up in the deeper levels of the product documentation and realizes that he/she will need more than just a few minutes for the installation and configuration, which is unusual for Bea. The user is supposed to start with the so-called “Standalone Registry”. An installer has to be opened to do so. This can be done using command line with java -jar Bea-aqualogic-service-registry-2.0.jar. Under the assumption that the user has JDK 1.4 or a later version, a clear, menu-driven installation dialog is started. At first, this dialog overwhelms the user with the number of options. However, if the user limits him/herself to the named installation variant and the use of the internal Hypersonic SQL database, the user can access their target in 9 steps when additional information is entered. The registry can then be started using <REGISTRY_HOME>/bin/serverstart.bat. This starts the Systinet service for Java and not Weblogic. The ALSR administration console can be accessed through http://<host>:<port>/uddi/web.
The user could leave it at that. The Service Registry is now completely ready for use. However, if the user does not want to implement a new server product into the infrastructure and would prefer to use an existing Weblogic server (WLS) with the application, then additional steps will be necessary. First, the set-up tool (<REGISTRY_HOME>/bin/setup.bat) has to be opened. In the “Portation” option, the product can be ported to a WLS 8.x or .9. A few more settings and entries have to be made here as well. A Web application archive (WAR file) is then stored in <REGISTRY_HOME>/conf/portation/weblogic/build after a few dialog steps and a confirming click. However, this only works if none of the previously installed servers have been started. Otherwise, the system will issue an error message. Finally, a new service instance (WLS domain) has to be generated, the start script of the WLS expanded to include parameter "Djava.security.auth.login.config= and the WAR file deployed to the WLS. If the SSL functionality of the WLS is still active, the AquaLogic Service Registry can finally be used in an WLS instance via
<REGISTRY_HOME>/conf/jaas.config"https://<host>:<port>/<context>/uddi/web. This is a rather long and inconvenient method. We can only hope that BEA provides its own installer with the next version, making the Systinet Registry closer to a company’s internal server than is now the case.
Figure 2. The web-based administration console of the AquaLogic Service Registry.
Following the installation of the ALSR, a pre-defined registry will be available and will contain demo data. The demo data contains two example scenarios, which are meant to demonstrate the use of the Business Services console and the Registry console. The sample data records provide a good first look at the interaction between the functional requirements, services and technical implementation, as well as the set description. The appendix of the manual also include four different demo scenarios, which explain topics such as the programmatic use of the registry. Programming examples in the source code can be found under <REGISTRY_HOME>/demos/.
The AquaLogic Registry deals with the central registration and management of Web services. The developers first register them in the registry. A release mechanism can then be started using the workflows. In doing so, new or changed entries are forwarded to an administrator for release. If an administrator logs on to the registry, he/she will be directly shown the corresponding requests: together with all relevant information, such as for the technical conversion (bindings and interfaces). Once released, the Web service can be published and located and used by other users. Users can subscribe to be notified about changes to a service in “Subscriptions”. The system will then send the subscriber an e-mail about any changes. The BSR provides optimal support for developers when entering necessary data in the registry. In contrast to other products, the user is no longer dependent on the use of complex programming steps, thanks to the user-friendly screens. In addition to BSR, any other UDDI browsers can also be used in the registry and their contents accessed. The package is rounded off by a workflow system with defined release mechanisms. This means, that the defined services are not merely managed, but can be quality-secured using corresponding processes. In order to avoid conflicts between developers and production when dealing with such rules, it is recommended that companies have at least two different ALRS instances. One for developers, to register new Web services and have them approved, and a productive instance for searching and using Web services. Different update procedures will either transfer a part of the data or an entire dataset from the developers registry to the productive registry. This also enables the management of service data for major installations. To ensure that the security of the data exchange, all communication is done via https. Corresponding SSL certificates need to be set up in the instances for doing so.
The administration of the ALSR is entirely web-based. Once logged on to registry console http://<host>:<port>/uddi/web, the administrative user will be displayed the menu item “Manage”. This item can be used to adjust the relevant settings for the registry. The only limitation is the selection of the user memory. The set-up tool can be used to select either LDAP or database. However, the relevant considerations will have to be made before installing and generating the deployable Web application for the Weblogic. The administrative tasks (contents, release, users and authorizations, etc.) are usually performed using this access. An incremental tour through the contents provides in-depth support and can be started directly from the console.
The Business Service console can be started from http://<host>:<port>/uddi/bsc/web. It offers access to the saved data of the individual services, thus providing the interfaces for the actual catalog functions. New services can be created using the publishing wizards. Moreover, additional information on the individual services can also be stored and processed. An incremental tour through the contents is also provided, with in-depth support.
A few of the registry functions can also be accessed through the command line. The corresponding tool can be found under REGISTRY_HOME/bin/PStoreTool.bat. A rather comprehensive description can be found in the product documentation. The use of this tool should for script controlling should only be necessary in cases of exception.
There is also another tool, which may be of interest for developers. The SOAPSpy tool works as a proxy between the client and server and allows the contents of Web services messages to be displayed. A absolute blessing for suffering Web service developers. This little helper can be found under REGISTRY_HOME/bin/SOAPSpy.bat.
And whoever carefully reads the developer sections of the ALSR documentation will also find information on an Eclipse plug-in, which is supposedly available. Unfortunately, the documentation does not specify where it can be found. Neither can it be found in the installation registry of the ALSR. Nor does searching the Bea developer sites provide any real insight into the matter. The Bea download sites are also of no use in the matter. With some knowledge of the origin of the product, the user can finally locate it, where it would never be expected. It can be found in the manufacturer’s site under the name "Systinet Developer for Eclipse 6.0" . Yet again, the few pages on the use of the plug-in provided in the ALSR documentation is the only information available on its use. Expanding the 43MB ZIP file after downloading does reveal some known parts from Eclipse. Which is also why the plug-in and feature files can be easily copied to an existing Eclipse installation. The included start file also adds Eclipse to the developer screen. This time, it includes a large quantity of new functions for the Service Registry (see figure 3). The included assistants enable the registry functions required by the developers to be accessed from Eclipse. This includes the searching and generation of class skeletons for developing Web services and clients. Whoever considered the previous approach to be excessive and difficult when developing and managing services, will be more than satisfied with the Eclipse plug-in. The use of Web interfaces is thus eliminated, at least for developers, and users can easily get used to the few new clicks thanks to the known concepts. Keywords or unique keys enable access to the descriptions of the services stored in the registry. This also enables the creation of new clients or even new services. The Eclipse integration can also be used to register newly-created services directly in the ALSR. Why Bea does not provide the plug-in and whether it will be included in a new version of the Weblogic Workshop is not currently known. However, it would be a good idea. Bea could at least provide a small reference to it on the Bea websites. It would at least prevent some unnecessary searching.
Figure 3. The Eclipse plug-in by Systinet for developing clients and Web services.
The Weblogic administration console is the least important aspect for ALSR. It can, of course, be accessed through http://<host>:<port>/console. Unfortunately, it is no longer needed following the one-time deployment of the ALSR, since ALS does not use a specific WLS function.
With the Systinet Registry, Bea has introduced a first-class UDDI registry into the AquaLogic product family portfolio. The Systinet Registry is currently the best UUDI registry on the market. The user-friendly interfaces, well thought-out processes and the stabile application core with refined programming interfaces not only makes development fun, but also gives the product the necessary added values when used in service infrastructures. It is only too bad, that an in-depth demo application is not available. However, the integration into a service-oriented architecture, with corresponding development processes and interaction between the other products of the family, would be welcome.
