Getting Started with UDDI v3

Nowadays it is very easy to get started with a UDDI v3 registry. Here are the steps to get started with jUDDI v3.

1. From the jUDDI releases page, download the latest jUDDI v3 tomcat-bundle, or if you want an additional browser then you can download the portal-bundle.

2. Unzip the bundle and start the server by running the bin/start.sh (use the start.bat on windows).

3. Since the UDDI v3 API is a WebServices API you can interact with it using tools like SoapUI. Visit http://www.soapui.org/ to download SoapUI. Unzip the SoapUI.zip and start it using /bin/soapui.sh.

4. Open your browser to http://localhost:8080/juddiv3, and save the wsdls for the security, publish and inquiry API.

5. Import these WSDLs into a SoapUI project, and you are now ready to use the API. See also the demo to publish and delete a business.

The demo is broken down into 2 parts, please scroll down for part 2 of the demo.

WSDL to UDDI Mapping

I was just working on added the standard WSDL and BPEL to UDDI mappings to the the juddi-client, when I came across this article. Nice post Kasun.

Kasun's Blog: WSDL to UDDI Mapping: "Introduction Universal Description, Discovery and Integration (UDDI) is a platform independent, Extensible Markup Language (XML) based..."

--Kurt

How to register Java RMI services into jUDDI

The UDDI v3 specification speaks about 5 UDDI transport tModels to define the type of protocol a binding of a service is using.

11.3.3 UDDI HTTP Transport
11.3.4 UDDI SMTP Transport
11.3.5 UDDI FTP Transport
11.3.6 UDDI Fax Transport
11.3.7 UDDI Telephone Transport

The jUDDI project is adding out-of-the-box support for RMI. For an application written in Java we think it makes sense to support Java specific transports and starting at with the jUDDI-3.1 release we will support two more Transports: rmi and jndi-rmi, where the jndi-rmi transport is a special version of the rmi transport (We'll come back to that later).

Introduction

In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. Transport tModels are referenced by service bindings to describe the type of transport used to invoke the service, either when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) do not specify the transport used by the particular service binding, or when the service provider wants to explicitly call out the transport in the technical fingerprint so as to enable discovery. Transport tModels are frequently coupled with other tModels that describe more completely what the service does. For example, the RMI Transport tModel may be coupled with the SOAP Protocol tModel to indicate that a Web service communicates using SOAP over RMI. The RMI Transport tModel provides a means for designating that services transport messages using the RMI protocol.

Design Goals

The RMI Transport tModel is provided to enable discovery of services that transport messages using the RMI protocol. This tModel can be used alone to provide a technical fingerprint for simple services that are accessed through HTTP when they might otherwise not have a tModel to reference in their bindingTemplates, or it can be used in conjunction with other protocol tModels to indicate the applicable transport when other parts of the technical fingerprint are ambiguous or silent with respect to the transport to use.

UDDI RMI Transport tModel Definition

Name: uddi-org:rmi
Description: A Java service that uses RMI transport
UDDI Key (V3): uddi:uddi.org:transport:rmi
Evolved V1,V2 format key: N/A
Categorization: transport
UDDI RMI Transport

UDDI RMI Transport tModel Structure

<tModel
 tModelKey="uddi:uddi.org:transport:http">
  <name>uddi-org:rmi</name>
  <description>Java RMI based service registered to the Java Registry</description>
  <overviewDoc>
    <overviewURL useType="text">
      http://juddi.apache.org/docs/3.0/userguide/html/chap-root_seed_data.html#sect-rmi
    </overviewURL> 
  </overviewDoc> 
  <categoryBag>
    <keyedReference keyName="uddi-org:types:transport"
      keyValue="transport" 
      tModelKey="uddi:uddi.org:categorization:types"/> 
   </categoryBag>
</tModel>

UDDI RMI Transport Example of use
The following is a typical bindingTemplate for a simple service that references the RMI Transport tModel:

<bindingTemplate bindingKey="uddi:...." serviceKey="uddi:...."> 
  <description xml:lang="en">Buy from Bigfoot Breweries over
    the Web</description>
  <accessPoint useType="endpoint"
    rmi://hostname:1099/shopService
  </accessPoint>
  <tModelInstanceDetails>
    <tModelInstanceInfo 
      tModelKey="uddi:uddi.org:transport:rmi />
  </tModelInstanceDetails>
</bindingTemplate>

UDDI JNDI-RMI Transport tModel Definition

Name: uddi-org:jndi-rmi
Description: A Java service that uses JNDI-RMI transport
UDDI Key (V3): uddi:uddi.org:transport:jndi-rmi
Evolved V1,V2 format key: N/A
Categorization: transport
UDDI RMI Transport

UDDI JNDI-RMI Transport tModel Structure

<tModel
 tModelKey="uddi:uddi.org:transport:jndi-rmi">
  <name>uddi-org:jndi-rmi</name>
  <description> A Java RMI based service registered to a JNDI Registry </description>
  <overviewDoc>
    <overviewURL useType="text">
      http://juddi.apache.org/docs/3.0/userguide/html/chap-root_seed_data.html#sect-jndi-rmi
    </overviewURL> 
  </overviewDoc> 
  <categoryBag>
    <keyedReference keyName="uddi-org:types:transport"
      keyValue="transport" 
      tModelKey="uddi:uddi.org:categorization:types"/> 
   </categoryBag>
</tModel>

UDDI JNDI-RMI Transport Example of use
The following is a typical bindingTemplate for a simple service that references the JNDI-RMI Transport tModel. Optionally an InitialContext can be provided in the instanceParms, which should be used by the client at runtime to lookup the service as registered in that JNDI (somecontext/shopService) in this case:

<bindingTemplate bindingKey="uddi:...." serviceKey="uddi:...."> 
  <description xml:lang="en">Buy from Bigfoot Breweries over
    the Web</description>
  <accessPoint useType="endpoint"
    jndi-rmi://somecontext/shopService
  </accessPoint>
  <tModelInstanceDetails>
    <tModelInstanceInfo 
      tModelKey="uddi:uddi.org:transport:jndi-rmi />
     <instanceParms>
        <![CDATA[
        <?xml version="1.0" encoding="utf-8" ?>
        <initialContextInfo>
            <contextProperty name="java.naming.factory.initial" 
                value="org.jnp.interfaces.NamingContextFactory"/>
            <contextProperty name="java.naming.provider.url" 
                value="jnp://localhost:1099"/>
            <contextProperty name="java.naming.factory.url.pkgs" 
                value="org.jboss.naming:org.jnp.interfaces"/>
        </initialContextInfo>
        ]]>
  </tModelInstanceDetails>
</bindingTemplate>

Other UDDI registries will also be able to store RMI based services, as long as you add the
'uddi:uddi.org:transport:rmi' and 'uddi:uddi.org:transport:jndi-rmi' tModels.

Cheers,
--Kurt

RiftSaw integrates jUDDI for auto-registration of BPEL processes.

Recently I worked on RiftSaw. RiftSaw is the Apache ODE BPEL engine deployed to JBoss. The deployment code in RiftSaw allows BPEL processes to be deployed to the appserver in jar archives. When the BPEL process is deployed both the Service and its BindingTemplate (EndPoint information) are registered, and a partnerLinkChannel is created for each partnerLink. UDDI lookup will obtain the WSDL Endpoint from the UDDI and access this URL to obtain the WSDL straight from the Service. Upon undeployment the BindingTemplate is removed from the UDDI Registry. The Service is removed with the removal of the last BindingTemplate. For more information see the RiftSaw User Guide. This functionality allows for dynamic endpoint discovery of BPEL Services.

Most of the functionality developed for RiftSaw integration is part of the jUDDI client code. If you are interested check out the functionality of the UDDIClerk. Note that the same UDDIClerk is used by the UDDI Annotations.

Cheers,

--Kurt

jUDDI TLP has new website location

Now that jUDDI has become a Top Level Project, our coordinates are changing. Most noticeably our site is now found at juddi.apache.org and Scout is found at juddi.apache.org/scout/. Our mailing lists have been migrated (along with the existing users and archives). We now have user@juddi.apache.org and dev@juddi.apache.org, for both jUDDI and Scout. Please update your bookmarks.

Cheers,

--Kurt

Short introduction to the jUDDI QA Process

We've recorded a short presentation about the jUDDI QA Process. We believe that there are three levels of testing:

Unit tests

• Functionality
  
• Regression of components

Integration tests

• System level functionality
• Regression across components

QA tests

• Long running and repetitive, simulating real user load (memory leaks, performance)

For the QA tests we use XLT, and it it's simplest form the XLT agent and reporting engine are run on the same machine as the jUDDI server. However at true performance load testing multiple agents are deployed on dedicated machines.


Deployment Architecture showing how XLT is hooked up to load jUDDI.



The slides of the presentation can be download here.

Hurray! jUDDI is now a TLP project!

I hope your summer has been good. Not too much coding went on but instead the big news is that recently a vote passed to make jUDDI a Top Level Project (TLP). The ASF Board approved that both jUDDI and Scout will be combined into one project called "jUDDI". This is quite exciting and it is another major step for the project. It does mean that we will go through a bit of a reorganization though to move from subproject of Apache WS to the new TLP status. Stay tuned!

Cheers,

--Kurt