Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

Chapter 10. Advanced Service Registry Configuration Options

10.1. Configure an Alternative JAXR Implementation

Procedure 10.1. Task

  1. Choose a specific JAXR implementation.
  2. Set the property to configure the class. (Because the JBoss Enterprise SOA Platform uses Apache Scout by default, this property is set to the Scout factory class, namely org.apache.ws.scout.registry.ConnectionFactoryImpl.)
  3. Configure the JAXR implementation by providing it with the Registry's location. Do so by editing org.jboss.soa.esb.registry.queryManagerURI, org.jboss.soa.esb.registry.lifeCycleManagerURI and org.jboss.soa.esb.registry.securityManagerURI.

10.2. Configure an Alternative API to JAXR

Procedure 10.2. Task

  • Write a new SystinetRegistryImplemtation class and provide a reference to it from within this property.

10.3. Using Transports

When using Apache Scout, you can set a special optional parameter: org.jboss.soa.esb.scout.proxy.transportClass. This is the transport class that facilitates communications between Scout and the jUDDI Registry.
If you are using Scout to communicate with jUDDI, leave the transport class as LocalTransport and configure the file to make use of the jUDDI registry's transports (InVM, RMI and WS). This file defines the Registry's nodes.

10.4. Node

A node is a location in the service registry.

10.5. Select a Transport

Procedure 10.3. Task

  1. Edit the node definition file: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml
  2. Use the node settings to select which transport to use:
    <node>
    	    <!-- required 'default' node -->
    	    <name>default</name> 
    	    <description>Main jUDDI node</description>
    	    <properties>
    	<property name="serverName" value="localhost" />
    		<property name="serverPort" value="8880" />
    	    </properties>
    	    <!-- JAX-WS Transport
         <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport>
    	    <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer?wsdl</custodyTransferUrl>
        <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry?wsdl</inquiryUrl>
        <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish?wsdl</publishUrl>
        <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security?wsdl</securityUrl>
        <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription?wsdl</subscriptionUrl>
        <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-listener?wsdl</subscriptionListenerUrl>
    	   <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</juddiApiUrl>
    	    -->
    	   <!-- In VM Transport Settings 
        <proxyTransport>org.jboss.internal.soa.esb.registry.client.JuddiInVMTransport</proxyTransport>
        <custodyTransferUrl>org.apache.juddi.api.impl.UDDICustodyTransferImpl</custodyTransferUrl>
    	    <inquiryUrl>org.apache.juddi.api.impl.UDDIInquiryImpl</inquiryUrl>
    	    <publishUrl>org.apache.juddi.api.impl.UDDIPublicationImpl</publishUrl>
        <securityUrl>org.apache.juddi.api.impl.UDDISecurityImpl</securityUrl>
        <subscriptionUrl>org.apache.juddi.api.impl.UDDISubscriptionImpl</subscriptionUrl>
        <subscriptionListenerUrl>org.apache.juddi.api.impl.UDDISubscriptionListenerImpl</subscriptionListenerUrl>
    	   <juddiApiUrl>org.apache.juddi.api.impl.JUDDIApiImpl</juddiApiUrl>
     	-->
    	<!-- RMI Transport Settings -->
    <proxyTransport>org.apache.juddi.v3.client.transport.RMITransport</proxyTransport>
    	<custodyTransferUrl>/juddiv3/UDDICustodyTransferService</custodyTransferUrl>
    	<inquiryUrl>/juddiv3/UDDIInquiryService</inquiryUrl>
    	<publishUrl>/juddiv3/UDDIPublicationService</publishUrl>
    <securityUrl>/juddiv3/UDDISecurityService</securityUrl>
    <subscriptionUrl>/juddiv3/UDDISubscriptionService</subscriptionUrl>
    <subscriptionListenerUrl>/juddiv3/UDDISubscriptionListenerService</subscriptionListenerUrl>
    <juddiApiUrl>/juddiv3/JUDDIApiService</juddiApiUrl>
    <javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial>
    	<javaNamingFactoryUrlPkgs>org.jboss.naming</javaNamingFactoryUrlPkgs>
    	<javaNamingProviderUrl>jnp://localhost:1099</javaNamingProviderUrl>
    	</node>
    
  3. By default, the Remote Method Invocation (RMI) settings are enabled. To switch transports, comment those ones out and enable the ones you want to use.
  4. Save the file and exit.

10.6. Remote Invocation Class

As its name implies, a remote invocation class is a class that can be called from a remote machine. This can be useful for developers but can also lead to potential security risks.

10.7. Transport Settings

When you configure a transport, you must specify the following items:
  • a proxyTransport
  • a URL for all of the supported UDDI application programming interfaces ( inquiry, publish, security, subscription, subscription-listener and custodytransfer)
  • a jUDDI application programming interface URL.
  • the RMI transport (which also includes JNDI settings)

10.8. Configure Apache Scout

Procedure 10.4. Task

  1. Check that the transportClass is set to LocalTransport in the uddi.xml file.
  2. Configure the uddi.xml file to utilize the Registry's transports (these being InVM, RMI and WS, respectively). The file is located in SOA_ROOT/jboss-as/server/all/deploy/jbossesb.sar/esb.juddi.client.xml
  3. Create a schema in the jUDDI registry by adding the jbossesb publisher to it.

    Note

    The product/install/jUDDI-registry directory contains database-create scripts for most common databases. These files are located in SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi-sql.

    Note

    The system can generate the database automatically if the user has been granted permission to create tables. (The Registry can create a database of any type for which there exists an associated Hibernate dialect.)
  4. Check that the SOA_ROOT/jboss-as/server/default/deploy/jbossesb-registry.sar/esb.juddi.xml and SOA_ROOT/jboss-as/server/all/deploy/jbossesb.sar/esb.juddi.client.xml exist. These files contain the Registry's configuration settings.

    Note

    If you want the software to communicate with another UDDI registry, use Apache Scout's JAXR transports. There are four implementations of this class and they are also based on SOAP, SAAJ, RMI and Embedded Java.
  5. If you decide to change the transport, always change the query and life-cycle uniform resource indicators as well. Here is sample code that demonstrates how to do so:
    SOAP
    queryManagerURI	http://localhost:8080/juddi/inquiry
    lifeCycleManagerURI	http://localhost:8080/juddi/publish
    transportClass		org.apache.ws.scout.transport.AxisTransport
    
    RMI
    queryManagerURI 	jnp://localhost:1099/InquiryService?org.apache.juddi.registry.rmi.Inquiry#inquire
    lifeCycleManagerURI 	jnp://localhost:1099/PublishService?org.apache.juddi.registry.rmi.Publish#publish
    transportClass		org.apache.ws.scout.transport.RMITransport
    
    Local
    queryManagerURI	org.apache.juddi.registry.local.InquiryService#inquire
    lifeCycleManagerURI	org.apache.juddi.registry.local.PublishService#publish
    transportClass		org.apache.ws.scout.transport.LocalTransport
    

10.9. Interceptor

Interceptors are used by the Service Registry to intercept requests. They are stored in an interceptor stack. Each interceptor in a stack can do the following things:
  • service the request
  • provide direct responses to the request
  • augment the responses received from a lower interceptor or registry implementation
There are two interceptors provided in the current implementation.

10.10. The LocalRegistryInterceptor

The LocalRegistryInterceptor is the class that is responsible for processing local services.

10.11. Configure the Interceptor Stack

  1. Open the global configuration file in a text editor: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml.
  2. Modify the org.jboss.soa.esb.registry.interceptors properties.
  3. Save the file and exit.

10.12. Interceptor Settings

Table 10.1. Interceptor Properties

Property Description
org.jboss.internal.soa.esb.services.registry.InVMRegistryInterceptor
The InVM registry interceptor is responsible for handling any InVM end-point references. These are registered by any of the services executing within the same server instance. The information about the InVM EPR and its associated service will be cached within the interceptor, will not be propagated to subsequent interceptors and will be returned to the caller by augmenting results from subsequent interceptors or registry queries.
org.jboss.internal.soa.esb.services.registry.CachingRegistryInterceptor
The caching registry interceptor retains a cache of end-point references and their associated services, evicting information from the cache on a LRU basis or after the information has expired.
The interceptor can be configured through the org.jboss.soa.esb.registry.cache.maxSize and org.jboss.soa.esb.registry.cache.validityPeriod properties within jbossesb-properties.xml