Red Hat Training
A Red Hat training course is available for JBoss Enterprise SOA Platform
JUDDI Registry Guide
This is a guide to using the service registry for developers.
Edition 5.3.1
David Le Sage
Suzanne Dorfield
Abstract
Preface
Chapter 1. Preface
1.1. Business Integration
1.2. What is a Service-Oriented Architecture?
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
- 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?
1.5. The Service-Oriented Architecture Paradigm
- 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
1.7. Components of the JBoss Enterprise SOA Platform
- 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
- 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
- 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
1.11. Integration Use Case
1.12. Utilising the JBoss Enterprise SOA Platform in a Business Environment
Chapter 2. Introducing the jUDDI Registry
2.1. Intended Audience
2.2. Aim of This Book
2.3. Back Up Your Data
Warning
2.4. jUDDI Registry
2.5. jUDDI and the JBoss Enterprise SOA Platform
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
- SOA Software SMS
- HP Systinet
2.7. Service Registry
2.8. Service Provider
2.9. Service Broker
2.10. Service Requester
2.11. Web Service
2.12. Web Service End-Point
2.13. Web Services Description Language (WSDL)
- 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
2.15. UDDI Application Programming Interfaces
- 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
- 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
2.18. jUDDI and the ESB
2.19. How the Registry Works
- 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
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)
2.22. Registry Interface
2.23. Variable Name: SOA_ROOT Directory
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
Chapter 3. Setting Up Your Root Seed Data
3.1. Service Registry Publishers
- root
- The root publisher is the owner of the root partition and UDDI services (such as
inquiry
andpublication
). 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.jar
file'sjuddi_install_data/
directory. - uddi
- uddi owns all of the other seed data (such as the pre-defined
tModels
.
3.2. Seed Data
3.3. Service Registry Seed Data Files
- <publisher>_Publisher.xml
- <publisher>_tModelKeyGen.xml
- <publisher>_BusinessEntity.xml
- <publisher>_tModels.xml
3.4. root_Publisher.xml
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>
3.5. Key Generator Schema
3.6. tModel
3.7. root_tModelKeyGen.xml
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:
<tModel tModelKey="uddi:juddi.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>uddi-org:keyGenerator</name> <description>Root domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel>
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
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:
<tModel tModelKey="uddi:juddi.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>uddi-org:keyGenerator</name> <description>Root domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel>
- 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
Procedure 3.2. Task
- Use the
<publisher>_tModels.xml
file.
3.10. Configure Business and Service Data Using a Publisher
Procedure 3.3. Task
- Open the
<publisher>_BusinessEntity.xml
file 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:
<businessEntity xmlns="urn:uddi-org:api_v3" xmlns:xml="http://www.w3.org/XML/1998/namespace" businessKey="uddi:juddi.apache.org:businesses-asf"> <!-- Change the name field to represent the name of your registry --> <name xml:lang="en">An Apache jUDDI Node</name> <!-- Change the description field to provided a brief description of your registry --> <description xml:lang="en"> This is a UDDI v3 registry node as implemented by Apache jUDDI. </description> <discoveryURLs> <!-- This discovery URL should point to the home installation URL of jUDDI --> <discoveryURL useType="home"> http://${juddi.server.baseurl}/juddiv3 </discoveryURL> </discoveryURLs> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:nodes" keyValue="node" /> </categoryBag> <businessServices> <!-- As mentioned above, you may want to provide user-defined keys for these (and the services/bindingTemplates below. Services that you don't intend to support should be removed entirely --> <businessService serviceKey="uddi:juddi.apache.org:services-inquiry" businessKey="uddi:juddi.apache.org:businesses-asf"> <name xml:lang="en">UDDI Inquiry Service</name> <description xml:lang="en">Web Service supporting UDDI Inquiry API</description> <bindingTemplates> <bindingTemplate bindingKey="uddi:juddi.apache.org:servicebindings-inquiry-ws" serviceKey="uddi:juddi.apache.org:services-inquiry"> <description>UDDI Inquiry API V3</description> <!-- This should be changed to the WSDL URL of the inquiry API. An access point inside a bindingTemplate will be found for every service in this file. They all must point to their API's WSDL URL --> <accessPoint useType="wsdlDeployment"> http://${juddi.server.baseurl}/juddiv3/services/inquiry?wsdl </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="uddi:uddi.org:v3_inquiry"> <instanceDetails> <instanceParms> <![CDATA[ <?xml version="1.0" encoding="utf-8" ?> <UDDIinstanceParmsContainer xmlns="urn:uddi-org:policy_v3_instanceParms"> <defaultSortOrder> uddi:uddi.org:sortorder:binarysort </defaultSortOrder> </UDDIinstanceParmsContainer> ]]> </instanceParms> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> <categoryBag> <keyedReference keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" tModelKey="uddi:uddi.org:categorization:types"/> </categoryBag> </bindingTemplate> </bindingTemplates> </businessService> <businessService serviceKey="uddi:juddi.apache.org:services-publish" businessKey="uddi:juddi.apache.org:businesses-asf"> <name xml:lang="en">UDDI Publish Service</name> ........... </businessService> </businessServices> </businessEntity>
- Save the file and exit.
Warning
The seeding process only commences if there are nopublishers
in 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
Procedure 3.4. Task
- To set the value of the tokens in the root_
BusinessEntity.xml
file (${juddi.server.baseurl}
), modify theSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
file. Open the<publisher>_BusinessEntity.xml
file 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
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.xml
file.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_data
Note
If your root publisher is not calledroot
you will need to set theSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
file's juddi.root.publisher property to something other than this:juddi.root.publisher=root
Properties are set in this way:<entry key="juddi.root.publisher">root</entry>
Chapter 4. Simple Publishing via the API
4.1. UDDI Data Model
- 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
4.3. Business Service
4.4. End-Point Reference
4.5. UDDI and the jUDDI API
sets
. Each set
represents a specific area of functionality:
Inquiry
handles queries to the Registry for details about entities.Publication
handles the registration of entities.Security
is an open-ended specification that handles authentication.Custody and Ownership Transfer
handles the transference of ownership of entities.Subscription
allows clients to retrieve information about entities using a subscription format.Subscription Listener
is 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.)Replication
allows 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
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
Procedure 4.1. Task
- Instantiate the
SimplePublish
class. Here is the constructor:public SimplePublish() { try { String clazz = UDDIClientContainer.getUDDIClerkManager(null). getClientConfig().getUDDINode("default").getProxyTransport(); Class<?> transportClass = ClassUtil.forName(clazz, Transport.class); if (transportClass!=null) { Transport transport = (Transport) transportClass. getConstructor(String.class).newInstance("default"); security = transport.getUDDISecurityService(); juddiApi = transport.getJUDDIApiService(); publish = transport.getUDDIPublishService(); } } catch (Exception e) { e.printStackTrace(); } }
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
Security
API set, so you can obtain authorisation tokens, - the proprietary
jUDDI
API set so you can save a publisher, - the
Publication
API set so that you can register entities in the jUDDI.
Here are the first few lines of thepublish
method:// Setting up the values to get an authentication token for the 'root' user // ('root' user has admin privileges and can save other publishers). GetAuthToken getAuthTokenRoot = new GetAuthToken(); getAuthTokenRoot.setUserID("root"); getAuthTokenRoot.setCred(""); // Making API call that retrieves the authentication token for the 'root' user. AuthToken rootAuthToken = security.getAuthToken(getAuthTokenRoot); System.out.println ("root AUTHTOKEN = " + rootAuthToken.getAuthInfo());
This code simply retrieves the authorisation token for the root user. - Add a publisher:
// Creating a new publisher that we will use to publish our entities to. Publisher p = new Publisher(); p.setAuthorizedName("my-publisher"); p.setPublisherName("My Publisher"); // Adding the publisher to the "save" structure, using the 'root' user authentication // info and saving away. SavePublisher sp = new SavePublisher(); sp.getPublisher().add(p); sp.setAuthInfo(rootAuthToken.getAuthInfo()); juddiApi.savePublisher(sp);
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:
// Our publisher is now saved, so now we want to retrieve its authentication token GetAuthToken getAuthTokenMyPub = new GetAuthToken(); getAuthTokenMyPub.setUserID("my-publisher"); getAuthTokenMyPub.setCred(""); AuthToken myPubAuthToken = security.getAuthToken(getAuthTokenMyPub); System.out.println ("myPub AUTHTOKEN = " + myPubAuthToken.getAuthInfo());
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:
// Creating the parent business entity that will contain our service. BusinessEntity myBusEntity = new BusinessEntity(); Name myBusName = new Name(); myBusName.setValue("My Business"); myBusEntity.getName().add(myBusName); // Adding the business entity to the "save" structure, using our publisher's // authentication info and saving away. SaveBusiness sb = new SaveBusiness(); sb.getBusinessEntity().add(myBusEntity); sb.setAuthInfo(myPubAuthToken.getAuthInfo()); BusinessDetail bd = publish.saveBusiness(sb); String myBusKey = bd.getBusinessEntity().get(0).getBusinessKey(); System.out.println("myBusiness key: " + myBusKey); // Creating a service to save. Only adding the minimum data: the parent // business key retrieved from saving the business above and a single name. BusinessService myService = new BusinessService(); myService.setBusinessKey(myBusKey); Name myServName = new Name(); myServName.setValue("My Service"); myService.getName().add(myServName); // Add binding templates, etc... // Adding the service to the "save" structure, using our publisher's // authentication info and saving away. SaveService ss = new SaveService(); ss.getBusinessService().add(myService); ss.setAuthInfo(myPubAuthToken.getAuthInfo()); ServiceDetail sd = publish.saveService(ss); String myServKey = sd.getBusinessService().get(0).getServiceKey(); System.out.println("myService key: " + myServKey);
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 thesave
call. 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
5.1. Subscription API
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
- 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_Subscription
to obtain a synchronous reply.
5.3. Tutorial: Subscriptions
Prerequisites
- In this example, you will configure nodes for
sales
andmarketing
. 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_data
by running these commands:cd juddiv3/WEB-INF/classes
mv RENAME4SALES_juddi_custom_install_data juddi_custom_install_data
- Open the
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
file 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
- 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_data
by running these commands:cd juddiv3/WEB-INF/classes
mv RENAME4MARKETING_juddi_custom_install_data juddi_custom_install_data
- Open the
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
file 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
- 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.xml
file withuddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml.sales
. - Open the
uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml
file in a text editor and add the following properties:<name>default</name> <properties> <property name="serverName" value="sales"/> <property name="serverPort" value="8080"/> <property name="rmiPort" value="1099"/> </properties>
- 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
sales
and observe what is displayed onscreen. - Before logging into the marketing portal, replace marketing's
uddi-portlet.war/WEB-INF/classes/META-INF/uddi.xml
file withudd-portlet.war/WEB-INF/classes/META-INF/uddi.xml.marketing
. - Open the
uddi-portlet.war/WEB-INF/classes/META_INF/uddi.xml
file in a text editor and add the following properties:<name>default</name> <properties> <property name="serverName" value="marketing"/> <property name="serverPort" value="8080"/> <property name="rmiPort" value="1099"/> </properties>
- 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
sales
and 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
Procedure 5.2. Task
- Open the
juddiv3-samples.war/WEB-INF/classes/META-INF/uddi.xml
file in a text editor and add the following property values to sales:<?xml version="1.0" encoding="ISO-8859-1" ?> <uddi> <reloadDelay>5000</reloadDelay> <manager name="example-manager"> <nodes> <node> <name>default</name> <description>Sales jUDDI node</description> <properties> <property name="serverName" value="sales"/> <property name="serverPort" value="8080"/> <property name="keyDomain" value="sales.apache.org"/> <property name="department" value="sales" /> </properties> <proxyTransport> org.apache.juddi.v3.client.transport.InVMTransport </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> </node> </nodes> </manager> </uddi>
- Save the file and exit.
- Now deploy the
juddiv3-samples.war
to the sales registry.ant deploy
ant runtest
Note
The HelloSales service is provided in thejuddiv3-samples.war
archive 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
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
:<save_tModel xmlns="urn:uddi-org:api_v3"> <tModel tModelKey="uddi:marketing.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>marketing-apache-org:keyGenerator</name> <description>Marketing domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel> <tModel tModelKey="uddi:marketing.apache.org:subscription:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>marketing-apache-org:subscription:keyGenerator</name> <description>Marketing Subscriptions domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel> <tModel tModelKey="uddi:sales.apache.org:keygenerator" xmlns="urn:uddi-org:api_v3"> <name>sales-apache-org:keyGenerator</name> <description>Sales Root domain key generator</description> <overviewDoc> <overviewURL useType="text"> http://uddi.org/pubs/uddi_v3.htm#keyGen </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:keyGenerator" keyValue="keyGenerator" /> </categoryBag> </tModel> </save_tModel>
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.xml
file in a text editor and adding the following lines:<clerks registerOnStartup="false"> <clerk name="MarketingCratchit" node="default" publisher="marketing" password="marketing"/> <clerk name="SalesCratchit" node="sales-ws" publisher="marketing" password="marketing"/> <!-- optional <xregister> <servicebinding entityKey="uddi:marketing.apache.org:servicebindings-subscriptionlistener-ws" fromClerk="MarketingCratchit" toClerk="SalesCratchit"/> </xregister> --> </clerks>
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-ws
UDDI 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
HelloWorld
service. The raw XML response is then posted to theUDDISubscriptionNotification
portlet: - The response is processed by the marketing node. This node then imports the
HelloWorld
subscription 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
6.1. M-Bean
6.2. jUDDI M-Beans
- 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
7.1. jUDDI Client
SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/lib/juddi-client-VERSION.jar
.
7.2. jUDDI Client Dependencies
uddi-ws-3.0.0.jar
commons-configuration-1.5.jar
commons-collection-3.2.1.jar
log4j-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
Important
7.4. Transport Settings
7.5. uddi.xml
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
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();
- Alternatively, if your application deploys as a WAR archive, add your client configuration to
yourwar/META-INF/myuddi.xml
and, in the web.xml file, specify these context parameters:uddi.client.manager.name
anduddi.client.xml
.In this example, both context parameters are set and on deployment the UDDIClerkServlet takes care of reading the configuration:<!-- required --> <context-param> <param-name>uddi.client.manager.name</param-name> <param-value>example-manager</param-value> </context-param> <!-- optional override --> <context-param> <param-name>uddi.client.xml</param-name> <param-value>META-INF/myuddi.xml</param-value> </context-param> <servlet> <servlet-name>UDDIClerkServlet</servlet-name> <display-name>Clerk Servlet</display-name> <servlet-class>org.apache.juddi.v3.client.config.UDDIClerkServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet>
7.7. Sample jUDDI Client Configuration File
<?xml version="1.0" encoding="ISO-8859-1" ?> <uddi> <reloadDelay>5000</reloadDelay> <manager name="example-manager"> <nodes> <node isHomeJUDDI="true"> <name>default</name> <description>jUDDI node</description> <properties> <property name="serverName" value="www.myuddiserver.com"/> <property name="serverPort" value="8080"/> <property name="keyDomain" value="mydepartment.mydomain.org"/> <property name="department" value="mydepartment" /> </properties> <!-- InVM --> <proxyTransport>org.apache.juddi.v3.client.transport.InVMTransport</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> <!-- JAX-WS Transport <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport> <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer</custodyTransferUrl> <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry</inquiryUrl> <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish</publishUrl> <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security</securityUrl> <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription</subscriptionUrl> <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-listener</subscriptionListenerUrl> <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</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://${serverName}:1099</javaNamingProviderUrl> --> </node> </nodes> <clerks registerOnStartup="true"> <clerk name="BobCratchit" node="default" publisher="bob" password="bob"> <class>org.apache.juddi.samples.HelloWorldImpl</class> </clerk> </clerks> </manager> </uddi>
isHomeJUDDI="true"
, while for the 'remote' registries you would set isHomeJUDDI="false"
.
Table 7.1. Elements
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 |
Table 7.2. Clerks
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)
7.9. Set the JAX-WS Transport
Prerequisites
- Based on the settings in the
uddi.xml
file, 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:
<!-- JAX-WS Transport --> <proxyTransport>org.apache.juddi.v3.client.transport.JAXWSTransport</proxyTransport> <custodyTransferUrl>http://${serverName}:${serverPort}/juddiv3/services/custody-transfer</custodyTransferUrl> <inquiryUrl>http://${serverName}:${serverPort}/juddiv3/services/inquiry</inquiryUrl> <publishUrl>http://${serverName}:${serverPort}/juddiv3/services/publish</publishUrl> <securityUrl>http://${serverName}:${serverPort}/juddiv3/services/security</securityUrl> <subscriptionUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription</subscriptionUrl> <subscriptionListenerUrl>http://${serverName}:${serverPort}/juddiv3/services/subscription-listener</subscriptionListenerUrl> <juddiApiUrl>http://${serverName}:${serverPort}/juddiv3/services/juddi-api?wsdl</juddiApiUrl>
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
7.11. jUDDI and Remote Method Invocation
7.12. Enable Remote Method Invocation for jUDDI
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.properties
file, or as system parameters.<!-- 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://${serverName}:1099</javaNamingProviderUrl>
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
7.14. InVM and jUDDI
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
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.
<!-- InVM --> <proxyTransport>org.apache.juddi.v3.client.transport.InVMTransport</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>
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
- Call the following method prior to making any other calls to it:
Registry.start()
7.17. Stop the Service Registry Using the InVM Transport
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
Note
7.19. Use the UDDIService Annotation
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
Table 7.3.
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
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
Table 7.4. UDDIServiceBinding Attributes
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
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):
package org.apache.juddi.samples; import javax.jws.WebService; import org.apache.juddi.v3.annotations.UDDIService; import org.apache.juddi.v3.annotations.UDDIServiceBinding; @UDDIService( businessKey="uddi:myBusinessKey", serviceKey="uddi:myServiceKey", description = "Hello World test service") @UDDIServiceBinding( bindingKey="uddi:myServiceBindingKey", description="WSDL endpoint for the helloWorld Service. This service is used for " + "testing the jUDDI annotation functionality", accessPointType="wsdlDeployment", accessPoint="http://localhost:8080/juddiv3-samples/services/helloworld?wsdl") @WebService( endpointInterface = "org.apache.juddi.samples.HelloWorld", serviceName = "HelloWorld") public class HelloWorldImpl implements HelloWorld { public String sayHi(String text) { System.out.println("sayHi called"); return "Hello " + text; } }
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>
default
, and that he will be using the sales
publisher (for which the password is sales
).
Note
7.25. Example Use of the CategoryBag Annotation
<categoryBag> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:wsdl" keyValue="wsdlDeployment" /> <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="uddi-org:types:wsdl2" keyValue="wsdlDeployment2" /> </categoryBag>
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
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:
package org.apache.juddi.samples; import javax.jws.WebService; import org.apache.juddi.v3.annotations.UDDIService; import org.apache.juddi.v3.annotations.UDDIServiceBinding; @UDDIService(businessKey="uddi:myBusinessKey", serviceKey="uddi:myServiceKey", description = "Hello World test service") @UDDIServiceBinding(bindingKey="uddi:myServiceBindingKey", description="WSDL endpoint for the helloWorld Service. This service is used for " + "testing the jUDDI annotation functionality", accessPointType="wsdlDeployment", accessPoint="http://localhost:8080/juddiv3-samples/services/helloworld?wsdl") @WebService(endpointInterface = "org.apache.juddi.samples.HelloWorld", serviceName = "HelloWorld") public class HelloWorldImpl implements HelloWorld { public String sayHi(String text) { System.out.println("sayHi called"); return "Hello " + text; } }
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.HelloWorldImpl
service class:<clerks registerOnStartup="true"> <clerk name="BobCratchit" node="default" publisher="bob" password="bob"> <class>org.apache.juddi.samples.HelloWorldImpl</class> </clerk> </clerks>
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
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
Table 7.5. Key Template Properties
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
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.xml
file. - Make sure the clerk manager points to your custom
uddi.xml
when it is instantiated:UDDIClerkManager clerkManager = new UDDIClerkManager("META/myuddi.xml"); clerkManager.start(); UDDIClerk clerk = clerkManager.getClientConfig().getUDDIClerks().get(clerkName);
Note
A UDDIClerk will allow you do make authenticated requests to a UDDI server.
7.30. WSDL and the UDDI Registry
7.31. Specification for the Service and Binding Descriptions in the WSDL
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
Prerequisites
- org.apache.juddi.v3.client.mapping
Procedure 7.10. Task
- Use the code in the
org.apache.juddi.v3.client.mapping
package. - Make the following call to asynchronously register your web service end point:
//Add the properties from the uddi.xml properties.putAll(clerk.getUDDINode().getProperties()); RegistrationInfo registrationInfo = new RegistrationInfo(); registrationInfo.setServiceQName(serviceQName); registrationInfo.setVersion(version); registrationInfo.setPortName(portName); registrationInfo.setServiceUrl(serviceUrl); registrationInfo.setWsdlUrl(wsdlURL); registrationInfo.setWsdlDefinition(wsdlDefinition); registrationInfo.setRegistrationType(RegistrationType.WSDL); registration = new AsyncRegistration(clerk, urlLocalizer, properties, registrationInfo); Thread thread = new Thread(registration); thread.start();
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");
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
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);
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
Prerequisites
- org.apache.juddi.v3.client.mapping
Procedure 7.12. Task
- Use the code in the
org.apache.juddi.v3.client.mapping
package. - Make the following call to asynchronously register your web service end point:
//Add the properties from the uddi.xml properties.putAll(clerk.getUDDINode().getProperties()); RegistrationInfo registrationInfo = new RegistrationInfo(); registrationInfo.setServiceQName(serviceQName); registrationInfo.setVersion(version); registrationInfo.setPortName(portName); registrationInfo.setServiceUrl(serviceUrl); registrationInfo.setWsdlUrl(wsdlURL); registrationInfo.setWsdlDefinition(wsdlDefinition); registrationInfo.setRegistrationType(RegistrationType.BPEL); registration = new AsyncRegistration(clerk, urlLocalizer, properties, registrationInfo); Thread thread = new Thread(registration); thread.start();
Set the RegistrationInfo.RegistrationType to RegistrationType.BPEL.
7.35. URLLocalizer Interface and the JBoss Enterprise SOA Platform
7.36. Dynamic UDDI Service Look-up
7.37. Use the Service Locator to Find a Service Binding
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);
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
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-client
module. - Make a call to the Registry to obtain an authentication token. (The following code is taken from the unit tests in this module):
public void testAuthToken() { try { String clazz = ClientConfig.getConfiguration().getString( Property.UDDI_PROXY_TRANSPORT,Property.DEFAULT_UDDI_PROXY_TRANSPORT); Class<?> transportClass = Loader.loadClass(clazz); if (transportClass!=null) { Transport transport = (Transport) transportClass.newInstance(); UDDISecurityPortType securityService = transport.getSecurityService(); GetAuthToken getAuthToken = new GetAuthToken(); getAuthToken.setUserID("root"); getAuthToken.setCred(""); AuthToken authToken = securityService.getAuthToken(getAuthToken); System.out.println(authToken.getAuthInfo()); Assert.assertNotNull(authToken); } else { Assert.fail(); } } catch (Exception e) { e.printStackTrace(); Assert.fail(); } }
Note
Ensure that you supply the correct credentials for the root publisher to obtain a successful response.
Appendix A. Revision History
Revision History | |||
---|---|---|---|
Revision 5.3.1-23.400 | 2013-10-31 | Rüdiger Landmann | |
| |||
Revision 5.3.1-23 | Thu Jan 10 2013 | David Le Sage | |
|