JUDDI Registry Guide
This is a guide to using the service registry for developers.
Edition 5.3.1
Abstract
Preface
Chapter 1. Preface Copy linkLink copied to clipboard!
1.1. Business Integration Copy linkLink copied to clipboard!
1.2. What is a Service-Oriented Architecture? Copy linkLink copied to clipboard!
A Service Oriented Architecture (SOA) is not a single program or technology. Think of it, rather, as a software design paradigm.
Note
1.3. Key Points of a Service-Oriented Architecture Copy linkLink copied to clipboard!
- the messages being exchanged
- the agents that act as service requesters and providers
- the shared transport mechanisms that allow the messages to flow back and forth.
1.4. What is the JBoss Enterprise SOA Platform? Copy linkLink copied to clipboard!
1.5. The Service-Oriented Architecture Paradigm Copy linkLink copied to clipboard!
- Service Provider
- A service provider allows access to services, creates a description of a service and publishes it to the service broker.
- Service Requester
- A service requester is responsible for discovering a service by searching through the service descriptions given by the service broker. A requester is also responsible for binding to services provided by the service provider.
- Service Broker
- A service broker hosts a registry of service descriptions. It is responsible for linking a requester to a service provider.
1.6. Core and Components Copy linkLink copied to clipboard!
1.7. Components of the JBoss Enterprise SOA Platform Copy linkLink copied to clipboard!
- A full Java EE 5-compliant application server (the JBoss Enterprise Application Platform)
- an enterprise service bus (JBoss ESB)
- a business process management system (jBPM)
- a business rules engine (JBoss Rules)
- support for the optional JBoss Enterprise Data Services (EDS) product.
1.8. JBoss Enterprise SOA Platform Features Copy linkLink copied to clipboard!
- The JBoss Enterprise Service Bus (ESB)
- The ESB sends messages between services and transforms them so that they can be processed by different types of systems.
- Business Process Execution Language (BPEL)
- You can use web services to orchestrate business rules using this language. It is included with SOA for the simple execution of business process instructions.
- Java Universal Description, Discovery and Integration (jUDDI)
- This is the default service registry in SOA. It is where all the information pertaining to services on the ESB are stored.
- Smooks
- This transformation engine can be used in conjunction with SOA to process messages. It can also be used to split messages and send them to the correct destination.
- JBoss Rules
- This is the rules engine that is packaged with SOA. It can infer data from the messages it receives to determine which actions need to be performed.
1.9. Features of the JBoss Enterprise SOA Platform's JBossESB Component Copy linkLink copied to clipboard!
- Multiple transports and protocols
- A listener-action model (so that you can loosely-couple services together)
- Content-based routing (through the JBoss Rules engine, XPath, Regex and Smooks)
- Integration with the JBoss Business Process Manager (jBPM) in order to provide service orchestration functionality
- Integration with JBoss Rules in order to provide business rules development functionality.
- Integration with a BPEL engine.
- Be configured to work with a wide variety of transport mechanisms (such as e-mail and JMS),
- Be used as a general-purpose object repository,
- Allow you to implement pluggable data transformation mechanisms,
- Support logging of interactions.
Important
org.jboss.internal.soa.esb and org.jboss.soa.esb. Use the contents of the org.jboss.internal.soa.esb package sparingly because they are subject to change without notice. By contrast, everything within the org.jboss.soa.esb package is covered by Red Hat's deprecation policy.
1.10. Task Management Copy linkLink copied to clipboard!
1.11. Integration Use Case Copy linkLink copied to clipboard!
1.12. Utilising the JBoss Enterprise SOA Platform in a Business Environment Copy linkLink copied to clipboard!
Chapter 2. Introducing the jUDDI Registry Copy linkLink copied to clipboard!
2.1. Intended Audience Copy linkLink copied to clipboard!
2.2. Aim of This Book Copy linkLink copied to clipboard!
2.3. Back Up Your Data Copy linkLink copied to clipboard!
Warning
2.4. jUDDI Registry Copy linkLink copied to clipboard!
2.5. jUDDI and the JBoss Enterprise SOA Platform Copy linkLink copied to clipboard!
The JBoss Enterprise SOA Platform product includes a pre-configured installation of a jUDDI registry. You can use a specific API to access this registry through your custom client. However, any custom client that you build will not covered by your SOA Platform support agreement. You can access the full set of jUDDI examples, documentation and APIs from: http://juddi.apache.org/.
2.6. Other Supported Service Registries Copy linkLink copied to clipboard!
- SOA Software SMS
- HP Systinet
2.7. Service Registry Copy linkLink copied to clipboard!
2.8. Service Provider Copy linkLink copied to clipboard!
2.9. Service Broker Copy linkLink copied to clipboard!
2.10. Service Requester Copy linkLink copied to clipboard!
2.11. Web Service Copy linkLink copied to clipboard!
2.12. Web Service End-Point Copy linkLink copied to clipboard!
2.13. Web Services Description Language (WSDL) Copy linkLink copied to clipboard!
- location of the service
- the operations that the service supports
- the protocol bindings the service supports (SOAP, HTTP, etc)
- access procedure
2.14. Universal Description, Discovery and Integration (UDDI) Registry Copy linkLink copied to clipboard!
2.15. UDDI Application Programming Interfaces Copy linkLink copied to clipboard!
- UDDI_Security_PortType
- This defines the API to obtain a security token. With a valid security token a publisher can publish to the registry. A security token can be used for the entire session.
- UDDI_Publication_PortType
- This defines the API to publish business and service information to the UDDI registry.
- UDDI_Inquiry_PortType
- This defines the API to query the UDDI registry. This API does not normally require a security token.
- UDDI_CustodyTransfer_PortType
- This API can be used to transfer the custody of a business from one UDDI node to another.
- UDDI_Subscription_PortType
- This defines the API to register for updates on a particular business of service.
- UDDI_SubscriptionListener_PortType
- This defines the API a client must implement to receive subscription notifications from a UDDI node.
- UDDI_Replication_PortType
- This defines the API to replicate registry data between UDDI nodes.
- UDDI_ValueSetValidation_PortType
- This is used by nodes to allow external providers of value set the validation. Web services to assess whether keyedReferences or keyedReferenceGroups are valid.
- UDDI_ValueSetCaching_PortType
- UDDI nodes may perform validation of publisher references themselves using the cached values obtained from such a Web service.
2.16. UDDI Page Types Copy linkLink copied to clipboard!
- Green Pages
- Green Pages provide information that enables you to bind a client to the service being provided.
- Yellow Pages
- Yellow Pages are used to categorize businesses based upon the industries to which they belong.
- White Pages
- White Pages contain general information, such as the name, address and other contact details for the company providing the service.
2.17. The Service Registry and the JBoss Enterprise SOA Platform Copy linkLink copied to clipboard!
2.18. jUDDI and the ESB Copy linkLink copied to clipboard!
2.19. How the Registry Works Copy linkLink copied to clipboard!
- The JBoss Enterprise Service Bus funnels all interaction with the Registry through the registry interface.
- It then calls a JAXR implementation of this interface.
- The JAXR API needs to utilize a JAXR implementation. (By default, this is Apache Scout.)
- Apache Scout, in turn, calls the Registry.
2.20. Apache Scout Copy linkLink copied to clipboard!
org.jboss.soa.esb.scout.proxy.transportClass class, one each for SOAP, SAAJ, RMI and Embedded Java (Local).
2.21. Java API for XML Registries (JAXR) Copy linkLink copied to clipboard!
2.22. Registry Interface Copy linkLink copied to clipboard!
2.23. Variable Name: SOA_ROOT Directory Copy linkLink copied to clipboard!
jboss-soa-p-5 directory. In the Standalone edition, though, it is the jboss-soa-p-standalone-5 directory.
SOA_ROOT. Substitute either jboss-soa-p-5 or jboss-soa-p-standalone-5 as appropriate whenever you see this name.
2.24. Variable Name: PROFILE Copy linkLink copied to clipboard!
Chapter 3. Setting Up Your Root Seed Data Copy linkLink copied to clipboard!
3.1. Service Registry Publishers Copy linkLink copied to clipboard!
- root
- The root publisher is the owner of the root partition and UDDI services (such as
inquiryandpublication). Each registry need to have a root publisher. There can only be one root publisher per node. The jUDDI Registry ships some default seed data for the root account, found in thejuddi-core-3.x.jarfile'sjuddi_install_data/directory. - uddi
- uddi owns all of the other seed data (such as the pre-defined
tModels.
3.2. Seed Data Copy linkLink copied to clipboard!
3.3. Service Registry Seed Data Files Copy linkLink copied to clipboard!
- <publisher>_Publisher.xml
- <publisher>_tModelKeyGen.xml
- <publisher>_BusinessEntity.xml
- <publisher>_tModels.xml
3.4. root_Publisher.xml Copy linkLink copied to clipboard!
root_Publisher.xml data seed file looks like this:
<publisher xmlns="urn:juddi-apache-org:api_v3" authorizedName="root">
<publisherName>root publisher</publisherName>
<isAdmin>true</isAdmin>
</publisher>
<publisher xmlns="urn:juddi-apache-org:api_v3" authorizedName="root">
<publisherName>root publisher</publisherName>
<isAdmin>true</isAdmin>
</publisher>
3.5. Key Generator Schema Copy linkLink copied to clipboard!
3.6. tModel Copy linkLink copied to clipboard!
3.7. root_tModelKeyGen.xml Copy linkLink copied to clipboard!
tModel Key Generator is defined in the SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_tModelKeyGen.xml file:
root publisher need to be in the following form: uddi:juddi.apache.org:<text-of-choice>.
3.8. Create a Key Generator Schema for a Publisher Copy linkLink copied to clipboard!
Procedure 3.1. Task
- Each publisher need to define its own KenGenerator tModel. The tModel Key Generator is defined in the root_tModelKeyGen.xml file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - The keys used by the root publisher need to be in the following form:
uddi:juddi.apache.org:<text-of-choice>. If you use another format, you will see an illegal key error.Warning
Do not share KeyGenerators.
3.9. View a Publisher via More than Just One KeyGenerator tModel Copy linkLink copied to clipboard!
Procedure 3.2. Task
- Use the
<publisher>_tModels.xmlfile.
3.10. Configure Business and Service Data Using a Publisher Copy linkLink copied to clipboard!
Procedure 3.3. Task
- Open the
<publisher>_BusinessEntity.xmlfile in a text editor:vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml - Edit the file to specify your services. Here is an example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
Warning
The seeding process only commences if there are nopublishersin the database, unless you set juddi.seed.always totrue. (It will then re-apply all files with the exception of the root data files.)This can lead to data loss, as any information added to entities that are re-seeded will be erased. This is because that data is not merged.
3.11. Configure Tokens in the root_BusinessEntity.xml File Copy linkLink copied to clipboard!
Procedure 3.4. Task
- To set the value of the tokens in the root_
BusinessEntity.xmlfile (${juddi.server.baseurl}), modify theSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xmlfile. Open the<publisher>_BusinessEntity.xmlfile in a text editor:vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/root_BusinessEntity.xml - Here you can set keys and security tokens. Modify these sections to suit your needs.
- Save the file and exit.
Note
The value substitution takes place at run-time, so different nodes can substitute their own values if need be.
3.12. Customise the Seed Data Copy linkLink copied to clipboard!
Procedure 3.5. Task
Important
You must do this prior to starting the Service Registry for the first time as this seed data will be used to populate the database.If you do want to re-run the process, delete the database that was created.Do not forget to set the tokens in theSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xmlfile.Add your custom seed data tojuddiv3.war/WEB-INF/classes/juddi_custom_install_data/directory.Note
To use the Sales Seed Data rename the directory found in theSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar//WEB-INF/classes/by running this command:mv RENAME4Sales_juddi_custom_install_data juddi_custom_install_dataNote
If your root publisher is not calledrootyou will need to set theSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xmlfile's juddi.root.publisher property to something other than this:juddi.root.publisher=root
juddi.root.publisher=rootCopy to Clipboard Copied! Toggle word wrap Toggle overflow Properties are set in this way:<entry key="juddi.root.publisher">root</entry>
<entry key="juddi.root.publisher">root</entry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 4. Simple Publishing via the API Copy linkLink copied to clipboard!
4.1. UDDI Data Model Copy linkLink copied to clipboard!
- Business entities
- Business entities are at the top of the pyramid. They contain business services.
- Business services
- Business services contain end-point references.
4.2. Business Entity Copy linkLink copied to clipboard!
4.3. Business Service Copy linkLink copied to clipboard!
4.4. End-Point Reference Copy linkLink copied to clipboard!
4.5. UDDI and the jUDDI API Copy linkLink copied to clipboard!
sets. Each set represents a specific area of functionality:
Inquiryhandles queries to the Registry for details about entities.Publicationhandles the registration of entities.Securityis an open-ended specification that handles authentication.Custody and Ownership Transferhandles the transference of ownership of entities.Subscriptionallows clients to retrieve information about entities using a subscription format.Subscription Listeneris a client API for accepting subscription results.Value Set (Validation and Caching)validates keyed reference values. (This set is not yet available for the jUDDI.)Replicationallows you to federate data between registry nodes. (This set is not yet available for the jUDDI.)
sets you will use most frequently are Inquiry, Publication and Security. They provide the standard functions you need for interacting with the Registry.
sets as a JAX-WS-compliant web service. (Each method defined in a set is simply a method in the corresponding web service.)
4.6. jUDDI Additions to the UDDI Model Copy linkLink copied to clipboard!
The jUDDI Registry's implementation provides the data model with some additional structure beyond that described in the specification. Prime amongst this is the concept of the publisher.
publish calls to assign ownership to the published entities.
4.7. Tutorial: Use the Service Registry for the First Time Copy linkLink copied to clipboard!
Procedure 4.1. Task
- Instantiate the
SimplePublishclass. Here is the constructor:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This constructor uses the jUDDI client API to retrieve the transport from the default node. In this example, it is simply retrieving the default client transport class which is designed to make UDDI calls out using JAX-WS web services. - Obtain the three API sets needed for the example:
- the
SecurityAPI set, so you can obtain authorisation tokens, - the proprietary
jUDDIAPI set so you can save a publisher, - the
PublicationAPI set so that you can register entities in the jUDDI.
Here are the first few lines of thepublishmethod:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This code simply retrieves the authorisation token for the root user. - Add a publisher:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The code above uses the jUDDI API to save a publisher with authorised name, my-publisher. Note that the authorisation token for the root user is utilised. - Obtain the authorisation token for this new publisher:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note that no credentials have been set on either of the authorisation calls. This is because, by using the default authenticator, you do not have to provide any. - Publish:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
There are some important things to note with regard to the use of entity keys. Version three of the specification allows for publishers to create their own keys but also instructs implementers to have default methods.Red Hat has chosen the default implementation approach by leaving each entity’s key field blank in thesavecall. The jUDDI’s default key generator simply takes the node’s partition and appends a GUID to it.In a default installation, it will look something like this:uddi:juddi.apache.org:<GUID>(You can, of course, customise all of this if you wish.)The second important point is that when the BusinessService is saved, its parent business key (retrieved from previous call saving the business) is set explicitly. This is a necessary step when the service is saved in an independent call like this because, otherwise, you would encounter an error as the jUDDI will not know where to find the parent entity.
In this example you have created and saved a BusinessEntity and then created and saved a BusinessService. You have added the bare minimum of data to each entity (and, in fact, have not added any BindingTemplates to the service).
Chapter 5. Subscriptions Copy linkLink copied to clipboard!
5.1. Subscription API Copy linkLink copied to clipboard!
subscription API allows you to cross-register services on different service registries and keep them up-to-date by sending out notifications as the registry information in the parent registry changes. This is helpful if you have a large or complex organisation and decide to run different service registries for different departments, with some services being shared between them.
5.2. Subscription Types Copy linkLink copied to clipboard!
- asynchronous
- With this, you can save a subscription, and receive updates on a set schedule. It requires a listener service to be installed on the node to which the notifications will be sent.
- synchronous
- With this, you can save a subscription and invoke
get_Subscriptionto obtain a synchronous reply.
5.3. Tutorial: Subscriptions Copy linkLink copied to clipboard!
Prerequisites
- In this example, you will configure nodes for
salesandmarketing. To do so, you will need to deploy the Service Registry to two different services first.
Procedure 5.1. Task
Configuring Node One: Sales
Createjuddi_custom_install_databy running these commands:cd juddiv3/WEB-INF/classesmv RENAME4SALES_juddi_custom_install_data juddi_custom_install_data- Open the
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xmlfile in a text editor and set the following property values (where "sales" is the DNS name of your server):juddi.server.name=sales juddi.server.port=8080
juddi.server.name=sales juddi.server.port=8080Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
- Start the server:
SOA_ROOT/jboss-as/bin/./run.sh - Open a web browser and go to this address: http://sales:8080/juddiv3. You should see a message that provides you with information about the node.
Configuring Node Two: Marketing
Createjuddi_custom_install_databy running these commands:cd juddiv3/WEB-INF/classesmv RENAME4MARKETING_juddi_custom_install_data juddi_custom_install_data- Open the
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xmlfile in a text editor and set the following property values (where "marketing" is the DNS name of your server)juddi.server.name=marketing juddi.server.port=8080
juddi.server.name=marketing juddi.server.port=8080Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
- Start the server:
SOA_ROOT/jboss-as/bin/./run.sh - Open a web browser and go to this address: http://sales:8080/juddiv3. Again you should see a message that provides you with information about the node.
Note
Note that the root partition was kept the same, because both the sales and marketing departments are located in the same company, but the Node Id and Name changed to reflect that each node belongs to a different department. - Next, replace the sales server's
uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xmlfile withuddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml.sales. - Open the
uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xmlfile in a text editor and add the following properties:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
- Launch a web browser and go to this address: http://sales:8080/pluto.
- Log in with both a user name and password of
salesand observe what is displayed onscreen. - Before logging into the marketing portal, replace marketing's
uddi-portlet.war/WEB-INF/classes/META-INF/uddi.xmlfile withudd-portlet.war/WEB-INF/classes/META-INF/uddi.xml.marketing. - Open the
uddi-portlet.war/WEB-INF/classes/META_INF/uddi.xmlfile in a text editor and add the following properties:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
- Launch a web browser and go to this address: http://marketing:8080/pluto.
- Log in with both a user name and password of
salesand observe what is displayed onscreen.Note
The subscriptionlistener is owned by the Marketing Node business, not the Root Marketing Node. The Marketing Node Business is managed by the marketing publisher.
5.4. Tutorial: Deploy the HelloSales Service Copy linkLink copied to clipboard!
Procedure 5.2. Task
- Open the
juddiv3-samples.war/WEB-INF/classes/META-INF/uddi.xmlfile in a text editor and add the following property values to sales:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the file and exit.
- Now deploy the
juddiv3-samples.warto the sales registry.ant deployant runtestNote
The HelloSales service is provided in thejuddiv3-samples.wararchive file and it is annotated, so it will automatically register itself. - Subscribe to the Sales UDDI node's HelloWord service from within the Marketing UDDI node.
5.5. Allow Users to Create Their Own Subscriptions Copy linkLink copied to clipboard!
Prerequisites
- For a user to create and save subscriptions, they must have valid "publisher" log-ins for both the sales and marketing nodes.
- If the marketing publisher is going to create registry objects in the marketing node, the marketing publisher needs to own the
sales keygenerator tModel.It is important to understand that the marketing publisher in the marketing registry owns the followingtModels:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure 5.3. Task
- If you are going to use the marketing publisher to subscribe to updates in the sales registry, then you must provide this publisher with two clerks. You do so by opening the
uddi-portlet.war/uddi.xmlfile in a text editor and adding the following lines:Copy to Clipboard Copied! Toggle word wrap Toggle overflow In the code above, you created two clerks for this publisher, namely MarketingCratchit and SalesCratchit. These allow the publisher to check on the subscriptions it owns in each of the two systems. - Save the file and exit.
- Log in as the marketing publisher on the marketing portal and select the UDDISubscription Portlet.
- When both nodes turn green, click on the new subscription icon (found on the toolbar.) This will be a synchronous subscription, so only leave the Binding Key and Notification Interval
- Click the Save icon to store the subscription.
- Make sure that the subscription key uses the marketing publisher's
keyGenerator's conventions. You should see the orange subscription icon appear under thesales-wsUDDI node. - To invoke a synchronous subscription, click the Green Arrows icon. This will give you the opportunity to set the coverage period.
- Click the Green Arrows icon again to invoke the synchronous subscription request.The example finder request will search the sales node looking for updates to the
HelloWorldservice. The raw XML response is then posted to theUDDISubscriptionNotificationportlet: - The response is processed by the marketing node. This node then imports the
HelloWorldsubscription information, as well as thesales business. If they synchronise successfully, three businesses will be visible in the marketing node's browser portlet.
Chapter 6. Support for M-Beans Copy linkLink copied to clipboard!
6.1. M-Bean Copy linkLink copied to clipboard!
6.2. jUDDI M-Beans Copy linkLink copied to clipboard!
- org.apache.juddi.api.impl.UDDIServiceCounter
- org.apache.juddi.api.impl.UDDICustodyTransferCounter
- org.apache.juddi.api.impl.UDDIInquiryCounter
- org.apache.juddi.api.impl.UDDIPublicationCounter
- org.apache.juddi.api.impl.UDDISecurityCounter
- org.apache.juddi.api.impl.UDDISubscriptionCounter
- successful queries
- failed queries
- total queries
- processing time
- an aggregate count of total/successful/failed per API
Chapter 7. Using the jUDDI Client Copy linkLink copied to clipboard!
7.1. jUDDI Client Copy linkLink copied to clipboard!
SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/lib/juddi-client-VERSION.jar.
7.2. jUDDI Client Dependencies Copy linkLink copied to clipboard!
uddi-ws-3.0.0.jarcommons-configuration-1.5.jarcommons-collection-3.2.1.jarlog4j-1.2.13.jar
- libraries for JDK6.
- JAXWS client libraries (if you are using a JAXWS transport like CXF.)
- RMI and JNDI client libraries (if you are using the RMI Transport.)
7.3. jUDDI Client and the JBoss Enterprise SOA Platform Copy linkLink copied to clipboard!
Important
7.4. Transport Settings Copy linkLink copied to clipboard!
7.5. uddi.xml Copy linkLink copied to clipboard!
META-INF/uddi.xml file contains the configuration settings for the jUDDI client. You can include this file in the deployment archive that is interacting with the UDDI client code.
7.6. Deploy a Custom jUDDI Client Configuration Copy linkLink copied to clipboard!
Procedure 7.1. Task
- Open META-INF/uddi.xml in your text editor.
- Configure the settings.
- Save and exit.
- Include the uddi.xml file in your archive when you deploy it.
- Call this code:
UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml"); clerkManager.start();UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml"); clerkManager.start();Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Alternatively, if your application deploys as a WAR archive, add your client configuration to
yourwar/META-INF/myuddi.xmland, in the web.xml file, specify these context parameters:uddi.client.manager.nameanduddi.client.xml.In this example, both context parameters are set and on deployment the UDDIClerkServlet takes care of reading the configuration:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.7. Sample jUDDI Client Configuration File Copy linkLink copied to clipboard!
isHomeJUDDI="true", while for the 'remote' registries you would set isHomeJUDDI="false".
| Element Name | Description | Required? |
|---|---|---|
| name | name of the node | yes |
| description | description of the node | no |
| properties | container for properties that will be passed into the clerk | no |
| proxyTransport | The Transport protocol used by the client to connect to the UDDI server | yes |
| custodyTransferUrl | Connection settings for custody transfer | no |
| inquiryUrl | Connection location settings for inquiries | yes |
| publishUrl | Connection location settings for publishing | yes |
| securityUrl | Connection location settings for obtaining security tokens | yes |
| subscriptionUrl | Connection location settings for registering subscription requests | no |
| subscriptionListenerUrl | Connection location settings receiving subscription notifications | no |
| juddiApiUrl | Connection location settings for the jUDDI specific API for things like publisher management | no |
| Attribute Name | Description | Required? |
|---|---|---|
| name | name of the clerk | yes |
| node | name reference to one of the nodes specified in the same manager | yes |
| publisher | name of an existing publisher | yes |
| password | password credential of the publisher | yes |
7.8. Java API for XML Web Services (JAX-WS) Copy linkLink copied to clipboard!
7.9. Set the JAX-WS Transport Copy linkLink copied to clipboard!
Prerequisites
- Based on the settings in the
uddi.xmlfile, the client will use JAX-WS to communicate with the (remote) registry server. This means that the client needs to have access to a JAX-WS-compliant web service stack (such as CXF, Axis2 or JBossWS).
Procedure 7.2. Task
- Ensure that the JAX-WS URLs are pointing to an address where the UDDI client can find the WSDL documents:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Important
Pros: This is the standard way of performing UDDI communication and it should should work with all UDDIv3 server implementations.Cons: If the server is deployed on the same application server this may lead to issues when auto-registration on deployment/undeployment is used, since the WS stack may become unavailable during undeployment. A workaround is to host the UDDI server on a different server.
7.10. Remote Invocation Class Copy linkLink copied to clipboard!
7.11. jUDDI and Remote Method Invocation Copy linkLink copied to clipboard!
7.12. Enable Remote Method Invocation for jUDDI Copy linkLink copied to clipboard!
Procedure 7.3. Task
- Open the jUDDI configuration file in a text editor:
vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml. - Edit the settings and set the property <entry key="juddi.jndi.registration">true</entry>. If set to true, RMI methods are registered to jndi and can be searched and called. Default is true.
- Save the file and exit.
- Open the UDDI configuration file in a text editor:
vi META-INF/uddi.xml. - "Comment out" the JAX-WS section of the file and uncomment the RMI section instead.
- As an optional step, you can also set the java.naming.* properties. In this example, you specified the setting for connecting to jUDDI v3 deployed on a JBoss Application Server. If you like you can instead set the java.naming.* properties in a
jndi.propertiesfile, or as system parameters.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Important
Pros: It is lightweight fast since it does not need a web service stack.Cons: It only works with a jUDDI v3 server implementation. - Save the file and exit.
When you deploy it, the RMI-based UDDI services will bind to the global JNDI namespace:
- juddiv3 (class:
org.jnp.interfaces.NamingContext) - UDDIPublicationService (class:
org.apache.juddi.rmi.UDDIPublicationService) - UDDICustodyTransferService (class:
org.apache.juddi.rmi.UDDICustodyTransferService) - UDDISubscriptionListenerService (class:
org.apache.juddi.rmi.UDDISubscriptionListenerService) - UDDISecurityService (class:
org.apache.juddi.rmi.UDDISecurityService) - UDDISubscriptionService (class:
org.apache.juddi.rmi.UDDISubscriptionService) - UDDIInquiryService (class:
org.apache.juddi.rmi.UDDIInquiryService)
7.13. InVM Transport Copy linkLink copied to clipboard!
7.14. InVM and jUDDI Copy linkLink copied to clipboard!
juddi.war archive, the server will be started by the org.apache.juddi.RegistryServlet class, but if you are running outside any container, you are responsible for starting and stopping the org.apache.juddi.Registry service yourself.
7.15. Configure the InVM Transport for jUDDI Copy linkLink copied to clipboard!
Procedure 7.4. Task
- Open the UDDI configuration file in a text editor:
vi META-INF/uddi.xml. - "Comment out" the JAX-WS and RMI Transport sections of the file and uncomment the InVM Transport section instead.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Important
Pros: It is lightweight and provides the best performance for communications and there are no deployment order issues when using auto-registration of services during deployment and undeployment.Cons: It will only work with a jUDDI v3 server implementation. Normally, you would use a jUDDI server for each application server sharing one common database. - Save the file and exit.
7.16. Start the Service Registry Using the InVM Transport Copy linkLink copied to clipboard!
- Call the following method prior to making any other calls to it:
Registry.start()
7.17. Stop the Service Registry Using the InVM Transport Copy linkLink copied to clipboard!
Procedure 7.5. Task
- Call the following method prior to making any other calls to it:
Registry.stop()
The registry releases any resources it may be holding.
7.18. UDDI Annotation Copy linkLink copied to clipboard!
Note
7.19. Use the UDDIService Annotation Copy linkLink copied to clipboard!
Procedure 7.6. Task
- Use the UDDIService annotation to register a service under an already-existing business in the Registry. The annotation should be added to the Java class' "class" level.
7.20. UDDIService Attributes Copy linkLink copied to clipboard!
| Attribute | Description | Required? |
|---|---|---|
| serviceName | This is the name of the service. By default, the clerk will use the one name specified in the WebService annotation | No |
| description | This is the human-readable description of the service | Yes |
| serviceKey | This is the service's UDDI v3 key. | Yes |
| businessKey | This is the UDDI v3 key of the business that should own the service. (The business should exist in the Registry at time of registration.) | Yes |
| lang | This is the language locale which will be used for the name and description. (It defaults to "en" if you omit it.) | No |
| categoryBag | This is the definition of a CategoryBag. | No |
7.21. Use the UDDIServiceBinding Annotation Copy linkLink copied to clipboard!
Procedure 7.7. Task
- Use the UDDIServiceBinding annotation to register an end-point reference in the Service Registry. The annotation should be added to the Java class' "class" level.
Note
You cannot use this annotation by itself. It needs to be utilised within an UDDIService annotation
7.22. UDDIServiceBinding Attributes Copy linkLink copied to clipboard!
| Attribute | Description | Required? |
|---|---|---|
| bindingKey | This is the ServiceBinding's UDDI v3 key. | Yes |
| description | This is a human-readable description of the service | Yes |
| accessPointType | This is UDDI v3's AccessPointType. (It defaults to wsdlDeployment if you omit it.) | No |
| accessPoint | This is the end-point reference | Yes |
| lang | This is the language locale which will be used for the name and description, (It will default to "en" if you omit it.) | No |
| tModelKeys | This is a comma-separated list of tModelKeys key references. | No |
| categoryBag | This is the definition of a CategoryBag. | No |
7.23. Example Use of UDDI Annotations Copy linkLink copied to clipboard!
You can use the annotations on any class that defines a service. Here they are added to a web service (a POJO with a JAX-WS web service annotation):
juddi-client code will scan this class for UDDI annotations and take care of the registration process.
org.apache.juddi.samples.HelloWorldImpl service class:
<clerk name="BobCratchit" node="default" publisher="sales" password="sales">
<class>org.apache.juddi.samples.HelloWorldImpl</class>
</clerk>
<clerk name="BobCratchit" node="default" publisher="sales" password="sales">
<class>org.apache.juddi.samples.HelloWorldImpl</class>
</clerk>
default, and that he will be using the sales publisher (for which the password is sales).
Note
7.24. CategoryBag Attribute Copy linkLink copied to clipboard!
7.25. Example Use of the CategoryBag Annotation Copy linkLink copied to clipboard!
categoryBag="keyedReference=keyName=uddi-org:types:wsdl;keyValue=wsdlDeployment;" +
"tModelKey=uddi:uddi.org:categorization:types," +
"keyedReference=keyName=uddi-org:types:wsdl2;keyValue=wsdlDeployment2;" +
"tModelKey=uddi:uddi.org:categorization:types2",
categoryBag="keyedReference=keyName=uddi-org:types:wsdl;keyValue=wsdlDeployment;" +
"tModelKey=uddi:uddi.org:categorization:types," +
"keyedReference=keyName=uddi-org:types:wsdl2;keyValue=wsdlDeployment2;" +
"tModelKey=uddi:uddi.org:categorization:types2",
7.26. Use Annotations to Develop a Web Service Copy linkLink copied to clipboard!
Procedure 7.8. Task
- Add an annotation to any class that defines a service. Here is an example where they are added to a web service POJO with a JAX-WS Webservice annotation:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow On deployment of this WebService, the juddi-client code will scan this class for UDDI annotations and take care of the registration process. - Open the uddi.xml file in your text editor:
vi uddi.xml - Scroll down to the "clerk" section and add a reference to the
org.apache.juddi.samples.HelloWorldImplservice class:Copy to Clipboard Copied! Toggle word wrap Toggle overflow In this example, Bob is using the connection setting for the node named "default". Furthermore, he will be using a publisher named "bob", for which the password is also "bob". - Save the file and exit.
7.27. Key Template Copy linkLink copied to clipboard!
uddi.xml file.
uddi.xml file. The values you set for the properties in this template will be used when the key is registered.
7.28. Key Template Properties Copy linkLink copied to clipboard!
| Property | Description | Required? | Default Value |
|---|---|---|---|
| lang | The language setting used by the registration | no | en |
| businessName | The business name which is used by the registration. | yes | - |
| keyDomain | The key domain key part (used by the key formats) | yes | - |
| businessKeyFormat | Key format used to construct the Business Key | no | uddi:${keyDomain}:business_${businessName} |
| serviceKeyFormat | Key format used to construct the BusinessService Key | no | uddi:${keyDomain}:service_${serviceName} |
| bindingKeyFormat | Key format used to construct the TemplateBinding Key | no | uddi:${keyDomain}:binding_${nodeName}_${serviceName}_${portName} |
| serviceDescription | Default BusinessService description | no | Default service description when no <wsdl:document> element is defined inside the <wsdl:service> element. |
| bindingDescription | Default BindingTemplate description | no | Default binding description when no <wsdl:document> element is defined inside the <wsdl:binding> element. |
7.29. Use the jUDDI Client Code in Your Application Copy linkLink copied to clipboard!
Procedure 7.9. Task
- Open the jUDDI client configuration file in a text editor:
vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml. Use this file as a template for your ownuddi.xmlfile. - Make sure the clerk manager points to your custom
uddi.xmlwhen it is instantiated:UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml"); clerkManager.start(); UDDIClerk clerk = clerkManager.getClientConfig().getUDDIClerks().get(clerkName);UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml"); clerkManager.start(); UDDIClerk clerk = clerkManager.getClientConfig().getUDDIClerks().get(clerkName);Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
A UDDIClerk will allow you do make authenticated requests to a UDDI server.
7.30. WSDL and the UDDI Registry Copy linkLink copied to clipboard!
7.31. Specification for the Service and Binding Descriptions in the WSDL Copy linkLink copied to clipboard!
uddi.xml file. However it makes a lot more sense to have a specific description for each service and binding and so the registration code tries to obtain these descriptions from the <wsdl:document> tags in the WSDL, which can be nested as a child element inside the <wsdl:service> and <wsdl:binding> elements.
7.32. Register a WSDL Process in jUDDI Copy linkLink copied to clipboard!
Prerequisites
- org.apache.juddi.v3.client.mapping
Procedure 7.10. Task
- Use the code in the
org.apache.juddi.v3.client.mappingpackage. - Make the following call to asynchronously register your web service end point:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
This does assume that you can pass in a URL to the WSDL file in addition to the WSDLDefinition. In most cases you will need to package the WSDL file you wish to register in your deployment.To obtain a WSDLDefinition use this code:ReadWSDL readWSDL = new ReadWSDL(); Definition definition = readWSDL.readWSDL("wsdl/HelloWorld.wsdl");ReadWSDL readWSDL = new ReadWSDL(); Definition definition = readWSDL.readWSDL("wsdl/HelloWorld.wsdl");Copy to Clipboard Copied! Toggle word wrap Toggle overflow You need to pass the path information to the WSDL that is on the classpath.
7.33. Remove a WSDL Binding from the Service Registry Copy linkLink copied to clipboard!
Procedure 7.11. Task
- To remove a WSDL binding from the service registry, use this code:
WSDL2UDDI wsdl2UDDI = new WSDL2UDDI(clerk, urlLocalizer, properties); String serviceKey = wsdl2UDDI.unRegister(serviceName, portName, serviceURL);
WSDL2UDDI wsdl2UDDI = new WSDL2UDDI(clerk, urlLocalizer, properties); String serviceKey = wsdl2UDDI.unRegister(serviceName, portName, serviceURL);Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
If this is the last BindingTemplate for the BusinessService it will also remove the BusinessService itself along with the WSDLPortType and WSDLBinding TModels. The lifecycle is set to "registration" on deployment of the end point and set to "unregistration" on removal of the end point.
7.34. Register a BPEL Process in jUDDI Copy linkLink copied to clipboard!
Prerequisites
- org.apache.juddi.v3.client.mapping
Procedure 7.12. Task
- Use the code in the
org.apache.juddi.v3.client.mappingpackage. - Make the following call to asynchronously register your web service end point:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Set the RegistrationInfo.RegistrationType to RegistrationType.BPEL.
7.35. URLLocalizer Interface and the JBoss Enterprise SOA Platform Copy linkLink copied to clipboard!
7.36. Dynamic UDDI Service Look-up Copy linkLink copied to clipboard!
7.37. Use the Service Locator to Find a Service Binding Copy linkLink copied to clipboard!
Prerequisites
- You must already know the names of the service and port.
Procedure 7.13. Task
- To locate a service binding using the service locator, use this code:
ServiceLocator serviceLocator = new ServiceLocator(clerk, urlLocalizer, properties); String endPointURL = serviceLocator.lookupEndpoint(serviceQName, String portName);
ServiceLocator serviceLocator = new ServiceLocator(clerk, urlLocalizer, properties); String endPointURL = serviceLocator.lookupEndpoint(serviceQName, String portName);Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
The downside of doing a look-up prior to each service invocation is that it will be detrimental to performance.
7.38. Tutorial: Using the jUDDI Client Copy linkLink copied to clipboard!
Prerequisites
- Make sure the publisher (in this case,
root) already exists in the Service Registry
Procedure 7.14. Task
- Obtain the sample code located in the
uddi-clientmodule. - Make a call to the Registry to obtain an authentication token. (The following code is taken from the unit tests in this module):
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note
Ensure that you supply the correct credentials for the root publisher to obtain a successful response.
Appendix A. Revision History Copy linkLink copied to clipboard!
| Revision History | |||
|---|---|---|---|
| Revision 5.3.1-23.400 | 2013-10-31 | ||
| |||
| Revision 5.3.1-23 | Thu Jan 10 2013 | ||
| |||