http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/JBossDeploy.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/JBossDeploy.xml b/docs/userguide/en-US/JBossDeploy.xml deleted file mode 100644 index 917f48d..0000000 --- a/docs/userguide/en-US/JBossDeploy.xml +++ /dev/null @@ -1,92 +0,0 @@ -<?xml version='1.0'?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" -"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; -]> - -<!-- chapter: Subscription --> -<chapter id="chap-deployjboss"> - <title>Deploying to JBoss 5.1.0.GA</title> - - <!-- section: Introduction --> - <section id="sect-deployjboss"> - <title>Introduction</title> - <para> - This section describes how to deploy juddi to JBoss 5.1.0.GA. These instructions will use CXF as a webservice framework rather than JBoss WS native. - </para> - - <para> - First, download jboss-5.1.0.GA - the zip or tar.gz bundle may be found -at http://www.jboss.org/jbossas/downloads/. Download the bundle and uncompress it. - </para> - - <para> - Next, download jbossws-cxf-3.2.0.zip - which can be found at http://www.jboss.org/jbossws/downloads/. Uncompress it. - </para> - - <para> - In the uncompressed jbossws-cxf-3.2.0, rename <filename>ant.properties-example</filename> to <filename>ant.properties</filename>. Edit ant.properties and set the jboss.510.home property to the directory where you unpacked your jboss-5.1.0.GA installation. - </para> - - <para> - Next, execute the ant target "ant deploy-jboss510". Once CXF is deployed, start the server and verify the installation with 'ant tests'. - </para> - - </section> - - <section id="sect-juddi-war"> - <title>Add juddiv3.war</title> - <para> - Copy juddiv3.war to server/default/deploy and unpack it. - </para> - - <para> - Insert <filename>jboss-web.xml</filename> into the juddiv3.war/WEB-INF directory , should look like the following : - <programlisting><xi:include href="extras/jboss-web.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - </para> - </section> - - <!-- section: Two node example setup: Sales and Marketing --> - <section id="sect-datasource"> - <title>Configure Datasource</title> - <para> - The first step for configuring a datasource is to copy your JDBC driver into the classpath. Copy your JDBC driver into <filename>${jboss.home.dir}/server/${configuration}/lib</filename>, where configuration is the profile you wish to start with (default, all, etc.). - - Example : - <programlisting>cp mysql-connector-java-5.0.8-bin.jar /opt/jboss-5.1.0.GA/server/default/lib</programlisting> - </para> - - <para> - Next, configure a JBoss datasource file for your db. Listed below is an example datasource for MySQL : - </para> - <programlisting><xi:include href="extras/juddiv3-ds.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - Next, make a few changes to the <filename>juddiv3.war/classes/META-INF/persistence.xml</filename>. - - Change the "hibernate.dialect" property to match the database you have chosen for persistence. For MySQL, change the value of hibernate.dialect to "org.hibernate.dialect.MySQLDialect". A full list of dialects available can be found in the hibernate documentation (https://www.hibernate.org/hib_docs/v3/api/org/hibernate/dialect/package-summary.html). - - Next, change the <jta-data-source> tags so that it reads <non-jta-data-source>, and change the value from java:comp/env/jdbc/JuddiDS to java:/JuddiDS. - </para> - - </section> - -</chapter>
http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/Legal_Notice.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/Legal_Notice.xml b/docs/userguide/en-US/Legal_Notice.xml deleted file mode 100644 index 45c322c..0000000 --- a/docs/userguide/en-US/Legal_Notice.xml +++ /dev/null @@ -1,44 +0,0 @@ -<?xml version='1.0' encoding='utf-8' ?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE legalnotice PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ - -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; - -]> - -<legalnotice lang="en-US"> - <para> - Copyright <trademark class="copyright"></trademark> 2010 - </para> - - <para> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - http://www.apache.org/licenses/LICENSE-2.0 - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - </para> - -</legalnotice> - http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/Preface.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/Preface.xml b/docs/userguide/en-US/Preface.xml deleted file mode 100644 index 9b28bd8..0000000 --- a/docs/userguide/en-US/Preface.xml +++ /dev/null @@ -1,41 +0,0 @@ -<?xml version='1.0'?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; -]> - -<preface id="User_Guide-Preface"> - <title>Preface</title> - <xi:include href="Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude";> - <xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude";> - <!-- <xi:include href="Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> --> - <!-- maybe we want to have info here about the book source --> - </xi:fallback> - </xi:include> - - - - <xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude";> - <xi:fallback xmlns:xi="http://www.w3.org/2001/XInclude";> - <xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> - </xi:fallback> - </xi:include> - -</preface> http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/Revision_History.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/Revision_History.xml b/docs/userguide/en-US/Revision_History.xml deleted file mode 100644 index 7e21017..0000000 --- a/docs/userguide/en-US/Revision_History.xml +++ /dev/null @@ -1,59 +0,0 @@ -<?xml version='1.0'?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; -]> - -<appendix id="appe-Publican-Revision_History"> - <title>Revision History</title> - <simpara> - <revhistory> - <revision> - <revnumber>1.1</revnumber> - <date>Thu Jan 07 2010</date> - <author> - <firstname>Tom</firstname> - <surname>Cunningham</surname> - <email>tcunn...@apache.org</email> - </author> - <revdescription> - <simplelist> - <member>Translated Dev Guide to docbook</member> - </simplelist> - </revdescription> - </revision> - <revision> - <revnumber>1.0</revnumber> - <date>Mon Nov 16 2009</date> - <author> - <firstname>Darrin</firstname> - <surname>Mison</surname> - <email>dmi...@redhat.com</email> - </author> - <revdescription> - <simplelist> - <member>Created from community jUDDI Guide</member> - </simplelist> - </revdescription> - </revision> - </revhistory> - </simpara> -</appendix> - http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/Root_seed_data.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/Root_seed_data.xml b/docs/userguide/en-US/Root_seed_data.xml deleted file mode 100644 index dc3bab4..0000000 --- a/docs/userguide/en-US/Root_seed_data.xml +++ /dev/null @@ -1,145 +0,0 @@ -<?xml version='1.0'?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" -"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; -]> - -<!-- chapter: Using the UDDI-Client --> -<chapter id="chap-root_seed_data"> - <title>Root Seed Data</title> - - <!-- section: Introduction --> - <section id="sect-root_seed_data_intro"> - <title>Introduction</title> - <para> - As of UDDI v3, each registry need to have a <literal>ârootâ</literal> publisher. - The root publisher is the owner of the UDDI services (inquiry, publication, etc). - There can only be one root publisher per node. JUDDI ships some default seed data - for the root account. The default data can be found in the - <filename>juddi-core-3.x.jar</filename>, under - <filename>juddi_install_data/</filename>. By default jUDDI installs two - Publishers: <literal>ârootâ</literal> and <literal>âuddiâ</literal>. Root owns the - root partition, and uddi owns all the other seed data such as pre-defined tModels. - </para> - - </section> - - <!-- section: Seed Data Files --> - <section id="sect-seed_data_files"> - <title>Seed Data Files</title> - - <para> - For each publisher there are four seed data files that will be read the first time - you start jUDDI: - </para> - - <screen><xi:include href="extras/Root_seed_data_1.screen" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></screen> - - <para> - For example the content of the <filename>root_Publisher.xml</filename> looks like - </para> - - <programlisting language="XML"><xi:include href="extras/Root_seed_data_1.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - Each publisher should have its own key generator schema so that custom generated - keys cannot end up being identical to keys generated by other publishers. It is - therefor that the each publisher need to define their own KenGenerator tModel. The - tModel Key Generator is defined in the file <filename>root_tModelKeyGen.xml</filename> - and the content of this file is - </para> - - <programlisting language="XML"><xi:include href="extras/Root_seed_data_2.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - - <para> - This means that the legal format of keys used by the root publisher need to be in - the form <literal>uddi:juddi.apache.org:<text-of-chioce></literal> The use - of other types of format will lead to an 'illegal key' error. The root publisher - can only own one KeyGenerator while any other publisher can own more then one - KeyGenerator. KeyGenerators should not be shared unless there is a good reason to - do so. If you want to see your publisher with more then just the one KeyGenerator - tModel, you can use the<filename> <publisher>_tModels.xml</filename> file. - </para> - - <para> - Finally, in the <filename><publisher>_BusinessEntity.xml</filename> file can - be used to setup Business and Service data. In the <filename>root_BusinessEntity.xml</filename> we - specified the ASF Business, and the UDDI services; Inquiry, Publish, etc.: - </para> - - <programlisting language="XML"><xi:include href="extras/Root_seed_data_3.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - Note that the seeding process only kicks off if no publishers exist in the - database. So this will only work with a clean database, unless you set - <literal>juddi.seed.always</literal> to true. Then it will re-apply all files with - the exception of the root data files. Note that this can lead to losing data that - was added to entities that are re-seeded, since data is not merged. - </para> - - </section> - - <!-- section: Tokens in the Seed Data --> - <section id="sect-tokens_in_the_seed_data"> - <title>Token in the Seed Data</title> - <para> - You may have noticed the tokens in the <filename>root_BusinessEntity.xml</filename> - file (<literal>${juddi.server.baseurl}</literal>. The value of this tokens can set in - the <filename>juddiv3.properties</filename> file. The value substitution takes place - at runtime, so that different nodes can do the substitution with their own value if needed. - </para> - </section> - - <!-- section: Customer Seed Data --> - <section id="sect-custom_seed_data"> - <title>Customer Seed Data</title> - <para> - In your deployment you probably do not want to use the Seed Data shipped with the - default jUDDI install. The easiest way to overwrite this data is to add it to a - directory call <filename>juddi_custom_install_data</filename> in the - <filename>juddiv3.war/WEB-INF/classes/</filename> directory. That way you don't - have to modify the <filename>juddi-core-3.x.jar</filename>. Additionally if your - root publisher is not called ârootâ you will need to set the - <property>juddi.root.publisher</property> property in the - <filename>juddiv3.properties</filename> file to something other then - </para> - - <programlisting><xi:include href="extras/Root_seed_data_1.properties" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - The <filename>juddiv3.war</filename> ships with two example data directory. One - for the Sales Affiliate, and one for the Marketing Affiliate. To use the Sales - Seed Data, in the <filename>juddiv3.war/WEB-INF/classes/</filename>, rename the - directory - </para> - - <screen><xi:include href="extras/Root_seed_data_2.screen" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></screen> - - <para> - before you start jUDDI the first time. It will then use this data to populate the - database. If you want to rerun you can trash the database it created and restart - tomcat. Don't forget to set the tokens in the <filename>juddiv3.properties</filename> file. - </para> - </section> - - -</chapter> http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/SimplePublish.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/SimplePublish.xml b/docs/userguide/en-US/SimplePublish.xml deleted file mode 100644 index 0b2fc0b..0000000 --- a/docs/userguide/en-US/SimplePublish.xml +++ /dev/null @@ -1,315 +0,0 @@ -<?xml version='1.0'?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; -]> -<chapter id="chap-SimplePublish"> - <title>Simple Publishing Using the jUDDI API</title> - <para> - 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. - </para> - <section> - <title>UDDI Data Model</title> - <para> - 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. - </para> - <para> - Below is a great diagram of the UDDI data model (taken directly from the specification): - </para> - <figure id="fig-UDDI-coredatastructures"> - <title>UDDI Core Data Structures</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/uddi_core_datastructures.gif" scalefit="1" /> - </imageobject> - <textobject> - <phrase>UDDI core data structures</phrase> - </textobject> - </mediaobject> - </figure> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - 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.) - </para> - <para> - 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. - </para> - <para> - 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. - </para> - </section> - <section> - <title>jUDDI Additions to the Model</title> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - 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. - </para> - <para> - One quick note: 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. - </para> - </section> - <section> - <title>UDDI and jUDDI API</title> - <para> - 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. - </para> - <para> - UDDI divides their API into several âsetsâ â each representing a specific area of functionality. The API sets are listed below: - </para> - <itemizedlist> - <listitem> - <para> - Inquiry â deals with querying the registry to return details on entities within - </para> - </listitem> - <listitem> - <para> - Publication â handles publishing entities into the registry - </para> - </listitem> - <listitem> - <para> - Security â open-ended specification that handles authentication - </para> - </listitem> - <listitem> - <para> - Custody and Ownership Transfer â deals with transferring ownership and custody of entities - </para> - </listitem> - <listitem> - <para> - Subscription â allows clients to retrieve information on entities in a timely manner using a subscription format - </para> - </listitem> - <listitem> - <para> - Subscription Listener â client API that accepts subscription results - </para> - </listitem> - <listitem> - <para> - Value Set (Validation and Caching)â validates keyed reference values (not implemented by jUDDI) - </para> - </listitem> - <listitem> - <para> - Replication â deals with federation of data between registry nodes (not implemented by jUDDI) - </para> - </listitem> - </itemizedlist> - <para> - The most commonly used APIs are the Inquiry, Publication and Security APIs. These APIs provide the standard functions for interacting with the registry. - </para> - <para> - 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. - </para> - <para> - 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. - </para> - </section> - <section> - <title>Getting Started</title> - <para> - 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 - <ulink url="http://apachejuddi.blogspot.com/2010/02/getting-started-with-juddi-v3.html";>article</ulink> - that explains how to start the jUDDI server. - </para> - <section> - <title>Simple Publishing Example</title> - <para> - We will now go over the âsimple-publishâ example found in the documentation. This sample expands upon the HelloWorld example in that after retrieving an authentication token, a Publisher, BusinessEntity and BusinessService are published to the registry. - </para> - <para> - The sample consists of only one class: SimplePublish. Letâs start by taking a look at the constructor: - </para> - <programlisting language="Java" role="JAVA"> - public SimplePublish() { - try { - String clazz = UDDIClientContainer.getUDDIClerkManager(null). - getClientConfig().getUDDINode("default").getProxyTransport(); - Class<?> transportClass = ClassUtil.forName(clazz, Transport.class); - if (transportClass!=null) { - Transport transport = (Transport) transportClass. - getConstructor(String.class).newInstance("default"); - - security = transport.getUDDISecurityService(); - juddiApi = transport.getJUDDIApiService(); - publish = transport.getUDDIPublishService(); - } - } catch (Exception e) { - e.printStackTrace(); - } - } - </programlisting> - <para> - 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. - </para> - <para> - Once the transport is instantiated, we grab the three API sets we need for this demo: 1) the Security API set so we can get authorization tokens, 2) the proprietary jUDDI API set so we can save a Publisher and 3) the Publication API set so we can actually publish - entities to the registry. - </para> - <para> - All the magic happens in the publish method. We will look at that next. - </para> - <para> - Here are the first few lines of the publish method: - </para> - <programlisting language="Java" role="JAVA"> - // Setting up the values to get an authentication token for the 'root' user ('root' user - // has admin privileges and can save other publishers). - GetAuthToken getAuthTokenRoot = new GetAuthToken(); - getAuthTokenRoot.setUserID("root"); - getAuthTokenRoot.setCred(""); - - // Making API call that retrieves the authentication token for the 'root' user. - AuthToken rootAuthToken = security.getAuthToken(getAuthTokenRoot); - System.out.println ("root AUTHTOKEN = " + rootAuthToken.getAuthInfo()); - </programlisting> - <para> - This code simply gets the authorization token for the ârootâ user. The ârootâ user (or publisher) is automatically installed in every jUDDI instance and acts as the âadministratorâ for jUDDI API calls. Additionally, the ârootâ 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. - </para> - <para> - Letâs get back to the code. Now that we have root authorization, we can add a publisher: - </para> - <programlisting language="Java" role="JAVA"> - // Creating a new publisher that we will use to publish our entities to. - Publisher p = new Publisher(); - p.setAuthorizedName("my-publisher"); - p.setPublisherName("My Publisher"); - - // Adding the publisher to the "save" structure, using the 'root' user authentication info and - // saving away. - SavePublisher sp = new SavePublisher(); - sp.getPublisher().add(p); - sp.setAuthInfo(rootAuthToken.getAuthInfo()); - juddiApi.savePublisher(sp); - </programlisting> - <para> - Here weâve simply used the jUDDI API to save a publisher with authorized name âmy-publisherâ. Notice how the authorization token for the ârootâ user is used. Next, we need to get the authorization token for this new publisher: - </para> - <programlisting language="Java" role="JAVA"> - // Our publisher is now saved, so now we want to retrieve its authentication token - GetAuthToken getAuthTokenMyPub = new GetAuthToken(); - getAuthTokenMyPub.setUserID("my-publisher"); - getAuthTokenMyPub.setCred(""); - AuthToken myPubAuthToken = security.getAuthToken(getAuthTokenMyPub); - System.out.println ("myPub AUTHTOKEN = " + myPubAuthToken.getAuthInfo()); - </programlisting> - <para> - This is pretty straightforward. Youâll note that no credentials have been set on both authorization calls. This is because weâre using the default authenticator which doesnât require credentials. We have our authorization token for our new - publisher, now we can simply publish away: - </para> - <programlisting language="Java" role="JAVA"> - // Creating the parent business entity that will contain our service. - BusinessEntity myBusEntity = new BusinessEntity(); - Name myBusName = new Name(); - myBusName.setValue("My Business"); - myBusEntity.getName().add(myBusName); - - // Adding the business entity to the "save" structure, using our publisher's authentication info - // and saving away. - SaveBusiness sb = new SaveBusiness(); - sb.getBusinessEntity().add(myBusEntity); - sb.setAuthInfo(myPubAuthToken.getAuthInfo()); - BusinessDetail bd = publish.saveBusiness(sb); - String myBusKey = bd.getBusinessEntity().get(0).getBusinessKey(); - System.out.println("myBusiness key: " + myBusKey); - - // Creating a service to save. Only adding the minimum data: the parent business key retrieved - //from saving the business above and a single name. - BusinessService myService = new BusinessService(); - myService.setBusinessKey(myBusKey); - Name myServName = new Name(); - myServName.setValue("My Service"); - myService.getName().add(myServName); - // Add binding templates, etc... - - // Adding the service to the "save" structure, using our publisher's authentication info and - // saving away. - SaveService ss = new SaveService(); - ss.getBusinessService().add(myService); - ss.setAuthInfo(myPubAuthToken.getAuthInfo()); - ServiceDetail sd = publish.saveService(ss); - String myServKey = sd.getBusinessService().get(0).getServiceKey(); - System.out.println("myService key: " + myServKey); - </programlisting> - <para> - 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 (and in fact, have not added any BindingTemplates to the service). 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. - </para> - <para> - 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: - </para> - <blockquote> - <para> - uddi:juddi.apache.org:<GUID> - </para> - </blockquote> - <para> - 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, Iâve had 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 I would not have to set the parent business key. - </para> - </section> - </section> - <section> - <title>Conclusion</title> - <para> - That does it for this article. Hopefully I managed to clear some of the confusion around the open-ended question, âHow do I publish a service using jUDDI?â. - </para> - </section> -</chapter> - http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/Subscription.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/Subscription.xml b/docs/userguide/en-US/Subscription.xml deleted file mode 100644 index 69e2db7..0000000 --- a/docs/userguide/en-US/Subscription.xml +++ /dev/null @@ -1,444 +0,0 @@ -<?xml version='1.0'?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" -"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; -]> - -<!-- chapter: Subscription --> -<chapter id="chap-Subscription"> - <title>Subscription</title> - - <!-- section: Introduction --> - <section id="sect-subscription_intro"> - <title>Introduction</title> - <para> - Subscriptions come to play in a multi-registry setup. Within your company you may - have the need to run with more then one UDDI, let's say one for each department, - where you limit access to the systems in each department to just their own UDDI - node. However you may want to share some services cross departments. The - subscription API can help you cross registering those services and keeping them up - to date by sending out notifications as the registry information in the parent - UDDI changes. - </para> - - <para> - There are two type of subscriptions: - </para> - - <variablelist> - <varlistentry> - <term>asynchronous</term> - <listitem> - <para> - Save a subscription, and receive updates on a certain schedule. - </para> - </listitem> - </varlistentry> - <varlistentry> - <term>synchronous</term> - <listitem> - <para> - Save a subscription and invoke the get_Subscription and get a synchronous reply. - </para> - </listitem> - </varlistentry> - </variablelist> - - <para> - The notification can be executed in a synchronous and an asynchronous way. The - asynchronous way requires a listener service to be installed on the node to which - the notifications should be sent. - </para> - - </section> - - - <!-- section: Two node example setup: Sales and Marketing --> - <section id="sect-Two_node_example"> - <title>Two node example setup: Sales and Marketing</title> - <para> - In this example we are setting up a node for 'sales' and a node for 'marketing'. - For this you need to deploy jUDDI to two different services, then you need to do - the following setup: - </para> - - <!-- procedure: Setup Node 1: Sales --> - <procedure id="proc-Two_node_example_Setup_Node1"> - <title>Setup Node 1: Sales</title> - <step> - <para> - Create <filename>juddi_custom_install_data</filename>. - </para> - <screen><xi:include href="extras/Subscription_1.screen" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></screen> - </step> - <step> - <para> - edit: <filename>webapps/juddiv3/WEB-INF/classes/juddiv3.properties</filename> and set the following - property values where 'sales' is the DNS name of your server. - </para> - <programlisting><xi:include href="extras/Subscription_1.properties" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - </step> - <step> - <para> - Start the server (tomcat), which will load the UDDI seed data (since this - is the first time you're starting jUDDI, see - <xref linkend="chap-root_seed_data" />) - </para> - <screen><xi:include href="extras/Subscription_3.screen" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></screen> - </step> - <step> - <para> - Open your browser to <ulink url="http://sales:8080/juddiv3"/>. You should see: - </para> - - <!-- figure: Sales Node Installation --> - <figure id="fig-sales_node_installation"> - <title>Sales Node Installation</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/sales_node_installation.png" scalefit="1"/> - </imageobject> - <textobject> - <phrase>Sales Node Installation</phrase> - </textobject> - </mediaobject> - </figure> - - </step> - </procedure> - - <!-- procedure: Setup Node 2: Marketing --> - <procedure> - <title>Setup Node 2: Marketing</title> - <step> - <para> - Create <filename>juddi_custom_install_data</filename>. - </para> - <screen><xi:include href="extras/Subscription_4.screen" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></screen> - </step> - <step> - <para> - edit: <filename>webapps/juddiv3/WEB-INF/classes/juddiv3.properties</filename> and set the following - property values where 'marketing' is the DNS name of your server. - </para> - <programlisting><xi:include href="extras/Subscription_2.properties" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - </step> - <step> - <para> - Start the server (tomcat), which will load the UDDI seed data (since this - is the first time you're starting jUDDI, see - <xref linkend="chap-root_seed_data" />) - </para> - <screen><xi:include href="extras/Subscription_5.screen" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></screen> - </step> - <step> - <para> - Open your browser to <ulink url="http://marketing:8080/juddiv3"/> . - You should see: - </para> - <!-- figure: Marketing Node Installation --> - <figure id="fig-Marketing_Node_Installation"> - <title>Marketing Node Installation</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/marketing_node_installation.png" scalefit="1"/> - </imageobject> - <textobject> - <phrase>Marketing Node Installation</phrase> - </textobject> - </mediaobject> - </figure> - </step> - - </procedure> - - - <para> - Note that we kept the root partition the same as sales and marketing are in the - same company, however the Node Id and Name are different and reflect that this - node is in 'sales' or 'marketing'. - </para> - - <para> - Finally you will need to replace the sales server's - <filename>uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml</filename> - with <filename>uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml.sales</filename>. - Then, edit the - <filename>uddi-portlets.war/WEB-INF/classes/META-INF/uddi.xml</filename> and set - the following properties: - </para> - - <programlisting language="XML"><xi:include href="extras/Subscription_1.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - Log into the sales portal: <ulink url="http://sales:8080/pluto"/> with - username/password: sales/sales. - </para> - - <!-- figure: Sales Services --> - <figure id="fig-sales_services"> - <title>Sales Services</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/sales_services.png"/> - </imageobject> - <textobject> - <phrase>Sales Services</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - Before logging into the marketing portal, replace marketing's - <filename>uddi-portlet.war/WEB-INF/classes/META-INF/uddi.xml</filename> - with <filename>udd-portlet.war/WEB-INF/classes/META-INF/uddi.xml.marketing</filename>. - Then you will need to edit the - <filename>uddi-portlet.war/WEB-INF/classes/META_INF/uddi.xml</filename> and set - the following properties: - </para> - - <programlisting language="XML"><xi:include href="extras/Subscription_2.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - Now log into the marketing portal <ulink url="http://marketing:8080/pluto"/> with - username/password: marketing/ marketing. In the browser for the marketing node we - should now see: - </para> - - <!-- figure: Marketing Services --> - <figure id="fig-marketing_services"> - <title>Marketing Services</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/marketing_services.png"/> - </imageobject> - <textobject> - <phrase>Marketing Services</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - Note that the subscriptionlistener is owned by the Marketing Node business (and - not the Root Marketing Node). The Marketing Node Business is managed by the - marketing publisher. - </para> - - </section> - - <!-- section: Deploy the HelloSales Service --> - <section id="sect-deploy_HelloSales_service"> - <title>Deploy the HelloSales Service</title> - <para> - The sales department developed a service called HelloSales. The HelloSales service - is provided in the <filename>juddiv3-samples.war</filename>, and it is annotated - so that it will auto-register. Before deploying the war, edit the - <filename>juddiv3-samples.war/WEB-INF/classes/META-INF/uddi.xml</filename> file to - set some property values to 'sales'. - </para> - - <programlisting language="XML"><xi:include href="extras/Subscription_3.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - Now deploy the <filename>juddiv3-samples.war</filename> to the sales registry - node, by building the <filename>juddiv3-samples.war</filename> and deploying. The - HelloWorld service should deploy - </para> - - <!-- figure: Registration by Annotation, deploying the juddi-samples.war to the sales Node --> - <figure id="fig-Registration_Annotation"> - <title>Registration by Annotation, deploying the <filename>juddi-samples.war</filename> to the sales Node</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/registration_by_annotation.png"/> - </imageobject> - <textobject> - <phrase></phrase> - </textobject> - </mediaobject> - </figure> - - <para> - On the Marketing UDDI we'd like to subscribe to the HelloWord service, in the - Sales UDDI Node. As mentioned before there are two ways to do this; synchronously - and asynchronously. - </para> - - </section> - - <!-- section: Configure a user to create Subscriptions --> - <section id="sect-config_user_create_subscription"> - <title>Configure a user to create Subscriptions</title> - <para> - For a user to create and save subscriptions the publisher needs to have a valid - login to both the sales and the marketing node. Also if the marketing publisher is - going to create registry objects in the marketing node, the marketing publisher - needs to own the sales keygenerator tModel. Check the - <filename>marketing_*.xml</filename> files in the root seed data of both the - marketing and sales node, if you want to learn more about this. It is important to - understand that the 'marketing' publisher in the marketing registry owns the - following tModels: - </para> - - <programlisting language="XML"><xi:include href="extras/Subscription_4.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - If we are going to user the marketing publisher to subscribe to updates in the - sales registry, then we need to provide this publisher with two clerks in the - <filename>uddi.xml</filename> of the <filename>uddi-portlet.war</filename>. - </para> - - <programlisting language="XML"><xi:include href="extras/Subscription_5.xmlt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"; /></programlisting> - - <para> - Here we created two clerks for this publisher called 'MarketingCratchit' and - 'SalesCratchit'. This will allow the publisher to check the existing subscriptions - owned by this publisher in each of the two systems. - </para> - - </section> - - <!-- section: Synchronous Notifications --> - <section id="sect-synchronous_notifications"> - <title>Synchronous Notifications</title> - <para> - While being logged in as the marketing publisher on the marketing portal, we - should see the following when selecting the UDDISubscription Portlet. - </para> - - <!-- figure: Subscriptions. In (a) both nodes are up while in (b) the sales node is down --> - <figure id="fig-Subscriptions_a_both_nodes_up_b_sales_node_is_down"> - <title>Subscriptions. In (a) both nodes are up while in (b) the sales node is down</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/a_bothup_b_sales_down.png"/> - </imageobject> - <textobject> - <phrase>Subscriptions. In (a) both nodes are up while in (b) the sales node is down</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - When both nodes came up green you can lick on the 'new subscription' icon in the - toolbar. Since we are going to use this subscription synchronously only the - Binding Key and Notification Interval should be left blank, as shown in - <xref linkend="fig-create_a_new_subscription" />. Click the save icon to save the - subscription. - </para> - - <!-- figure: Create a New Subscription --> - <figure id="fig-create_a_new_subscription"> - <title>Create a New Subscription</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/create_new_subscription.png"/> - </imageobject> - <textobject> - <phrase>Create a New Subscription</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - Make sure that the subscription Key uses the convention of the keyGenerator of the - marketing publisher. You should see the orange subscription icon appear under the - âsales-wsâ UDDI node. - </para> - - <!-- figure: A Newly Saved Subscription --> - <figure id="fig-newly_saved_subscription"> - <title>A Newly Saved Subscription</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/newly_saved_subscription.png"/> - </imageobject> - <textobject> - <phrase>A Newly Saved Subscription</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - To invoke a synchronous subscription, click the icon with the green arrows. This - will give you the opportunity to set the coverage period. - </para> - - <!-- figure: Set the Coverage Period --> - <figure id="fig-set_coverage_period"> - <title>Set the Coverage Period</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/set_coverage_period.png"/> - </imageobject> - <textobject> - <phrase>Set the Coverage Period</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - Click the green arrows icon again to invoke the synchronous subscription request. - The example finder request will go out to the sales node and look for updates on - the HelloWorld service. The raw XML response will be posted in the - UDDISubscriptionNotification Portlet. - </para> - - <!-- figure: The Raw XML response of the synchronous Subscription request --> - <figure id="fig-RawXML_response_of_the_synchronous_Subscription_request"> - <title>The Raw XML response of the synchronous Subscription request</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/raw_XML_response_synchronous_subscription_request.png"/> - </imageobject> - <textobject> - <phrase>The Raw XML response of the synchronous Subscription request</phrase> - </textobject> - </mediaobject> - </figure> - - - <para> - The response will also be consumed by the marketing node. The marketing node will - import the HelloWorld subscription information, as well as the sales business. So - after a successful sync you should now see three businesses in the Browser Portlet - of the marketing node, see <xref linkend="fig-registry_info_HelloWorld" />. - </para> - - <!-- figure: The registry info of the HelloWorld Service information was imported by the subscription mechanism. --> - <figure id="fig-registry_info_HelloWorld"> - <title>The registry info of the HelloWorld Service information was imported by the subscription mechanism.</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/registry_info_helloworld.png"/> - </imageobject> - <textobject> - <phrase>The registry info of the HelloWorld Service information was imported by the subscription mechanism.</phrase> - </textobject> - </mediaobject> - </figure> - - - </section> - - - -</chapter> http://git-wip-us.apache.org/repos/asf/juddi/blob/0833b028/docs/userguide/en-US/UDDI_Registry.xml ---------------------------------------------------------------------- diff --git a/docs/userguide/en-US/UDDI_Registry.xml b/docs/userguide/en-US/UDDI_Registry.xml deleted file mode 100644 index f87d313..0000000 --- a/docs/userguide/en-US/UDDI_Registry.xml +++ /dev/null @@ -1,194 +0,0 @@ -<?xml version='1.0'?> -<!-- - * Copyright 2001-2009 The Apache Software Foundation. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - */ --> - -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" -"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ -<!ENTITY % BOOK_ENTITIES SYSTEM "jUDDI_User_Guide.ent"> -%BOOK_ENTITIES; -]> - -<!-- chapter: UDDI Registry --> -<chapter id="chap-UDDI_Registry"> - <title>UDDI Registry</title> - - <!-- section: Introduction --> - <section id="sect-UDDI_Registry-intro"> - <title>Introduction</title> - <para> - The Universal Description, Discovery and Integration (UDDI) protocol is one of the - major building blocks required for successful Web services. UDDI creates a standard - interoperable platform that enables companies and applications to quickly, easily, and - dynamically find and use Web services over the Internet. UDDI also allows operational - registries to be maintained for different purposes in different contexts. UDDI is a - cross-industry effort driven by major platform and software providers, as well as - marketplace operators and e-business leaders within the OASIS standards consortium. - UDDI has gone through 3 revisions and the latest version is 3.0.2. Additional - information regarding UDDI can be found at <ulink url="http://uddi.xml.org"/>. - </para> - </section> - - <!-- section: UDDI Registry --> - <section id="sect-UDDI_Registry"> - <title>UDDI Registry</title> - <para> - The UDDI Registry implements the UDDI specification. UDDI is a Web-based distributed - directory that enables businesses to list themselves on the Internet and discover each - other, similar to a traditional phone book's yellow and white pages. The UDDI registry - is both a white pages business directory and a technical specifications library. The - Registry is designed to store information about Businesses and Services and it holds - references to detailed documentation. - </para> - - <!-- figure: Invocation Pattern using the UDDI Registry --> - <figure id="fig-UDDI_Registry_Invocation_Pattern"> - <title>Invocation Pattern using the UDDI Registry</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/UDDI_Registry_invocation_pattern.png" scalefit="1"/> - </imageobject> - <textobject> - <phrase>Invocation Pattern using the UDDI Registry</phrase> - </textobject> - </mediaobject> - </figure> - - <para> - A business publishes services to the UDDI registry. A client looks up the service in - the registry and receives service binding information. The client then uses the binding - information to invoke the service. The UDDI APIs are SOAP based for interoperability - reasons. The UDDI v3 specification defines 9 APIs: - </para> - - <orderedlist> - <listitem> - <para> - <classname>UDDI_Security_PortType</classname>, defines the API to obtain a - security token. With a valid security token a publisher can publish to the - registry. A security token can be used for the entire session. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_Publication_PortType</classname>, defines the API to publish - business and service information to the UDDI registry. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_Inquiry_PortType</classname>, defines the API to query the - UDDI registry. Typically this API does not require a security token. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_CustodyTransfer_PortType</classname>, this API can be used to - transfer the custody of a business from one UDDI node to another. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_Subscription_PortType</classname>, defines the API to - register for updates on a particular business of service. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_SubscriptionListener_PortType</classname>, defines the API a - client must implement to receive subscription notifications from a UDDI node. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_Replication_PortType</classname>, defines the API to replicate - registry data between UDDI nodes. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_ValueSetValidation_PortType</classname>, by nodes to allow - external providers of value set validation. Web services to assess whether - keyedReferences or keyedReferenceGroups are valid. - </para> - </listitem> - <listitem> - <para> - <classname>UDDI_ValueSetCaching_PortType</classname>, UDDI nodes may perform - validation of publisher references themselves using the cached values obtained - from such a Web service. - </para> - </listitem> - </orderedlist> - - - <!-- - <para> - Within jUDDI, there are three downloadable files (juddi-core.jar, juddi.war, and - juddi-tomcat.zip). You should determine which one to use depending on what level of - integration you want with your application and your platform / server choices. - </para> - - Using the JAR - - The juddi-core module produces a JAR which contains the jUDDI source and a jUDDI - persistence.xml configuration. jUDDI's persistence is being actively tested with both - OpenJPA and with Hibernate. - - If you are going to use only the JAR, you would need to directly insert objects into jUDDI - through the database backend or persistence layer, or configure your own Webservice - provider with the provided WSDL files and classes. - - Using the WAR files - - As with the JAR, you need to make a decision on what framework you would like to use when - building the WAR. There will eventually be two WAR files shipped â one using CXF and one - using Axis 2. For the alpha release, only CXF has been tested thoroughly. - - Simple copy the WAR to the deploy folder of your server (this release has been tested - under Apache Tomcat 5.5.23), start your server, and follow the directions under âusing - jUDDI as a Web Serviceâ. - - Using the Tomcat Bundle - - The jUDDI Tomcat bundle packages up the jUDDI WAR, Apache Derby, and a few necessary - configuration files and provides the user with a pre-configured jUDDI instance. By - default, the Hibernate is used as the persistence layer and CXF is used as a Web Serice - framework. - - To get started using the Tomcat bundle, unzip the juddi-tomcat-bundle.zip, and start - Tomcat : - - % cd apache-tomcat-5.5.23/bin % ./startup.sh - - Using jUDDI as Web Service - - Browse to http://localhost:8080/juddi/services - - The services page shows you the available endpoints and methods available. Using any SOAP - client, you should be able to send some sample requests to jUDDI to test: - - Using jUDDI with your application - - As of the Alpha release, two of the UDDI v3 APIs should be active within jUDDI : inquiry - and publish. - --> - </section> - - - - -</chapter> --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@juddi.apache.org For additional commands, e-mail: commits-h...@juddi.apache.org
