You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@juddi.apache.org by ks...@apache.org on 2014/02/05 20:29:45 UTC
svn commit: r1564891 [2/39] - in /juddi/cms-site/trunk/content/docs/3.2: ./
juddi-client-guide/ juddi-client-guide/html/ juddi-client-guide/html/css/
juddi-client-guide/html/images/ juddi-client-guide/html/images/community/
juddi-client-guide/html/imag...
Added: juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch01.html
URL: http://svn.apache.org/viewvc/juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch01.html?rev=1564891&view=auto
==============================================================================
--- juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch01.html (added)
+++ juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch01.html Wed Feb 5 19:29:33 2014
@@ -0,0 +1,244 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Chapter 1. Simple Publishing Using the jUDDI API</title><link rel="stylesheet" type="text/css" href="css/jbossorg.css"/><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"/><link rel="home" href="index.html" title="Apache jUDDI Client and GUI Guide"/><link rel="up" href="index.html" title="Apache jUDDI Client and GUI Guide"/><link rel="prev" href="pr01.html" title="Preface"/><link rel="next" href="ch02.html" title="Chapter 2. jUDDI Client Configuration Guide"/><link rel="copyright" href="ln-d5e27.html" title="Legal Notice"/><meta xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" http-equiv="Content-Type" content="text/html; charset=UTF-8"/></head><body><p xmlns:d="http://docbook.org/ns/docbook" id="title"><a href="http://www.jboss.org" class="site_href"><strong>JBoss.org</strong></a><a href="http://docs.jboss.org/" class="doc_href"><strong>Community Documen
tation</strong></a></p><ul xmlns:d="http://docbook.org/ns/docbook" class="docnav"><li class="previous"><a accesskey="p" href="pr01.html"><strong>Prev</strong></a></li><li class="next"><a accesskey="n" href="ch02.html"><strong>Next</strong></a></li></ul><div class="chapter" title="Chapter 1. Simple Publishing Using the jUDDI API"><div class="titlepage"><div><div><h2 class="title"><a id="_simple_publishing_using_the_juddi_api"/>Chapter 1. Simple Publishing Using the jUDDI API</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="ch01.html#_uddi_data_model">1.1. UDDI Data Model</a></span></dt><dt><span class="section"><a href="ch01.html#_juddi_additions_to_the_model">1.2. jUDDI Additions to the Model</a></span></dt><dt><span class="section"><a href="ch01.html#_uddi_and_juddi_api">1.3. UDDI and jUDDI API</a></span></dt><dt><span class="section"><a href="ch01.html#_getting_started">1.4. Getting Started</a></span
></dt><dd><dl><dt><span class="section"><a href="ch01.html#_simple_publishing_example">1.4.1. Simple Publishing Example</a></span></dt><dt><span class="section"><a href="ch01.html#_about_uddi_entity_keys">1.4.2. About UDDI Entity Keys</a></span></dt></dl></dd><dt><span class="section"><a href="ch01.html#_a_few_tips_on_adding_binding_templates">1.5. A few tips on adding Binding Templates</a></span></dt><dt><span class="section"><a href="ch01.html#_conclusion">1.6. Conclusion</a></span></dt></dl></div>
+
+<p>One of the most common requests we get on the message board is "How do I publish a service using jUDDI?" This question holds a wide berth, as it can result anywhere from not understanding the UDDI data model, to confusion around how jUDDI is set up, to the order of steps required to publish artifacts in the registry, to general use of the API - and everything in between. This article will attempt to answer this "loaded" question and, while not going into too much detail, will hopefully clear some of the confusion about publishing into the jUDDI registry.</p>
+<div class="section" title="1.1. UDDI Data Model"><div class="titlepage"><div><div><h2 class="title"><a id="_uddi_data_model"/>1.1. UDDI Data Model</h2></div></div></div>
+
+<p>Before you begin publishing artifacts, you need to know exactly how to break down your data into the UDDI model. This topic is covered extensively in the specification, particularly in section 3, so I only want to gloss over some for details. Readers interested in more extensive coverage should most definitely take a look at the UDDI specification.</p>
+<p>Below is a great diagram of the UDDI data model (taken directly from the specification):
+<a class="ulink" href="http://juddi.apache.org/docs/3.x/userguide/html/images/uddi_core_datastructures.gif">http://juddi.apache.org/docs/3.x/userguide/html/images/uddi_core_datastructures.gif</a>
+As you can see, data is organized into a hierarchical pattern. Business Entities are at the top of the pyramid, they contain Business Services and those services in turn contain Binding Templates. TModels (or technical models) are a catch-all structure that can do anything from categorize one of the main entities, describe the technical details of a binding (ex. protocols, transports, etc), to registering a key partition. TModels wonât be covered too much in this article as I want to focus on the three main UDDI entities.</p>
+<p>The hierarchy defined in the diagram is self-explanatory. You must first have a Business Entity before you can publish any services. And you must have a Business Service before you can publish a Binding Template. There is no getting around this structure; this is the way UDDI works.</p>
+<p>Business Entities describe the organizational unit responsible for the services it publishes. It generally consist of a description and contact information. How one chooses to use the Business Entity is really dependent on the particular case. If youâre one small company, you will likely just have one Business Entity. If you are a larger company with multiple departments, you may want to have a Business Entity per department. (The question may arise if you can have one uber-Business Entity and multiple child Business Entities representing the departments. The answer is yes, you can relate Business Entities using Publisher Assertions, but that is beyond the scope of this article.)</p>
+<p>Business Services are the cogs of the SOA landscape. They represent units of functionality that are consumed by clients. In UDDI, thereâs not much to a service structure; mainly descriptive information like name, description and categories. The meat of the technical details about the service is contained in its child Binding Templates.</p>
+<p>Binding Templates, as mentioned above, give the details about the technical specification of the service. This can be as simple as just providing the serviceâs access point, to providing the location of the service WSDL to more complicated scenarios to breaking down the technical details of the WSDL (when used in concert with tModels). Once again, getting into these scenarios is beyond the scope of this article but may be the subject of future articles.</p>
+</div>
+<div class="section" title="1.2. jUDDI Additions to the Model"><div class="titlepage"><div><div><h2 class="title"><a id="_juddi_additions_to_the_model"/>1.2. jUDDI Additions to the Model</h2></div></div></div>
+
+<p>Out of the box, jUDDI provides some additional structure to the data model described in the specification. Primarily, this is the concept of the Publisher.</p>
+<p>The UDDI specification talks about ownership of the entities that are published within the registry, but makes no mention about how ownership should be handled. Basically, it is left up to the particular implementation to decide how to handle "users" that have publishing rights in the registry.</p>
+<p>Enter the jUDDI Publisher. The Publisher is essentially an out-of-the-box implementation of an identity management system. Per the specification, before assets can be published into the registry, a "publisher" must authenticate with the registry by retrieving an authorization token. This authorization token is then attached to future publish calls to assign ownership to the published entities.</p>
+<p>jUDDIâs Publisher concept is really quite simple, particularly when using the default authentication. You can save a Publisher to the registry using jUDDIâs custom API and then use that Publisher to publish your assets into the registry. jUDDI allows for integration into your own identity management system, circumventing the Publisher entirely if desired. This is discussed in more detail in the documentation, but for purposes of this article, we will be using the simple out-of-the-box Publisher solution.</p>
+<div xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h2>Tip</h2>
+<p>In UDDI, ownership is essentially assigned to a given registry entity by using its "authorizedName" field. The "authorizedName" field is defined in the specification in the operationalInfo structure which keeps track of operational info for each entity. In jUDDI, the authorizedName field translates to the personâs username, also know as the publisher id,</p>
+</div>
+
+</div>
+<div class="section" title="1.3. UDDI and jUDDI API"><div class="titlepage"><div><div><h2 class="title"><a id="_uddi_and_juddi_api"/>1.3. UDDI and jUDDI API</h2></div></div></div>
+
+<p>Knowing the UDDI data model is all well and good. But to truly interact with the registry, you need to know how the UDDI API is structured and how jUDDI implements this API. The UDDI API is covered in great detail in chapter 5 of the specification but will be summarized here.</p>
+<p>UDDI divides their API into several "sets" - each representing a specific area of functionality. The API sets are listed below:</p>
+<div class="itemizedlist"><ul class="itemizedlist"><li class="listitem">
+Inquiry - deals with querying the registry to return details on entities within
+</li><li class="listitem">
+Publication - handles publishing entities into the registry
+</li><li class="listitem">
+Security - open-ended specification that handles authentication
+</li><li class="listitem">
+Custody and Ownership Transfer - deals with transferring ownership and custody of entities
+</li><li class="listitem">
+Subscription - allows clients to retrieve information on entities in a timely manner using a subscription format
+</li><li class="listitem">
+Subscription Listener - client API that accepts subscription results
+</li><li class="listitem">
+Value Set (Validation and Caching)- validates keyed reference values (not implemented by jUDDI)
+</li><li class="listitem">
+Replication - deals with federation of data between registry nodes (not implemented by jUDDI)
+The most commonly used APIs are the Inquiry, Publication and Security APIs. These APIs provide the standard functions for interacting with the registry.
+</li></ul></div>
+
+<p>The jUDDI server implements each of these API sets as a JAX-WS compliant web service and each method defined in the API set is simply a method in the corresponding web service. The client module provided by jUDDI uses a "transport" class that defines how the call is to be made. The default transport uses JAX-WS but there are several alternative ways to make calls to the API. Please refer to the documentation for more information.</p>
+<p>One final note, jUDDI defines its own API set. This API set contains methods that deal with handling Publishers as well as other useful maintenance functions (mostly related to jUDDIâs subscription model). This API set is obviously proprietary to jUDDI and therefore doesnât conform to the UDDI specification.</p>
+</div>
+<div class="section" title="1.4. Getting Started"><div class="titlepage"><div><div><h2 class="title"><a id="_getting_started"/>1.4. Getting Started</h2></div></div></div>
+
+<p>Now that weâve covered the basics of the data model and API sets, itâs time to get started with the publishing sample. The first thing that must happen is to get the jUDDI server up and running. Please refer to this <a class="ulink" href="http://apachejuddi.blogspot.com/2010/02/getting-started-with-juddi-v3.html">http://apachejuddi.blogspot.com/2010/02/getting-started-with-juddi-v3.html</a> article that explains how to start the jUDDI server.</p>
+<div class="section" title="1.4.1. Simple Publishing Example"><div class="titlepage"><div><div><h3 class="title"><a id="_simple_publishing_example"/>1.4.1. Simple Publishing Example</h3></div></div></div>
+
+<p>We will now go over the "simple-publish" examples. These examples expand upon the HelloWorld example in that after retrieving an authentication token, a BusinessEntity and BusinessService are published to the registry. There are two examples:</p>
+<div class="itemizedlist"><ul class="itemizedlist"><li class="listitem">
+simple-publish-portal - This is how to perform the publish operations in a way thatâs portable, meaning that the code logic should apply to any UDDIv3 client application library.
+</li><li class="listitem">
+simple-publish-clerk - This shows you how to perform the same actions using the helper functions in jUDDIâs Client library, which greatly reduces the code required and makes things simple. This uses the UDDIClerkâs functions.
+</li></ul></div>
+
+<div class="section" title="1.4.1.1. Simple Publishing using Portable Code"><div class="titlepage"><div><div><h4 class="title"><a id="_simple_publishing_using_portable_code"/>1.4.1.1. Simple Publishing using Portable Code</h4></div></div></div>
+
+<p>The complete source for this example can be found here:
+ - Portable <a class="ulink" href="http://svn.apache.org/repos/asf/juddi/trunk/juddi-examples/simple-publish-portable/">http://svn.apache.org/repos/asf/juddi/trunk/juddi-examples/simple-publish-portable/</a></p>
+<pre class="screen"> public SimplePublishPortable() {
+ try {
+ // create a client and read the config in the archive;
+ // you can use your config file name
+ UDDIClient uddiClient = new UDDIClient("META-INF/uddi.xml");
+ // a UddiClient can be a client to multiple UDDI nodes, so
+ // supply the nodeName (defined in your uddi.xml.
+ // The transport can be WS, inVM, RMI etc which is defined in the uddi.xml
+ Transport transport = uddiClient.getTransport("default");
+ // Now you create a reference to the UDDI API
+ security = transport.getUDDISecurityService();
+ publish = transport.getUDDIPublishService();
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+ }</pre>
+
+<p>The constructor uses the jUDDI client API to retrieve the transport from the default node. You can refer to the documentation if youâre confused about how clerks and nodes work. Suffice it to say, we are simply retrieving the default client transport class which is designed to make UDDI calls out using JAX-WS web services.</p>
+<p>Once the transport is instantiated, we grab the two API sets we need for this demo: 1) the Security API set so we can get authorization tokens and 2) the Publication API set so we can actually publish entities to the registry.</p>
+<p>All the magic happens in the publish method. We will look at that next.</p>
+<p>Here are the first few lines of the publish method:</p>
+<pre class="screen"> // Login aka retrieve its authentication token
+ GetAuthToken getAuthTokenMyPub = new GetAuthToken();
+ getAuthTokenMyPub.setUserID("bob"); //your username
+ getAuthTokenMyPub.setCred("bob"); //your password
+ AuthToken myPubAuthToken = security.getAuthToken(getAuthTokenMyPub);
+ System.out.println(getAuthTokenMyPub.getUserID() + "'s AUTHTOKEN = " + "******* never log auth tokens!");</pre>
+
+<div xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h2>Important</h2>
+<p>Donât log authentication tokens. In addition, whenever youâre done with it, it should be <span class="emphasis"><em>discarded</em></span>. Think of it as a logout function.</p>
+</div>
+
+<p>This code simply gets the authorization token for the <span class="emphasis"><em>bob</em></span> user.</p>
+<div xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h2>Tip</h2>
+<p>jUDDI includes two reserved usernames, <span class="emphasis"><em>uddi</em></span> and <span class="emphasis"><em>root</em></span>. Root acts as the "administrator" for jUDDI API calls. Additionally, the <span class="emphasis"><em>root</em></span> user is the owning publisher for all the initial services installed with jUDDI. You may be wondering what those "initial services" are. Well, since the UDDI API sets are all implemented as web services by jUDDI, every jUDDI node actually registers those services inside itself. This is done per the specification. The user <span class="emphasis"><em>uddi</em></span> owns the remaining preinstalled data.</p>
+</div>
+
+<p>Now that we have Bobâs authorization, we can start publishing.</p>
+<div xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h2>Tip</h2>
+<p>Youâll note that no credentials have been set on both authorization calls. This is because weâre using the default authenticator (which is for testing purposes doesnât require credentials). Most UDDI servers will require authentication.</p>
+</div>
+
+<pre class="screen"> // 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...
+ // <snip> We removed some stuff here to make the example shorter, check out the source for more info</snip>
+
+ // 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);
+
+ //and we're done, don't forget to logout!
+ security.discardAuthToken(new DiscardAuthToken(myPubAuthToken.getAuthInfo()));</pre>
+
+<p>To summarize, here we have created and saved a BusinessEntity and then created and saved a BusinessService. Weâve just added the bare minimum data to each entity. Obviously, you would want to fill out each structure with greater information, particularly with services. However, this is beyond the scope of this article, which aims to simply show you how to programmatically publish entities.</p>
+</div>
+<div class="section" title="1.4.1.2. Simple Publishing using Clerks"><div class="titlepage"><div><div><h4 class="title"><a id="_simple_publishing_using_clerks"/>1.4.1.2. Simple Publishing using Clerks</h4></div></div></div>
+
+<p>The complete source for this example can be found here:
+ - Clerk <a class="ulink" href="http://svn.apache.org/repos/asf/juddi/trunk/juddi-examples/simple-publish-clerk/">http://svn.apache.org/repos/asf/juddi/trunk/juddi-examples/simple-publish-clerk/</a></p>
+<p>The sample consists of only one class: SimplePublishPortable. Letâs start by taking a look at the constructor:</p>
+<pre class="screen"> public SimplePublishClerk() {
+ try {
+ // create a client and read the config in the archive;
+ // you can use your config file name
+ UDDIClient uddiClient = new UDDIClient("META-INF/uddi.xml");
+ //get the clerk
+ clerk = uddiClient.getClerk("default");
+ if (clerk==null)
+ throw new Exception("the clerk wasn't found, check the config file!");
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+ }</pre>
+
+<p>Notice that this is already much more streamlined than the previous example. In this scenario, all configuration settings and credentials are stored in "META-INF/uddi.xml".</p>
+<div xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h2>Tip</h2>
+<p>The configuration file used by clients can be overridden via the system property "uddi.client.xml". E.g. java -Duddi.client.xml=/usr/local/uddi.xml -jar MyCoolProgram.jar</p>
+</div>
+
+<p>UDDIClientâs job is to read the configuration file and initialize the data structures for working with 1 or more UDDI nodes (or servers). It also handles automatic registration of endpoints using WSDL documents or using class annotations. UDDIClerkâs job is to manage credentials and to perform a number of common tasks. Feel free to use them in your programs and help you simplify things.</p>
+<p>The UDDIClerk also handle credentials and authentication to UDDI for you. If you didnât want to store credentials (it can be encrypted) then you can specify them at runtime very easily.</p>
+<p>Moving on, the next function is Publish. Hereâs the short short version.</p>
+<pre class="screen">public void publish() {
+ try {
+ // 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);
+ //<snip>we removed a bunch of useful stuff here, see the full example for the rest of it</snip>
+
+ //register the business, if the return value is null, something went wrong!
+ BusinessEntity register = clerk.register(myBusEntity);
+ //don't forget to log out!
+ clerk.discardAuthToken();
+ if (register == null) {
+ System.out.println("Save failed!");
+ System.exit(1);
+ }
+ // Now you have a business and service via
+ // the jUDDI API!
+ System.out.println("Success!");
+
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+ }
+</pre>
+
+<p>The UDDIClerk has a register and unregister function for nearly everything for UDDI. Between the UDDIClient and UDDIClerk, thereâs enough helper functions to significantly reduce the amount of code needed to work with UDDI. Hereâs a quick list of things they can do for you:</p>
+<div class="itemizedlist"><ul class="itemizedlist"><li class="listitem">
+Create a tModel Partition, also know as a Key Generator
+</li><li class="listitem">
+Resolve endpoints from WSDLs, Hosting directors, and other binding template references from Access Points <a class="ulink" href="http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908385">http://uddi.org/pubs/uddi-v3.0.2-20041019.htm#_Toc85908385</a>
+</li><li class="listitem">
+Get Bindings by Version
+</li><li class="listitem">
+Add REST or SOAP tModels to a binding template
+</li><li class="listitem">
+Setup asynchronous callbacks for subscriptions
+</li><li class="listitem">
+Compare the values of a tModel Instance Info, such as Quality of Service Metrics
+</li><li class="listitem">
+Create and register services using a WADL or WSDL document
+</li><li class="listitem">
+And moreâ¦
+</li></ul></div>
+
+<p>Weâre also looking for the next thing to add to the client library. Have an idea? Please open a ticket on jUDDIâs Issue Tracker at <a class="ulink" href="https://issues.apache.org/jira/browse/JUDDI">https://issues.apache.org/jira/browse/JUDDI</a>.</p>
+</div>
+</div>
+<div class="section" title="1.4.2. About UDDI Entity Keys"><div class="titlepage"><div><div><h3 class="title"><a id="_about_uddi_entity_keys"/>1.4.2. About UDDI Entity Keys</h3></div></div></div>
+
+<p>There are a couple important notes regarding the use of entity keys. Version 3 of the specification allows for publishers to create their own keys but also instructs implementers to have a default method. Here we have gone with the default implementation by leaving each entityâs "key" field blank in the save call. jUDDIâs default key generator simply takes the nodeâs partition and appends a GUID. In a default installation, it will look something like this:</p>
+<p>uddi:juddi.apache.org:(generated GUID/UUID)</p>
+<p>You can, of course, customize all of this, but that is left for another article. The second important point is that when the BusinessService is saved, we have to explicitly set its parent business key (retrieved from previous call saving the business). This is a necessary step when the service is saved in an independent call like this. Otherwise you would get an error because jUDDI wonât know where to find the parent entity. I could have added this service to the BusinessEntityâs service collection and saved it with the call to saveBusiness. In that scenario we would not have to set the parent business key.</p>
+</div>
+</div>
+<div class="section" title="1.5. A few tips on adding Binding Templates"><div class="titlepage"><div><div><h2 class="title"><a id="_a_few_tips_on_adding_binding_templates"/>1.5. A few tips on adding Binding Templates</h2></div></div></div>
+
+<p>Arguably, the most useful useful part of UDDI is advertising your services similar to a phone book or directory. The important part really isnât that Bobâs Business exists (BusinessEntity), itâs that Bob provides a service (BusinessService) and itâs located at this address. This is where the Binding Template comes it. It identifies an instance of a service, its location and any other metadata associated with the endpoint that someone may want to know.</p>
+<p>This article skips the binding Template data because it can be lengthy, but the full source for these examples shows you exactly how to build and add binding templates.</p>
+</div>
+<div class="section" title="1.6. Conclusion"><div class="titlepage"><div><div><h2 class="title"><a id="_conclusion"/>1.6. Conclusion</h2></div></div></div>
+
+<p>Hopefully this added clarity to the question, "How do I publish a service using jUDDI?".</p>
+</div>
+</div><ul xmlns:d="http://docbook.org/ns/docbook" class="docnav"><li class="previous"><a accesskey="p" href="pr01.html"><strong>Prev</strong>Preface</a></li><li class="up"><a accesskey="u" href="#"><strong>Up</strong></a></li><li class="home"><a accesskey="h" href="index.html"><strong>Home</strong></a></li><li class="next"><a accesskey="n" href="ch02.html"><strong>Next</strong>Chapter 2. jUDDI Client Configuration Guide</a></li></ul></body></html>
\ No newline at end of file
Propchange: juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch01.html
------------------------------------------------------------------------------
svn:executable = *
Added: juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch02.html
URL: http://svn.apache.org/viewvc/juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch02.html?rev=1564891&view=auto
==============================================================================
--- juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch02.html (added)
+++ juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch02.html Wed Feb 5 19:29:33 2014
@@ -0,0 +1,167 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Chapter 2. jUDDI Client Configuration Guide</title><link rel="stylesheet" type="text/css" href="css/jbossorg.css"/><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"/><link rel="home" href="index.html" title="Apache jUDDI Client and GUI Guide"/><link rel="up" href="index.html" title="Apache jUDDI Client and GUI Guide"/><link rel="prev" href="ch01.html" title="Chapter 1. Simple Publishing Using the jUDDI API"/><link rel="next" href="ch03.html" title="Chapter 3. Key Format Templates"/><link rel="copyright" href="ln-d5e27.html" title="Legal Notice"/><meta xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" http-equiv="Content-Type" content="text/html; charset=UTF-8"/></head><body><p xmlns:d="http://docbook.org/ns/docbook" id="title"><a href="http://www.jboss.org" class="site_href"><strong>JBoss.org</strong></a><a href="http://docs.jboss.org/" class="doc_h
ref"><strong>Community Documentation</strong></a></p><ul xmlns:d="http://docbook.org/ns/docbook" class="docnav"><li class="previous"><a accesskey="p" href="ch01.html"><strong>Prev</strong></a></li><li class="next"><a accesskey="n" href="ch03.html"><strong>Next</strong></a></li></ul><div class="chapter" title="Chapter 2. jUDDI Client Configuration Guide"><div class="titlepage"><div><div><h2 class="title"><a id="_juddi_client_configuration_guide"/>Chapter 2. jUDDI Client Configuration Guide</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="ch02.html#_introduction">2.1. Introduction</a></span></dt><dt><span class="section"><a href="ch02.html#_client_settings">2.2. Client Settings</a></span></dt><dt><span class="section"><a href="ch02.html#_nodes">2.3. Nodes</a></span></dt><dd><dl><dt><span class="section"><a href="ch02.html#_transport_options">2.3.1. Transport Options</a></span></dt></dl></dd><dt><span cla
ss="section"><a href="ch02.html#_clerks">2.4. Clerks</a></span></dt><dt><span class="section"><a href="ch02.html#_clerk">2.5. Clerk</a></span></dt><dt><span class="section"><a href="ch02.html#_digital_signatures">2.6. Digital Signatures</a></span></dt><dt><span class="section"><a href="ch02.html#_subscription_callbacks">2.7. Subscription Callbacks</a></span></dt><dt><span class="section"><a href="ch02.html#_xtowsdl">2.8. XtoWsdl</a></span></dt><dt><span class="section"><a href="ch02.html#_embedded_juddi_server">2.9. Embedded jUDDI server</a></span></dt><dd><dl><dt><span class="section"><a href="ch02.html#_requirements">2.9.1. Requirements</a></span></dt><dt><span class="section"><a href="ch02.html#_changes_in_configuration_compared_to_non_embedded">2.9.2. Changes in configuration compared to non-embedded</a></span></dt></dl></dd></dl></div>
+
+<div class="section" title="2.1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="_introduction"/>2.1. Introduction</h2></div></div></div>
+
+<p>The jUDDI Java and .NET clients use an XML configuration file that dictates settings and behaviors.
+This guide provides an overview of the settings. Both .NET and jUDDI use the same configuration file schema. This schema is located within the source tree and with the client distribution packages of jUDDI.</p>
+</div>
+<div class="section" title="2.2. Client Settings"><div class="titlepage"><div><div><h2 class="title"><a id="_client_settings"/>2.2. Client Settings</h2></div></div></div>
+
+<p>The root XML node for the jUDDI client configuration file is always "uddi".</p>
+<pre class="screen"><!-- applies to Java clients only -->
+uddi/reloadDelay</pre>
+
+<p>Multiple clients can be defined in each configuration file.</p>
+<pre class="screen">uddi/client@name="someName"</pre>
+
+</div>
+<div class="section" title="2.3. Nodes"><div class="titlepage"><div><div><h2 class="title"><a id="_nodes"/>2.3. Nodes</h2></div></div></div>
+
+<p>At least one node is required per client. A node represents a one logical UDDI server (or cluster of servers). Each UDDI node should host at least the inquiry service. A client using the jUDDI client package can be configured to access multiple nodes at the same time.</p>
+<pre class="screen"><!-- if isHomeJUDDI is true, then this node is loaded by default, when no node is specified in client code -->
+uddi/client/nodes[]/node@isHomeJUDDI=true/false
+<!-- the name of the node is referenced in client code -->
+uddi/client/nodes[]/node/name
+<!-- the description of the node -->
+uddi/client/nodes[]/node/description
+<!-- the properties section defines HTTP style credentials and a runtime tokenizer for URLs -->
+uddi/client/nodes[]/node/properties
+<!-- The transport represents the class name of the transport mechanism that the client will use to connect
+to the UDDI node. The most commonly used is org.apache.juddi.v3.client.transport.JAXWSTransport, however
+RMITransport, InVMTransport and JAXWSv2TranslationTransport are also defined -->
+uddi/client/nodes[]/node/proxyTransport
+
+<!-- endpoint URLs -->
+uddi/client/nodes[]/node/custodyTransferUrl
+uddi/client/nodes[]/node/inquiryUrl
+uddi/client/nodes[]/node/publishUrl
+uddi/client/nodes[]/node/securityUrl
+uddi/client/nodes[]/node/subscriptionUrl
+uddi/client/nodes[]/node/subscriptionListenerUrl
+<!-- note: this is for jUDDI v3.x servers only and is not part of the UDDI standard -->
+uddi/client/nodes[]/node/juddiApiUrl</pre>
+
+<div class="section" title="2.3.1. Transport Options"><div class="titlepage"><div><div><h3 class="title"><a id="_transport_options"/>2.3.1. Transport Options</h3></div></div></div>
+
+<p>The Proxy Transport defines which mechanism is used for <span class="emphasis"><em>on the wire</em></span> transport of the UDDI XML messages. JAXWS Transport is the most commonly used and assumes SOAP messaging protocol over HTTP transport layer.</p>
+<p>RMI Transport using the Java Remote Method Invocation for transport. Itâs more commonly used for communicating within a J2EE container, but could be used in other cases. Itâs not required by the UDDI specification and is considered a jUDDI add on.</p>
+<p>InVM Transport is for hosting jUDDI services without a J2EE container.</p>
+<p>JAXWSv2TranslationTransport is a bridge for accessing UDDIv2 web services using the UDDIv3 data structures and APIs. Only the Inquiry and Publish services are required and they must point to SOAP/HTTP endpoints for a UDDI v2 node.</p>
+</div>
+</div>
+<div class="section" title="2.4. Clerks"><div class="titlepage"><div><div><h2 class="title"><a id="_clerks"/>2.4. Clerks</h2></div></div></div>
+
+<p>Clerks are responsible for mapping stored user credentials to a Node and for automated registration.</p>
+<pre class="screen"><!-- if true, the contents of the child node xregister are registered when the UDDIClient object is created, using the credential and node reference.-->
+uddi/client/clerks/registerOnStartup=true/false</pre>
+
+</div>
+<div class="section" title="2.5. Clerk"><div class="titlepage"><div><div><h2 class="title"><a id="_clerk"/>2.5. Clerk</h2></div></div></div>
+
+<p>Clerks store credentials and map to a specific node.</p>
+<pre class="screen"><!-- the name is a reference to the Node that these credentials apply to-->
+uddi/client/clerks[]/clerk@node - This is reference to uddi/client/node/name, it must exist
+uddi/client/clerks[]/clerk@name - This is a unique identifier of the clerk
+uddi/client/clerks[]/clerk@publisher - This is the username
+uddi/client/clerks[]/clerk@password
+uddi/client/clerks[]/clerk@isPasswordEncrypted=true/false
+uddi/client/clerks[]/clerk@cryptoProvider=(see Crypto providers)</pre>
+
+<p>Credentials can be encrypted using the included batch/bash scripts and then appended to the configuration. Example with encryption:</p>
+<pre class="screen"><clerk name="default" node="default" publisher="root" password="(cipher text removed)"
+ isPasswordEncrypted="true" cryptoProvider="org.apache.juddi.v3.client.cryptor.AES128Cryptor" /></pre>
+
+<p>Clerks also have settings for the automated cross registration of Businesses and Services on start up.</p>
+<pre class="screen">uddi/client/clerks[]/xregister/service@bindingKey
+uddi/client/clerks[]/xregister/service@fromClerk
+uddi/client/clerks[]/xregister/service@toClerk</pre>
+
+</div>
+<div class="section" title="2.6. Digital Signatures"><div class="titlepage"><div><div><h2 class="title"><a id="_digital_signatures"/>2.6. Digital Signatures</h2></div></div></div>
+
+<p>The Signature section contains settings that map to the Digital Signature Utility that makes working with UDDI digital signatures simple. The section contains all of the settings for both signing and validating signatures.</p>
+<pre class="screen">uddi/client/signature/signingKeyStorePath
+uddi/client/signature/signingKeyStoreFilePassword
+uddi/client/signature/signingKeyStoreFilePassword@isPasswordEncrypted
+uddi/client/signature/signingKeyStoreFilePassword@cryptoProvider
+uddi/client/signature/signingKeyPassword
+uddi/client/signature/signingKeyPassword@isPasswordEncrypted
+uddi/client/signature/signingKeyPassword@cryptoProvider
+uddi/client/signature/signingKeyAlias
+uddi/client/signature/canonicalizationMethod
+uddi/client/signature/signatureMethod=(default RSA_SHA1)
+uddi/client/signature/XML_DIGSIG_NS=(default http://www.w3.org/2000/09/xmldsig#)
+uddi/client/signature/trustStorePath
+uddi/client/signature/trustStoreType
+uddi/client/signature/trustStorePassword
+uddi/client/signature/trustStorePassword@isPasswordEncrypted
+uddi/client/signature/trustStorePassword@cryptoProvider
+<!-- checks signing certificates for timestamp validity -->
+uddi/client/signature/checkTimestamps
+<!-- checks signing certificates for trust worthiness -->
+uddi/client/signature/checkTrust
+<!-- checks signing certificates for revocation -->
+uddi/client/signature/checkRevocationCRL
+uddi/client/signature/keyInfoInclusionSubjectDN
+uddi/client/signature/keyInfoInclusionSerial
+uddi/client/signature/keyInfoInclusionBase64PublicKey
+<!-- default is http://www.w3.org/2000/09/xmldsig#sha1 -->
+uddi/client/signature/digestMethod</pre>
+
+</div>
+<div class="section" title="2.7. Subscription Callbacks"><div class="titlepage"><div><div><h2 class="title"><a id="_subscription_callbacks"/>2.7. Subscription Callbacks</h2></div></div></div>
+
+<p>The subscriptionCallbacks section defines settings uses by the subscription callback API. This enables developers to create capabilities that need to be notified immediately when something in UDDI changes through the use of subscriptions.</p>
+<pre class="screen">uddi/client/subscriptionCallbacks/keyDomain
+uddi/client/subscriptionCallbacks/listenUrl this is the URL that is used for callbacks, should be externally resolvable
+uddi/client/subscriptionCallbacks/autoRegisterBindingTemplate=true/false
+uddi/client/subscriptionCallbacks/autoRegisterBusinessServiceKey=(key) append callback endpoint to this service
+uddi/client/subscriptionCallbacks/signatureBehavior=(AbortIfSigned,Sign,DoNothing,SignOnlyIfParentIsntSigned), default DoNothing. Applies when auto registering the endpoint to a business or service that is already signed.</pre>
+
+</div>
+<div class="section" title="2.8. XtoWsdl"><div class="titlepage"><div><div><h2 class="title"><a id="_xtowsdl"/>2.8. XtoWsdl</h2></div></div></div>
+
+<p>XtoWsdl represents configuration parameters for importing WSDL or WADL files. Currently, the only setting is for ignoring SSL errors when fetching remote WSDL or WADL files.</p>
+<pre class="screen">uddi/client/XtoWsdl/IgnoreSSLErrors=true or false</pre>
+
+</div>
+<div class="section" title="2.9. Embedded jUDDI server"><div class="titlepage"><div><div><h2 class="title"><a id="_embedded_juddi_server"/>2.9. Embedded jUDDI server</h2></div></div></div>
+
+<p>jUDDI has the ability to run in embedded mode. This means that the jUDDI services can operate without a web servlet container, such as Tomcat or JBoss. Typically, this is something that application developers would use for more advanced scenarios and for operation without network connectivity.</p>
+<div class="section" title="2.9.1. Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="_requirements"/>2.9.1. Requirements</h3></div></div></div>
+
+<p>A database server, if one is not available, the embedded Derby engine can be used.</p>
+</div>
+<div class="section" title="2.9.2. Changes in configuration compared to non-embedded"><div class="titlepage"><div><div><h3 class="title"><a id="_changes_in_configuration_compared_to_non_embedded"/>2.9.2. Changes in configuration compared to non-embedded</h3></div></div></div>
+
+<div class="itemizedlist"><ul class="itemizedlist"><li class="listitem">
+META-INF/embedded-uddi.xml needs to contain the connection settings for InVmTransport.
+</li></ul></div>
+
+
+<pre class="literallayout"> <!-- In VM Transport Settings -->
+ <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></pre>
+
+
+<div class="itemizedlist"><ul class="itemizedlist"><li class="listitem">
+The serverside config file juddiv3.xml needs to be added to the classpath.
+</li><li class="listitem">
+A META-INF/persistence.xml needs to be added.
+</li><li class="listitem">
+Add the juddi-core (UDDI server) and derby (Embedded Database) dependencies to the pom. Use the juddi-core-openjpa jar for OpenJPA.
+</li></ul></div>
+
+<p>See also the hello-world-embedded example.</p>
+</div>
+</div>
+</div><ul xmlns:d="http://docbook.org/ns/docbook" class="docnav"><li class="previous"><a accesskey="p" href="ch01.html"><strong>Prev</strong>Chapter 1. Simple Publishing Using the jUDDI API</a></li><li class="up"><a accesskey="u" href="#"><strong>Up</strong></a></li><li class="home"><a accesskey="h" href="index.html"><strong>Home</strong></a></li><li class="next"><a accesskey="n" href="ch03.html"><strong>Next</strong>Chapter 3. Key Format Templates</a></li></ul></body></html>
\ No newline at end of file
Propchange: juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch02.html
------------------------------------------------------------------------------
svn:executable = *
Added: juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch03.html
URL: http://svn.apache.org/viewvc/juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch03.html?rev=1564891&view=auto
==============================================================================
--- juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch03.html (added)
+++ juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch03.html Wed Feb 5 19:29:33 2014
@@ -0,0 +1,76 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Chapter 3. Key Format Templates</title><link rel="stylesheet" type="text/css" href="css/jbossorg.css"/><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"/><link rel="home" href="index.html" title="Apache jUDDI Client and GUI Guide"/><link rel="up" href="index.html" title="Apache jUDDI Client and GUI Guide"/><link rel="prev" href="ch02.html" title="Chapter 2. jUDDI Client Configuration Guide"/><link rel="next" href="ch04.html" title="Chapter 4. Using the jUDDI GUI"/><link rel="copyright" href="ln-d5e27.html" title="Legal Notice"/><meta xmlns:d="http://docbook.org/ns/docbook" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" http-equiv="Content-Type" content="text/html; charset=UTF-8"/></head><body><p xmlns:d="http://docbook.org/ns/docbook" id="title"><a href="http://www.jboss.org" class="site_href"><strong>JBoss.org</strong></a><a href="http://docs.jboss.org/" class="doc_href"><strong>Commu
nity Documentation</strong></a></p><ul xmlns:d="http://docbook.org/ns/docbook" class="docnav"><li class="previous"><a accesskey="p" href="ch02.html"><strong>Prev</strong></a></li><li class="next"><a accesskey="n" href="ch04.html"><strong>Next</strong></a></li></ul><div class="chapter" title="Chapter 3. Key Format Templates"><div class="titlepage"><div><div><h2 class="title"><a id="chapter-KeyFormatTemplates"/>Chapter 3. Key Format Templates</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="ch03.html#_uddiv3_key_format">3.1. UDDIv3 key format</a></span></dt><dt><span class="section"><a href="ch03.html#_juddi_key_format_templates">3.2. jUDDI key format templates</a></span></dt><dd><dl><dt><span class="section"><a href="ch03.html#_advantages_of_using_a_template">3.2.1. Advantages of using a template</a></span></dt><dt><span class="section"><a href="ch03.html#_default_uddikeyconvention_key_templates">3.2.2.
Default UDDIKeyConvention Key Templates</a></span></dt><dt><span class="section"><a href="ch03.html#_how_to_use_the_templates">3.2.3. How to use the templates?</a></span></dt><dt><span class="section"><a href="ch03.html#_where_to_define_to_properties">3.2.4. Where to define to properties?</a></span></dt></dl></dd></dl></div>
+
+<div class="section" title="3.1. UDDIv3 key format"><div class="titlepage"><div><div><h2 class="title"><a id="_uddiv3_key_format"/>3.1. UDDIv3 key format</h2></div></div></div>
+
+<p>The UDDI v3 keys are formatted such that they are human readable. The short story is that UDDI v3 keys are formatted like: <span class="emphasis"><em>uddi:<domain>:name</em></span>. For example, if you wanted a tModel defined as "uddi:www.mycompany.com:serviceauthenticationmethod", you would first have to create a tModel key generator with value "uddi:www.mycompany.com:keygenerator".</p>
+</div>
+<div class="section" title="3.2. jUDDI key format templates"><div class="titlepage"><div><div><h2 class="title"><a id="_juddi_key_format_templates"/>3.2. jUDDI key format templates</h2></div></div></div>
+
+<p>The jUDDI client has taken the key format approach one step further so the name part of the key actually helps you understand what the key is for, or even better in the case of a binding template what server registered the key.</p>
+<div class="section" title="3.2.1. Advantages of using a template"><div class="titlepage"><div><div><h3 class="title"><a id="_advantages_of_using_a_template"/>3.2.1. Advantages of using a template</h3></div></div></div>
+
+<p>Using a binding Key with format <code class="literal">uddi:${keyDomain}:binding_${serverName}_${serviceName}_${portName}_${serverPort}</code> contains valuable information for two reasons
+- you can tell from the bindingKey what server registered it. This is helpful information if you want to debug connectivity issues between a client and the UDDI server.
+- if a server goes to register a bindingTemplate it registered before it wonât create a second bindingTemplate, so it wonât leave behind dead or duplicate bindingTemplates.</p>
+</div>
+<div class="section" title="3.2.2. Default UDDIKeyConvention Key Templates"><div class="titlepage"><div><div><h3 class="title"><a id="_default_uddikeyconvention_key_templates"/>3.2.2. Default UDDIKeyConvention Key Templates</h3></div></div></div>
+
+<p>The default templates setup by the jUDDI client are:</p>
+
+<pre class="literallayout">uddi:${keyDomain}:business_${businessName}
+uddi:${keyDomain}:service_${serviceName}
+uddi:${keyDomain}:service_cache_${serverName}
+uddi:${keyDomain}:binding_${serverName}_${serviceName}_${portName}_${serverPort}</pre>
+
+
+<p>where tokens are expressed using <code class="literal">${}</code>. The templates are defined in the UDDIKeyConvention class.</p>
+</div>
+<div class="section" title="3.2.3. How to use the templates?"><div class="titlepage"><div><div><h3 class="title"><a id="_how_to_use_the_templates"/>3.2.3. How to use the templates?</h3></div></div></div>
+
+<p>At runtime a serviceKey can be obtained using</p>
+
+<pre class="literallayout">String serviceKey = UDDIKeyConvention.getServiceKey(properties, serviceName);</pre>
+
+
+<p>The serviceName can be specified in as a property in the first argument, or it can explicitly passed as the second argument. Using the second argument overrides whatâs specified in the properties. By default it will use the service template <code class="literal">uddi:${keyDomain}:service_${serviceName}</code>, but if you wish to use a different template you can simple specify that as a property, for example</p>
+
+<pre class="literallayout">String myCustomServiceFormat = "uddi:${keyDomain}:s_${serviceName}";
+properties.add(Property.SERVICE_KEY_FORMAT, myCustomServiceFormat);
+String myCustomFormattedServiceKey = UDDIKeyConvention.getServiceKey(properties, serviceName);</pre>
+
+
+</div>
+<div class="section" title="3.2.4. Where to define to properties?"><div class="titlepage"><div><div><h3 class="title"><a id="_where_to_define_to_properties"/>3.2.4. Where to define to properties?</h3></div></div></div>
+
+<p>You can define the properties in your code, or you can obtain and pass in the properties defined in your <code class="literal">uddi.xml</code>. For an exmaple of this you can check out the <code class="literal">META-INF/wsdl2uddi-uddi.xml</code> of the <code class="literal">wsdl2uddi</code> example where for the <code class="literal">default</code> node we set</p>
+
+<pre class="literallayout"> ...
+ <nodes>
+ <node>
+ <name>default</name>
+ <properties>
+ <property name="serverName" value="localhost"/>
+ <property name="serverPort" value="8080"/>
+ <property name="keyDomain" value="uddi.joepublisher.com"/>
+ <property name="businessName" value="WSDL-Business"/>
+ </properties>
+ ...
+ </node>
+ ...
+ </nodes>
+ ...</pre>
+
+
+<p>and you can obtain the properties like</p>
+
+<pre class="literallayout">UDDIClient uddiClient = new UDDIClient("META-INF/wsdl2uddi-uddi.xml");
+Properties properties = uddiClient.getClientConfig().getUDDINode("default").getProperties();</pre>
+
+
+<p>This is exactly what the WSDL2UDDI implementation does, and it the reason the class requires the properties in the constructor.</p>
+</div>
+</div>
+</div><ul xmlns:d="http://docbook.org/ns/docbook" class="docnav"><li class="previous"><a accesskey="p" href="ch02.html"><strong>Prev</strong>Chapter 2. jUDDI Client Configuration Guide</a></li><li class="up"><a accesskey="u" href="#"><strong>Up</strong></a></li><li class="home"><a accesskey="h" href="index.html"><strong>Home</strong></a></li><li class="next"><a accesskey="n" href="ch04.html"><strong>Next</strong>Chapter 4. Using the jUDDI GUI</a></li></ul></body></html>
\ No newline at end of file
Propchange: juddi/cms-site/trunk/content/docs/3.2/juddi-client-guide/html/ch03.html
------------------------------------------------------------------------------
svn:executable = *
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@juddi.apache.org
For additional commands, e-mail: commits-help@juddi.apache.org