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: [email protected]
For additional commands, e-mail: [email protected]
![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"){kind=link}
