How to Build J2EE Applications Using Novell Technologies: Part 9
Articles and Tips: article
Chief Architect
Zareus, Inc.
jeff@jeffhanson.com
01 Jul 2003
This is the ninth in a series that outlines a platform and methodology for Java 2 Platform Enterprise Edition (J2EE) application development on NetWare using a service-oriented architecture. In this AppNote, we introduce technologies that enable us to publish and find Web services using technologies on the NetWare platform.
Topics |
Java application development, J2EE, UDDI, registries, Web services |
Products |
Java 2 Enterprise Edition |
Audience |
developers |
Level |
intermediate |
Prerequisite Skills |
familiarity with Java programming |
Operating System |
n/a |
Tools |
none |
Sample Code |
yes |
Introduction
This is the ninth in a series of AppNotes outlining a platform and methodology for Java 2 Platform Enterprise Edition (J2EE) application development on NetWare using a service-oriented architecture.
In the previous AppNote, we extended our exploration of AXIS and Web services to show how to use AXIS to handle SOAP messages as an integral component of our platform.
In this AppNote, we introduce technologies that enable us to publish and find Web services using technologies on the NetWare platform.
Web Services Publishing and Discovery
In order for a Web service to be used by a consumer, it must first be found by the consumer. This implies that information about the service must exist in a location that can be accessed by the consumer. Web service registries were created for this purpose.
A Web service is typically listed or "published" to a public or private registry in order that it can be found or "discovered" by a consumer of the service. Once the consumer has found the service, the service can be bound to a particular protocol and then invoked by the consumer.Figure 1 illustrates how a service registry relates with service providers and service consumers in the lifecycle of a typical Web service.
Figure 1: The relationship of the registry to other components in a typical Web service lifecycle.
Web service registries act as databases or repositories of information about businesses and the services that they offer. Companies use public registries to publish information that is intended to be shared with potential or current business clients and partners. Once a company has stored its information in a registry, clients and Web service consumers can query the registry to retrieve the information in order to make decisions about how best they can interact with the company.
The two most often referenced registry standards are the Electronic Business XML (ebXML) registry and the Universal Description, Discovery, and Integration (UDDI) registry. While both registries are similar in that they expose information about a company in a global fashion, they differ in the kind of information they expose.
Overview of ebXML Registries
The ebXML Registry specification was created by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) as a means for companies to conduct business over the Internet. ebXML strives to define standards that enable businesses to communicate and to transfer XML data and messages securely over the Internet.
ebXML Technical Architecture
An ebXML registry is a repository of information that can be used to store information about a company's business processes in order that consumers and clients of the company can conduct electronic business with the company. The responsibility of an ebXML registry as it relates to other ebXML technologies is illustrated in Figure 2.
Figure 2: Conceptual architecture of an ebXML registry.
As shown in this diagram, an ebXML registry can interact with a local repository and remote registries, such as UDDI.
An ebXML registry strives to manage business collaboration using Collaboration Protocol Profiles (CPP), Collaboration Protocol Agreements (CPAs), and Business Process Specification Schemas (BPSS).
Overview of UDDI Registries
UDDI is a specification which defines how service providers can publish and discover information about their Web services using XML-based messages and data. A UDDI Registry implements the UDDI XML schema information model. The information stored in a UDDI registry consists of Business Entities, Business Services, Binding Information, and Compliance Information.
A UDDI registry is often referred to in terms of a type of telephone directory where "white pages" are represented by business address, contacts, and so on, "yellow pages" are represented by categorizations and taxonomies, and "green pages" are represented by technical information about each Web services.
Interacting with UDDI Registries
Service providers and consumers in a typical UDDI scenario, interact as illustrated in Figure 3.
Figure 3: Typical UDDI interactions.
In this scenario, a service provider implements a service and then deploys it to a SOAP server. At this point, some form of service description, such as a WSDL document, is published to a private registry. Once services have been published to a private registry, they can then be propagated or synchronized automatically or manually to public registries as needed.
Once published, services can be discovered and used by interested service consumers. The service consumer queries the private or public registry, retrieves the service description document, and binds to the service using the chosen protocol and communications infrastructure.
Publishing and Discovery with UDDI4J
UDDI4J is an open-industry initiative in the form of a Java class library, co-developed by engineers from HP and IBM, to interact with UDDI registries. UDDI4J provides full support for the UDDI version 2 specification, as well as support for multiple SOAP (Simple Object Access Protocol) transports. UDDI4J is based on code released earlier by IBM for UDDI version 1.0. It exposes a complete client-side API for connecting and using a UDDI registry. It also includes the source code, JavaDoc, and sample applications.
The UDDIProxy Class
The UDDIProxy class is the primary component used to connect and interact with UDDI registries. It provides all of the methods needed to connect to a UDDI registry, execute a query, and process the results.
Let's take a look at how to use the UDDIProxy class to connect to a UDDI registry, publish to the registry, discover its businesses and services, and so on.
Here is an example of how to create the UDDI Registry Proxy:
UDDIProxy proxy = new UDDIProxy(); proxy.setInquiryURL("http://www.jeffhanson.com/registries/test/inquire"); proxy.setPublishURL("https://www.jeffhanson.com/registries/test/publish");
Here is an example of discovering business listings:
BusinessList bl = proxy.find_business("C", null, 0); Vector businessInfos = bl.getBusinessInfos().getBusinessInfoVector(); Iterator iter = businessInfos.iterator(); while (iter.hasNext()) { BusinessInfo businessInfo = (BusinessInfo)iter.next(); System.out.println(businessInfo.getNameString()); }
Here is an example of publishing business listings:
usinessEntity busEntity = new BusinessEntity(""); busEntity.setName("My business"); Vector busEntities = new Vector(); busEntities.addElement(busEntity); AuthToken authToken = proxy.get_authToken("jdoe", "foobar"); BusinessDetail busDetail = proxy.save_business(authToken.getAuthInfoString(), busEntities);
Here is an example of removing business listings:
usinessList busList = proxy.find_business("My business", null, 0); AuthToken authToken = proxy.get_authToken("jdoe", "foobar"); Vector businessInfos = busList.getBusinessInfos().getBusinessInfoVector(); Iterator iter = businessInfos.iterator(); while (iter.hasNext()) { BusinessInfo businessInfo = (BusinessInfo)iter.next(); DispositionReport dispReport = proxy.delete_business(authToken.getAuthInfoString(), businessInfo.getBusinessKey()); if (dispReport.success() == true) { System.out.println("Business listing successfully deleted"); } else { System.out.println("Business listing unsuccessfully deleted"); } }
Publishing and Discovery with Novell Technologies
Novell's leading edge UDDI Classes for Java allow applications to be integrated with UDDI registries. They provide mechanisms to contact UDDI registries and enable inquiry and publishing from/to UDDI registries along with features such as authenticated inquiry. The classes are based on Version 2.04 of the UDDI API specification (http://www.uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf).
The dependencies of the UDDI Classes for Java are:
Java Virtual Machine (JVM) v1.4 for NetWare (http://developer.novell.com/ndk/jvm14.htm)
JavaBeans Activation Framework (JAF) - activation.jar (http://java.sun.com/products/javabeans/glasgow/jaf.html)
A JAXP (Java API for XML Processing)-compatible, namespace-aware XML parser (such as xerces.jar, available at http://xml.apache.org/xerces-j)
JavaMail API - mail.jar (http://java.sun.com/products/javamail)
SOAP - soap.jar (http://xml.apache.org/dist/soap)
JDOM - jdom.jar (http://www.jdom.org/dist/binary)
Conclusion
This AppNote introduced technologies that enable us to publish and find Web services using technologies on the NetWare platform.
In the next AppNote in this series, we will investigate Novell technologies that allow us to create and host UDDI Servers on the NetWare platform.
For Additional Information
For more information about the technologies discussed in this AppNote, refer to the following resources:
For more information about SOAP, visit http://www.w3.org/TR/SOAP.
For a discussion about UDDI and NetWare, visit news://developer-forums.novell.com/novell.devsup.uddi.
For more information about UDDI, visit http://www.uddi.org.
For more information about UDDI4J, visit http://oss.software.ibm.com/developerworks/projects/uddi4j.
For Novell-specific Java programming information, see http://developer.novell.com/ndk.
For information about Zareus and its products for building enterprise applications for J2EE, Web services, and X-Internet environments, visit http://www.zareus.com.
Previous AppNotes in This Series
The previous AppNotes in this series are available online at the URLs indicated:
Part 1: http://support.novell.com/techcenter/articles/ana20020505.html.
Part 2: http://support.novell.com/techcenter/articles/ana20020606.html.
Part 3: http://support.novell.com/techcenter/articles/dnd20020703.html.
Part 4: http://support.novell.com/techcenter/articles/dnd20020805.html.
Part 5: http://support.novell.com/techcenter/articles/dnd20020906.html.
Part 6: http://support.novell.com/techcenter/articles/dnd20021105.html.
Part 7: http://support.novell.com/techcenter/articles/dnd20021206.html.
Part 8: http://support.novell.com/techcenter/articles/dnd20030303.html.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.