EJB 3.1: Web Services Standards (Enterprise JavaBeans 3.1)

Web services have taken the enterprise computing industry by storm in the past couple of years, and for good reason. They present the opportunity for real interoperability across hardware, operating systems, programming languages, and applications. Based on the XML, SOAP, and WSDL standards, web services have enjoyed widespread adoption by nearly all of the major enterprise players, including Microsoft, IBM, BEA, JBoss, Oracle, Hewlett-Packard, and others. Sun Microsystems has integrated web services into the Java EE platform; specifically, Sun and the Java Community Process have introduced several web services APIs, including the Java API for XML Web Services (JAX-WS), the Java API for XML-based RPC (JAX-RPC), the SOAP with Attachments API for Java (SAAJ), and the Java API for XML Registries (JAXR). These web services APIs were integrated into J2EE 1.4 and have been expanded upon in subsequent releases, including Java EE 6 and EJB 3.1.

This topic provides an overview of the technologies that are the foundation of web services: XML Schema and XML Namespaces, SOAP, and WSDL.

Web Services Overview

The term web services means different things to different people, but thankfully, the definition is straightforward for EJB developers because the Java EE platform has adopted a rather narrow view of them. Specifically, a web service is a remote application described using the Web Service Description Language (WSDL) and accessed using the Simple Object Access Protocol (SOAP) according to the rules defined by the WS-I Basic Profile 1.1. The WS-I (Web Services Integration Organization) is a group of vendors (Microsoft, IBM, BEA, Sun Microsystems, Oracle, HP, and others) that have banded together to ensure web services are interoperable across all platforms. To do this, they have created a recommendation called the Basic Profile 1.1, which defines a set of rules for using XML, SOAP, and WSDL together to create interoperable web services.

In order to understand SOAP and WSDL, you must understand XML Schema and XML Namespaces. The rest of this topic conducts a whirlwind tour of XML, SOAP, and WSDL. Although it’s not the purpose of this topic to cover these subjects in depth, you should be able to understand the basics.

XML Schema and XML Namespaces

We’ll start with the basics of XML Schema and XML Namespaces. It’s assumed that you already understand how to use basic XML elements and attributes. If you don’t, you should probably read a primer on XML before proceeding. We recommend the topic Learning XML . If you already understand how XML Schema and XML Namespaces work, skip ahead to the section on SOAP.

XML Schema

An XML Schema is similar in purpose to a Document Type Definition (DTD), which validates the structure of an XML document. To illustrate some of the basic concepts of XML Schema, let’s start with an XML document with address information:

In order to ensure that the XML document contains the proper type of elements and data, the address information must be evaluated for correctness. You measure the correctness of an XML document by determining two criteria: whether the document is well formed and whether it is valid. To be well formed, an XML document must obey the syntactic rules of the XML markup language: it must use proper attribute declarations, the correct characters to denote the start and end of elements, and so on. Most XML parsers based on standards such as SAX and DOM automatically detect documents that aren’t well formed.

In addition to being well formed, the document must use the right types of elements and attributes in the correct order and structure. A document that meets these criteria is called valid. However, the criteria for validity have nothing to do with XML itself; they have more to do with the application in which the document is used. For example, the Address document would not be valid if it didn’t include the zip code or state elements. In order to validate an XML document, you need a way to represent these application-specific constraints.

The XML Schema for the Address XML document looks like this:

The first thing to focus on in this XML Schema is the <complexType> element, which declares a type of element in much the same way that a Java class declares a type of object. The <complexType> element explicitly declares the names, types, and order of elements that an AddressType element may contain. In this case, it may contain four elements of type string, in the following order: street, city, state, and zip. Validation is pretty strict, so any XML document that claims conformity to this XML Schema must contain exactly the right elements with the right data types, in the correct order.

XML Schema automatically supports about two dozen simple data types, called built-in types. Built-in types are a part of the XML Schema language and are automatically supported by any XML Schema-compliant parser. Table 20-1 provides a short list of some of the built-in types. It also includes Java types that correspond to each built-in type. (Table 20-1 presents only a subset of all the XML Schema [XSD] built-in types, but it’s more than enough for this topic.)

By default, each element declared by a <complexType> must occur once in an XML document, but you can specify that an element is optional or that it must occur more than once by using the occurrence attributes. For example, we can say that the street element must occur once but may occur twice:

By default, the maxOccurs and minOccurs attributes are always 1, indicating that the element must occur exactly once. Setting maxOccurs to 2 allows an XML document to have either two street elements or just one. You can also set maxOccurs to unbounded, which means the element may occur as many times as needed. Setting minOccurs to 0 means the element is optional and can be omitted.

The <element> declarations are nested under a <sequence> element, which indicates that the elements must occur in the order they are declared. You can also nest the elements under an <all> declaration, which allows the elements to appear in any order. The following shows the AddressType declared with an <all> element rather than a <sequence> element:

In addition to declaring elements of XSD built-in types, you can declare elements based on complex types. This is similar to how Java class types declare fields that are other Java class types. For example, we can define a CustomerType that uses the AddressType:

This XSD tells us that an element of CustomerType must contain a <last-name> and <first-name> element of the built-in type string, and an element of type AddressType. This is straightforward, except for the titan: prefix on AddressType. That prefix identifies the XML Namespace of the AddressType; we’ll discuss namespaces later in the topic. For now, just think of it as declaring that the AddressType is a custom type defined by Titan Cruises. It’s not a standard XSD built-in type. An XML document that conforms to the Customer XSD would look like this:

Building on what you’ve learned so far, we can create a Reservation schema using the CustomerType, the AddressType, and a new CreditCardType:

An XML document that conforms to the Reservation XSD would include information describing the customer (name and address), credit card information, and the identity of the cruise and cabin that are being reserved. This document might be sent to Titan Cruises from a travel agency that cannot access the TravelAgent EJB to make reservations. Here’s an XML document that conforms to the Reservation XSD:

At runtime, the XML parser compares the document to its schema, ensuring that the document conforms to the schema’s rules. If the document doesn’t adhere to the schema, it is considered invalid, and the parser produces error messages. An XML

Schema checks that XML documents received by your system are properly structured, so you won’t encounter errors while parsing the documents and extracting the data. For example, if someone sent your application a Reservation document that omitted the credit card element, the XML parser could reject the document as invalid before your code even sees it; you don’t have to worry about errors in your code caused by missing information in the document.

This brief overview represents only the tip of the iceberg. XML Schema is a very rich XML typing system and can be given sufficient attention only in a text dedicated to the subject. For in-depth and insightful coverage of XML Schema, read XML Schema: The W3C’s Object-Oriented Descriptions for XML,or read the XML Schema specification, starting with the primer at the World Wide Web Consortium (W3C) website (http://www.w3.org/TR/xmlschema-0).

XML Namespaces

The Reservation schema defines an XML markup language that describes the structure of a specific kind of XML document. Just as a class is a type of Java object, an XML markup language is a type of XML document defined by an XML Schema. In some cases, it’s convenient to combine two or more XML markup languages into a single document so that the elements from each markup language can be validated separately using different XML Schema. This is especially useful when you want to reuse a markup language in many different contexts. For example, the AddressType defined in the previous section is useful in a variety of contexts, not just the Reservation XSD, so it could be defined as a separate markup language in its own XML Schema:

To use different markup languages in the same XML document, you must clearly identify the markup language to which each element belongs. The following example is an XML document for a reservation, but this time we are using XML Namespaces to separate the address information from the reservation information:

All of the elements for the address information are prefixed with the characters addr:, and all the reservation elements are prefixed with res:. These prefixes allow parsers to identify and separate the elements that belong to the Address markup from those that belong to the Reservation markup. As a result, the address elements can be validated against the Address XSD, and the reservation elements can be validated against the Reservation XSD. The prefixes are assigned using XML Namespace declarations, which are shown in bold in the previous listing. An XML Namespace declaration follows this format:

The prefix can be anything you like, as long as it does not include blank spaces or any special characters. We use prefixes that are abbreviations for the name of the markup language: res stands for Reservation XSD, and addr stands for Address XSD. Most XML documents follow this convention, but it’s not a requirement; you could use a prefix like foo or bar or anything else you fancy.

While the prefix can be any arbitrary token, the Universal Resource Identifier (URI) must be very specific. A URI is an identifier that is a superset of the Universal Resource Locator (URL), which you use every day to look up web pages. In most cases, people use the stricter URL format for XML Namespaces because URLs are familiar and easy to understand. The URI used in the XML Namespace declaration identifies the exact markup language that is employed. It doesn’t have to point at a web page or an XML document; it only needs to be unique to that markup language. For example, the XML Namespace used by the Address markup is different from the URL used for the Reservation markup:

The URI in the XML Namespace declaration should match the target namespace declared by the XML Schema. The following example shows the Address XSD with the target namespace declaration in bold. The URL value of the targetNamespace attribute is identical to the URL assigned to the add: prefix in the Reservation document:

The targetNamespace attribute identifies the unique URI of the markup language; it is the permanent identifier for that XML Schema. Whenever elements from the Address XSD are used in some other document, the document must use an XML Namespace declaration to identify those elements as belonging to the Address markup language.

Prefixing every element in an XML document with its namespace identifier is a bit tedious, so the XML Namespace allows you to declare a default namespace that applies to all nonprefixed elements. The default namespace is simply an XML Namespace declaration that has no prefix (xmlns=”URL.”). For example, we can use a default name in the Reservation document for all reservation elements:

None of the reservation element names are prefixed. Any nonprefixed element belongs to the default namespace. The address elements do not belong to the http://www.titan.com/Reservationnamespace, so they are prefixed to indicate to which namespace they belong. The default namespace declaration has scope; in other words, it applies to the element in which it is declared (if that element has no namespace prefix), and to all nonprefixed elements nested under that element. We can apply the scoping rules of namespace to simplify the Reservation document further by allowing the address elements to override the default namespace with their own default namespace:

The Reservation default namespace applies to the <reservation> element and all of its children, except for the address elements. The <address> element and its children have defined their own default namespace, which overrides the default namespace of the <reservation> element.

Default namespaces do not apply to attributes. As a result, any attributes used in an XML document should be prefixed with a namespace identifier. The only exceptions to this rule are attributes defined by the XML language itself, such as the xmlns attribute, which establishes an XML Namespace declaration. This attribute doesn’t need to be prefixed, because it is part of the XML language.

XML Namespaces are URIs that uniquely identify a namespace but do not actually point at a resource. In other words, you don’t normally use the URI of an XML Namespace to look something up. It’s usually only an identifier. However, you might want to indicate the location of the XML Schema associated with an XML Namespace so that a parser can upload it and use it in validation. This is accomplished using the schemaLocation attribute:

The schemaLocation attribute provides a list of values as Namespace-Location value pairs. The first value is the URI of the XML Namespace; the second is the physical location (URL) of the XML Schema. The following schemaLocation attribute states that all elements belonging to the Reservation namespace (http://www.titan.com/Reservation) can be validated against an XML Schema located at the URL http:// www.titan.com/schemas/reservation.xsd:

The schemaLocation attribute is not a part of the XML language, so we’ll actually need to prefix it with the appropriate namespace in order to use it. The XML Schema specification defines a special namespace that can be used for schemaLocation (as well as other attributes). That namespace is http://www.w3.org/2001/XMLSchema-Instance. To declare the schemaLocation attribute properly, you must declare its XML Namespace and prefix it with the identifier for that namespace, as shown in the following snippet:

A namespace declaration needs to be defined only once; it applies to all elements nested under the element in which it’s declared. The convention is to use the prefix xsi for the XML Schema Instance namespace (http://www.w3.org/2001/XMLSchema-Instance).

XML Schema also use XML Namespaces. Let’s look at the XML Schema for the Address markup language with a new focus on the use of XML Namespaces:

In this file, namespaces are used in three separate declarations. The first declaration states that the default namespace is http://www.w3.org/2001/XMLSchema, which is the namespace of the XML Schema specification. This declaration makes it easier to read the XSD because most of the elements do not need to be prefixed. The second declaration states that the target namespace of the XML Schema is the namespace of the Address markup. This tells us that all the types and elements defined in this XSD belong to that namespace. Finally, the third namespace declaration assigns the prefix addr to the target namespace so that types can be referenced exactly. For example, the top-level <element> definition uses the name addr:AddressType to state that the element is of type AddressType, belonging to the namespace http://www.titan.com/Address.

Why do you have to declare a prefix for the target namespace? The reason is clearer when you examine the Reservation XSD:

The Reservation XSD imports the Address XSD so that the AddressType can be used to define the CustomerType. You can see the use of namespaces in the definition of CustomerType, which references types from both the Address and Reservation namespaces (prefixed by addr and res, respectively):

Assigning a prefix to the Reservation namespace allows us to distinguish between elements that are defined as Reservation types (e.g., credit-card) and elements that are defined as Address types (e.g., address). All the type attributes that reference the built-in string and int types also belong to the XML Schema namespace, so we don’t need to prefix them. We could, though, for clarity. That is, we’d replace string and int with xsd:string and xsd:int. The prefix xsd references the XML Schema namespace; it allows us to identify built-in types defined as XML Schema more clearly. It’s not a problem that the default namespace is the same as the namespace prefixed by xsd. By convention, the xsd prefix is the one used in most XML Schema.

SOAP 1.1

SOAP 1.1 is simply a distributed object protocol, similar to DCOM, CORBA’s IIOP, and JRMP (the primary transport used by RMI). The most significant difference between SOAP 1.1 and other distributed object protocols is that SOAP 1.1 is based on XML.

SOAP is defined by its own XML Schema and relies heavily on the use of XML Namespaces. Every SOAP message that is sent across the wire is an XML document consisting of standard SOAP elements and application data. The use of namespaces differentiates the standard SOAP elements from the application data. Here’s a SOAP request message that might be sent from a client to a server:

The standard SOAP elements are shown in bold, and the application data, or the Reservation XML document fragment, is shown in regular text. SOAP’s primary purpose is to establish a standard XML framework for packaging application data that is exchanged between different software platforms, such as Java and Perl, or Java and .NET. To do this, SOAP defines a set of elements, each designed to carry different data. The <Envelope> element is the root of the SOAP message; all other elements are contained by it. Within the <Envelope> element are two direct children: the <Header> element and the <Body> element.

The <Header> element is generally used for carrying infrastructure data such as security tokens, transaction IDs, routing information, and so on. In the previous example, the <Header> element is empty, which is not unusual for basic web services. In many cases, we are only interested in exchanging information and not in more advanced issues, such as those relating to security and transactions. Although the <Body> element is required, the <Header> element is not. From this point forward, the <Header> element will be omitted from examples.

The <Body> element carries the application information that is being exchanged. In the previous example, the <Body> element contains a <reservation> element, which is the application data. It’s an XML document fragment based on the Reservation XSD developed earlier in this topic. It’s called a “fragment” because it’s embedded inside a SOAP message instead of standing alone.

Web Services Styles

The SOAP message in the previous example is a Document/Literal message, which means that the message body is a single XML Schema instance document, and thus the full message can be validated. For this reason, Document/Literal is becoming the preferred message style of the web services community.

The schemaLocation attribute could have been included, but it’s omitted because we assume that the receiver is already familiar with the schema used for that type of SOAP message.

The other style allowed by the WS-I Basic Profile 1.1 and supported by EJB 3.1 is RPC/ Literal. RPC/Literal represents SOAP messages as RPC calls with parameters and return values, each with its own schema type. The following Java interface defines a single method called makeReservation():

The makeReservation() method can be modeled as a SOAP message using the RPC/ Literal messaging style:

The first element within the <Body> identifies the web services operation being invoked. In this case, it is the makeReservation operation. Directly beneath the <titan:makeReservation> element are the parameters of the RPC call, each represented by an element with a value.

EJB 3.1, but not the WS-I Basic Profile 1.1, supports the RPC/Encoded mode of SOAP messaging. Most SOAP applications used RPC/Encoded when web services were first created. However, the web services industry has moved toward Document/Literal and

RPC/Literal, primarily because interoperability between platforms using RPC/Encoded proved to be less than perfect and sometimes downright difficult. Whereas RPC/ Encoded SOAP messages rely on SOAP-defined types for arrays, enumeration, unions, lists, and the like, RPC/Literal and Document/Literal depend only on XML Schema for their data types, which seems to provide a better system for interoperability across programming languages. Although EJB 3.1 supports RPC/Encoded messaging, it’s not a very good option to use in web services. RPC/Encoded messaging is not addressed in this topic.

Exchanging SOAP Messages with HTTP

SOAP messages are network-protocol agnostic, which means that a SOAP message is not aware of or dependent on the type of network or protocol used to carry it. With that said, SOAP is primarily exchanged using HTTP. The reason for using HTTP is simple. Most Internet products, including web servers, application servers, and wireless devices, are designed to handle the HTTP protocol. This widespread support provides an instant infrastructure for SOAP messaging. The fact that SOAP can leverage the ubiquity of HTTP is one of the reasons it has become so popular so quickly.

Another advantage of using HTTP is that SOAP messages can slip through firewalls without any hassles. If you have ever tried to support internal or external customers who are separated from you by a firewall (yours or theirs), you know the headaches it can create. Unless you have direct control over the firewall, your chances of communicating with arbitrary clients using anything but HTTP or SMTP (email) are slim to none. However, because SOAP can be transmitted with HTTP, it slips through the firewall unnoticed. This ability makes life a lot simpler for the application developer, but it’s a point of contention with the security folks. Understandably, they’re a bit irked by the idea of application developers circumventing their defenses. Using HTTP to carry an application protocol such as SOAP is commonly called HTTP tunneling. In the past, support for tunneling by vendors of other distributed object protocols (CORBA IIOP, DCOM, and so on) was sporadic and proprietary, making interoperability extremely difficult. However, tunneling over HTTP is built into the SOAP 1.1 specification, which means interoperability is no longer a problem. Because almost every application server vendor rapidly adopts SOAP, SOAP-HTTP tunneling is becoming ubiquitous.

You can use SOAP 1.2 with other protocols, such as SMTP, FTP, and even raw TCP/ IP, but HTTP is the only protocol for which a binding is currently specified. As a result, EJB 3.1 and Java EE 6 require support for SOAP 1.1 over HTTP 1.1, but not other protocols.

Now You See It, Now You Don’t

All this talk about SOAP is intended to give you a better idea of what is going on under the hood, but in practice, you are unlikely to interact with the protocol directly. As with most protocols, SOAP is designed to be produced and consumed by software and is usually encapsulated by a developer API. In EJB 3.1, the API you use to exchange SOAP messages is the Java API for XML-based Web Services (JAX-WS), which hides the details of SOAP messaging so that you can focus on developing and invoking web services. While using JAX-WS, you will rarely have to deal with the SOAP protocol, which is nice because it makes you a lot more productive.

WSDL 1.1

The Web Service Description Language (WSDL) is an XML document used to describe a web service. WSDL is programming-language, platform, and protocol agnostic. The fact that WSDL is protocol agnostic means that it can describe web services that use protocols other than SOAP and HTTP. This ability makes WSDL very flexible, but it has the unfortunate side effect of also making WSDL abstract and difficult to understand. Fortunately, the WS-I Basic Profile 1.1 endorses only SOAP 1.1 or 1.2 over HTTP, so we’ll discuss WSDL as if that’s the only combination of protocols supported.

Imagine that you want to develop a web services component that implements the following interface:

Any application should be able to invoke this method using SOAP, regardless of the language in which it was written or the platform on which it is running. Because other programming languages don’t understand Java, we have to describe the web service in a language they do understand: XML. Using XML, and specifically the WSDL markup language, we can describe the type of SOAP messages that must be sent to invoke the makeReservation() method. A WSDL document that describes the makeReservation() method might look like this:

If you find the previous WSDL listing indecipherable, don’t despair. Most people can’t understand a WSDL document the first time they see one. Like many things that are complicated, the best approach to understanding WSDL is to study it in pieces. And fortunately, modern web services platforms, such as JBoss, provide tools to generate the WSDL for you. WSDL should be something you need to look at only when things break. At this point, things still break often, so it’s helpful to be familiar with WSDL; it will show you what the server expects when a method is called. But don’t think that you’ll be called on to write a WSDL document by yourself.

The <definitions> Element

The root element of a WSDL document is the <definitions> element. Usually, a WSDL document declares all the XML Namespaces used in the root element. In the previous example, the <definitions> element makes four XML Namespace declarations:

The default namespace (xmlns=”http://schemas.xmlsoap.org/wsdl/”) is the WSDL namespace. The xsd prefix is assigned to the XMLSchema namespace. It is used primarily to identify simple data types such as xsd:string, xsd:int, and xsd:dateTime in <message> elements:

The titan prefix is assigned to a Titan Cruises URL, which indicates that it’s an XML Namespace belonging to Titan Cruises. This namespace is also the value of the target Namespace attribute. This attribute is similar to the one used in XML Schema. For example, the <portType> element references <message> elements and the <binding> element references a <portType> element using the target namespace:

As you can see, the different WSDL types reference each other by name, and a named WSDL type automatically takes on the namespace declared by the targetNamespace attribute.

The <portType> and <message> Elements

The <portType> and <message> elements are the immediate children of the <definitions> element. Here’s what they look like:

The <portType> element describes the web services operations (Java methods) that are available. An operation can have input, output, and fault messages. An input message describes the type of SOAP message a client should send to the web service. An output message describes the type of SOAP message a client should expect to get back. A fault message (not shown in the example) describes any SOAP error messages that the web service might send back to the client. A fault message is similar to a Java exception.

JAX-WS, and therefore EJB 3.1, supports two styles of web services messaging: request-response and one-way. You know you are dealing with request-response if the <operation> element contains a single <input> element, followed by a single <output> element and, optionally, zero or more <fault> elements. The TravelAgent <portType> is an example of the request-response messaging style:

The one-way message style, on the other hand, is implied by the presence of a single <input> element but no <output> or <fault> element. Here is a web service that supports one-way messaging:

The request-response style of messaging is the kind you expect in RPC programming; you send a message and get a response. The one-way style tends to be used for asynchronous messaging; you send a message but do not expect a response. In addition, one-way messaging is frequently used to deliver XML documents, such as the Reservation document, rather than parameters and return values. However, both request-response and one-way messaging styles can be used with either RPC or document-style messaging.

WSDL also supports two other messaging styles: notification (a single <output> and no <input>) and solicitation (a single <output> followed by a single <input>). Although WSDL makes these messaging styles available, they are not supported by WS-I Basic Profile 1.1 or JAX-RPC.

The <types> Element

If your service needs any custom types, they are defined in the <types> element, which is the first child of the <definitions> element. The complete WSDL document shown earlier did not include a <types> element because it didn’t define any new types (it used XML Schema built-in types). The <types> element allows us to declare more complex XML types. For example, instead of declaring each parameter of the makeReservation operation as an individual part, you can combine them into a single structure that serves as the parameter of the operation:

The <types> element is frequently used with document-oriented messaging. For example, the following WSDL binding defines an XML Schema for the Reservation markup so that Reservation documents can be submitted to Titan as one-way messages. The schema is embedded within the WSDL document as the content of the <types> element:

The <binding> and <service> Elements

In addition to the <portType> and <message> elements, a WSDL document also defines <binding> and <service> elements. JAX-WS specifies these elements to generate marshaling and network communication code that is used to send and receive messages.

The <binding> element describes the type of encoding used to send and receive messages as well as the protocol on which the SOAP messages are carried. The <binding> definition for the TravelAgent port type looks like this:

A binding element is always interlaced with protocol-specific elements—usually, the elements describe the SOAP protocol binding. (In fact, this is the only binding that is allowed by the WS-I Basic Profile 1.1.) Because Java EE web services must support SOAP with attachments, the MIME binding is also supported when attachments (images, documents, and so on) are sent with SOAP messages. However, that subject is a bit involved and is outside the scope of this topic.

Similar to the <portType> element, the <binding> element contains <operation>, <input>, <output>, and <fault> elements. In fact, a binding is specific to a particular <portType>: its <operation>, <input>, and <output> elements describe the implementation details of the corresponding <portType>. The previous example used the HTTP protocol with RPC/Literal-style messaging. The WSDL binding for Document/Literal-style messaging is different:

The <binding> element describes a one-way web service that accepts an XML document fragment. The <portType> associated with this <binding> also defines a single input message (consistent with one-way messaging) within an operation called submitReservation:

UDDI 2.0

Universal Description, Discovery, and Integration (UDDI) is a specification that describes a standard for publishing and discovering web services on the Internet. It’s essentially a repository with a rigid data structure describing companies and the web services they provide. UDDI is not as fundamental to web services as XML, SOAP, and WSDL, but it is considered a basic constituent of web services in Java EE.

The analogy normally used to describe UDDI is that it provides electronic White, Yellow, and Green pages for companies and their web services. You can look up companies by name or identifier (White pages) or by business or product category (Yellow pages). You can also discover information about web services hosted by a company by examining the technical entities of a UDDI registry (Green pages). In other words, UDDI is an electronic directory that allows organizations to advertise their business and web services and to locate other organizations and web services.

Not only does a UDDI registry provide information about web services and their hosts, a UDDI repository is itself a web service. You can search, access, add, update, and delete information in a UDDI registry using a set of standard SOAP messages. All UDDI registry products must support the standard UDDI data structures and SOAP messages, which means that you can access any UDDI-compliant registry using the same standard set of SOAP messages.

Although organizations can set up private UDDI registries, there is a free UDDI registry that anyone can use, called the Universal Business Registry (UBR). This registry is accessed at one of four sites hosted by Microsoft, IBM, SAP, and NTT. If you publish information about your company in any one of these sites, the data will be replicated to each of the other three. You can find out more about the UBR and the sites that host it at http://uddi.xml.org/.

From Standards to Implementation

Understanding the fundamental web services standards (XML, SOAP, and WSDL) is essential to becoming a competent web services developer. However, you’ll also need to understand how to implement web services in software. Numerous web services platforms allow you to build production systems based on the web services standards, including .NET, Perl, and Java EE. The focus of this topic is obviously the Java EE platform, and specifically, support for web services in EJB.