In this article, we will provide an overview of Java Web Services. We will look at the characteristics of the services and API used on the platform as well as the role of the WS-I Basic Profile. This is part of a larger series of articles to help you prepare for the web service developer exam. You can review the last article, “Tutorial:In Depth Look at JAXR for the Web Service Developer Exam” if needed.

What is Java Web Services

All modern enterprise Java applications that need to support the principles of Service-Oriented Architecture (SOA) are based on the foundation of Web services. Java Web Services is about interoperability between Java EE 5 servers and any other Web services platform, including the .NET Framework, Perl, Apache Axis, Python, and C++, to name a few. Using the Web service technologies of Java EE 5 your system can be interoperable with any other system since Web service technologies are platform-agnostic. This is because the medium used to communicate is not specific to any combination of programming language, operating system, and hardware.

The core of Java Web Services interoperability, and of Web services interoperability in general, is the Basic Profile 1.1 (BP). This profile is published by the Web Services Interoperability Organization (WS-I). It provides a set of rules governing the way applications use common Web service technologies. The BP makes Web service interoperability practical by dictating how features of each specification should and should not be implemented. This introduces a series of design standards of its own, targeted primarily at resolving potential interoperability issues.

Java EE 5 vendors are required to support the BP as well as other Web Services APIs that that don't conform to the BP such as SOAP Messages with Attachments and RPC/Encoded messaging. In this article, we will provide an architectural overview of the Java EE 5 platform, Web service technologies, and the Java EE 5 Web Services APIs.

The Java EE 5 Platform

The Java Enterprise Edition 5 Platform specification describes a variety of enterprise Java APIs that are integrated into a complete platform. The Java EE 5 specification details how an application server configures and deploys the core components of the Java EE 5 (i.e. Enterprise JavaBeans 3.0, Java Servlets 2.5, and JavaServer Pages 2.1) and manages them at runtime. The Java EE 5 specification also details how server-side components interact with application server, resource APIs like Java Database Connectivity (JDBC) and Java Message Service (JMS) as well as each other. The figure shows the various components and APIs supported by the Java EE 5 specification.

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-javaee5platform.jpg
Figure 1-1. The Java EE 5 Platform

The figure gives an overview of the Java EE 5 architecture. The EJB and servlet/JSP components reside within their own containers, which manage their life cycles, incoming and outgoing messages, transactions, security, and other qualities of service. EJB and Servlet/JSP components have access to all of the resource APIs, such as Web Services, Java EE 5 Connectors (including JDBC), JMS, JavaMail, Security, Transactions, and Java EE 5 Management APIs. The entire platform is built on the Java 5 Platform, Standard Edition (JSE) 5, and runs in one or more Java Virtual Machines.

The Java EE 5 specification leverages several other specifications for its programming model and behavior of the EJB, servlet and JSP components as well as the Java EE 5 Connector, JDBC, JMS, JavaMail, JMX, and other resource APIs. The Java EE 5 specification provides the glue keeping all of these specifications together. As for Web service components, the Java Web Services requires compliance with the WS-I Basic Profile 1.1.

A Look at Java Web Services

Java Web Services (JWS) are included in the Java EE5 platform in order to facilitate the development of interoperable system using the principles of Service Oriented Architecture. The standards that form Java Web Services are shown in the table below:

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-jwssupportedstandards.jpg
Table: Standards supported by JWS

The JWS standards are of very important as they are the foundation for SOA development in enterprise Java. Loosely coupled SOA applications are critical components to corporations since they enable business processes to be flexible and to adapt to rapidly changing global markets. When enterprise java developers are looking to create SOA applications from loosely coupled Web services, they use JWS tools to do this. Leading enterprise Java vendors hold up JWS technologies as the development platform of choice for SOA applications.

The Technologies of Web Services

Web services has been given many different definitions, depending on the perspective of the person. There are definitions proposed by the media and so called Web services experts that are completely useless due to their ambiguity. In the Java EE 5 environment, the term "Web services" has a very specific meaning based on a standard adopted by all the major enterprise vendors including Oracle, Microsoft, IBM, Software AG,. Web services have the following definition:

A Web service is a software application that conforms to the Web Service Interoperability Organization's Basic Profile 1.1.

Before the definition of the Basic Profile by WS-I, the term "Web service" was simply too general to fulfill the technology's main purpose of interoperability. Web service technologies purpose is to allow applications on different platforms to exchange business data. These Web service technologies can be used for a number of different types of interactions. These can be Enterprise Application Integration (EAI) integration, Business-to-Consumer (B2C) communication or Business-to-Business (B2B) communication. EAI is used to refer to disparate applications in an organization communicating and exchanging data. B2C refers to consumers exchanging information with an organization. Finally B2B refers to when multiple organizations that are typically business partners, exchange data via multiple systems. Web service technologies today are used in all of these settings and there is huge growth in the B2C and B2B areas. A figure showing B2C Web service interaction is shown below:

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-webserviceinteraction.jpg
Figure: Web Services Interaction

For a computer programmer, interoperability is the capability of two different software applications to communicate. For example, the ability to access an application written in C++ running on Windows from a Java application running on Linux is a matter of interoperability. In order for a Java application on a Linux platform to access a C++ application on a Windows platform, you have to use network technologies that are independent of both the operating system and the hardware. This capability is already met by TCP/IP, DNS, and HTTP, and the Web service standards: XML, SOAP, WSDL, and UDDI.

XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration) are used in concert to provide Web service applications with a type system (XML), a messaging protocol (SOAP), an interface definition language (WSDL), and a registry for publishing Web services (UDDI). XML documents contain the information being exchanged between two parties, while SOAP provides a packaging and routing standard for exchanging XML documents over a network. WSDL allows an organization to describe the types of XML documents and SOAP messages that must be used to interact with their Web services. Finally, UDDI allows organizations to register their Web services in a uniform manner within a common directory, so clients can locate their Web services and learn how to access them.

The core Web service technologies are the basis for Java EE 5 Web Services. The technologies are XML, SOAP, WSDL and UDDI. These technologies we have covered in previous articles in the series for the Web Service Developer exam. These are: “Tutorial: Review of SOAP Web Services for the Web Service Developer Exam”, “Tutorial:Review of WSDL Document for the Web Service Developer Exam” and “Tutorial:In Depth Look at UDDI for the Web Service Developer Exam”. The Java Web Services APIs (i.e. JAX-WS, SAAJ, JAXR, JAXP) conforms with one or more of the Web services technologies. Therefore it is critical that you have a basic understanding of XML, SOAP, WSDL, and UDDI in order to know how Java EE 5 Web Services works. You will also need a good understanding of the WS-I Basic Profile 1.1, which we covered in, “Tutorial:Review of Building Web Services for the Web Service Developer Exam” in order to ensure interoperability across a range of platforms.

Understanding WS-I Basic Profile 1.1

The Web Services Interoperability Organization is an organization of Web services vendors committed to defining a standard for Web services interoperability. The first deliverable of the WS-I was the Basic Profile 1.0. This has now been updated to Basic Profile 1.1. This deliverable details how one uses the four primary Web services specifications together in Web services. The BP defines a set of conformance rules for clearing up ambiguities in the specifications of XML, WSDL, SOAP, and UDDI as well as defining concretely how to use these technologies together in order to register, describe, and communicate using Web services.

The development of the BP was required in order to provide clarification to the primary specifications. The specifications are seen as being too broad and open to interpretation to facilitate interoperability between various systems. Consider a WSDL for example. This is a very generalized technology allowing you to describe any kind of Web service. But the WSDL specification is so general that in many circumstances it is difficult to determine how a SOAP message should be formatted in order to be exchanged with the Web service. The WSDL defines features that unfortunately have complicated interoperability through things such as the SMTP and MIME bindings. If is for this reason that BP was defined. It explains exactly how WSDL should describe SOAP-based Web services as well as detailing restrictions on the use of WSDL.

Using the Basic Profile makes doing interoperability easier, but you are not required to adhere to the standard. If you want to use a Web service that conforms with the BP, using this service will be easier since it will be clear what you need to do to locate and communicate with that Web service. If it didn’t conform to the Basic Profile, your task would be much more difficult. To be perfectly honest, interoperability without the BP is pretty difficult to achieve. While XML, SOAP, WSDL, and UDDI have important roles, their use together is not well coordinated because each specification was developed independently. The BP defines the glue that binds these technologies together into one coherent specification.

The major vendors in the Java EE, .NET, Linux, and other platforms have all agreed to support the Basic Profile. This implication is that irrespective of the platform on which it is built, be it LAMP, Java EE, .NET, etc, you should be able to communicate with WS-I conformant Web services hosted by products on these platforms with little or no interoperability problems. Through the WS-I Basic Profile, it now is possible to define applications that are interoperable across most application platforms. It doesn’t matter if you have defined your Web services in an application written in any of the following programming language (i.e. Java, C++, C#, Perl, et al.), on the following operating systems (i.e. Unix, Microsoft, Linux, Mac, et al.), using any of the following development platforms (i.e. .NET Framework, WebLogic Application Server, WebSphere Application Server, et al.). Your Web services should be able to link up and communicated with other conformant Web services.

Now that we have covered what is the Basic Profile, let’s look at the relevant Java EE 5 Web service technologies that support the Basic Profile as well as Web services in general.

Core Web Service Technologies - XML

We use eXtensible Markup Language (XML) in order to organize documents and business data. It is a meta-language (i.e. a language for defining other languages) defined by a specification. XML defines a set of rules that are used for creating XML markup languages. A XML markup language defines a set of tags used to organize and describe text. This is known as an XML application. The tags are normally paired together with a start tag and an end tag. Everything between the tags are called an element. So for example, XHTML which is used for describing web pages is a markup language, as well as CML which is used for chemistry and MathML which is used for mathematics.

One very important part of the XML specification that is used with markup languages is the XML schemas which is used to describe a XML markup language’s structure in terms of simple types and complex types. Simple types are the primitive data types contained by elements and attributes, while complex types describe how elements are organized and nested.
XML documents can easily be stored or transformed as well as being transmitted between two applications on a network. Although XML documents are just plain text containing special tags that label different parts of a document or fields of data, they are usually read by software applications that read and manipulate XML documents through the use of a parser. There are basically two standard kinds are parsers:
  • SAX - this stands for Simple API for XML. This parser reads an XML document, starting at the beginning, it fires off events every time it encounters a new element, attribute, piece of text, or other component.
  • DOM - This stands for Document Object Model. DOM provides the programmer with a generic, object-oriented model of an XML document. Elements, attributes, and text values are represented as objects organized into a hierarchical tree structure reflecting the hierarchy of the XML document being processed. DOM allows an application to navigate the tree structure, modify elements and attributes, and generate new XML documents in memory. It's slow compared to SAX. It consumes a lot more memory but is quite powerful.

An example of an XML containing's mailing address is shown below:

XML Code: Acme XML Document with Mailing Address
<?xml version="1.0" encoding="UTF-8"?>
   <street>555 Main Street</street>
XML is the foundation on which is built all the other Web services technologies. As you know all of the Web services technologies specified by the WS-I Basic Profile 1.1 are built on top of XML and the W3C XML Schema Language.

Core Web Service Technologies - SOAP

If you wanted to build an EAI or B2B system based on XML, you had to define your own networking, addressing, and routing protocols, or use a proprietary system provided by a vendor. No two vendors were using the same protocols for exchanging data, so interoperability was difficult, to say the least.

SOAP which originally meant Simple Object Access Protocol defines a standard packaging format for transmitting XML data between applications on a network. It is neutral to all programming languages, products, or hardware platforms and therefore can be used by almost any kind of application written in C++, Java, .NET, Perl, legacy systems, and others. At its core, a SOAP message is just a specially designed XML document that contains and transmits other XML documents as well as the information related to routing, processing, security, transactions, and other service qualities. When SOAP came along there was at the time no widely accepted standard for routing and packaging XML data exchanged between two applications on a network. You would have needed a tedious custom-built solutions to get any two XML-based systems to communicate.

An instance of a SOAP XML document is called a SOAP message. It is carried as a payload over some other network protocol. The most commonly used network protocol for exchanging SOAP messages is HyperText Transfer Protocol (HTTP) that is the protocol used by Web browsers to access HTML Web pages. Unlike with a web browser where the HTML is transformed into a human readable form, SOAP messages are generally exchanged between applications on a network and are not meant for human consumption. As HTTP is so prevalent on the web, it is seen as a convenient way of sending and receiving SOAP messages. Below is an example of a SOAP message containing the XML address information from the listing above that is sent from one application to another to synchronize contact information on two different systems.

XML Code: SOAP Message Contains Address Information
<?xml version="1.0" encoding="UTF-8"?>
 xmlns:addr="" >
      <addr:street>555 Main Street</addr:street>
SOAP leverages advanced XML features such as XML namespaces and XML schemas. The SOAP messages serves as a network envelope for exchanging XML documents and data. By having a single industry standard for packaging and exchanging XML data, Web service applications are now more interoperable, understandable, and easier to implement.

SOAP 1.2 is considered part of the WS-I Basic Profile 1.1. The BP requires the use of SOAP 1.2 and has a number of clarifications and restrictions used to eliminate interoperability problems associated with the specified standard.

There is an corollary specification called SOAP with Attachments (SAAJ) that is used mainly for the SOAP messaging that is an API that developers can use to write SOAP messaging applications directly instead of using JAX-WS. The SAAJ API allows you to do XML messaging from the Java platform by making method calls using the SAAJ API. You can read and write SOAP-based XML messages, and optionally send and receive such messages over the Internet although some implementations may or may not support sending and receiving of message. SAAJ is supported in BP, version 1.1.

Core Web Service Technologies - WSDL

The Web Services Description Language (WSDL) is a standard for describing the structure of the XML data exchanged between two systems using SOAP. Anytime you create a new Web service, you can create a WSDL document that is used to describe the type of data (i.e. SOAP messages) that you have available to exchange between Web service clients and servers. It is used to specify the exact message format, internet protocol as well as address that a client needs to communicate with a particular Web service.

Although WSDL is a Web services standard, it's is quite complex. The complexity results from the designers' intention to create an interface definition language (IDL) for Web services that is not tied to any specific protocol, programming language, or operating system. It is important to remember that WSDL 1.1 is not specific to SOAP and can be used to describe non-SOAP-based Web services as well. The BP requires the use of WSDL 1.1, but due to the flexibility of the specification, includes strict rules on how it's used, to improve interoperability.

Core Web Service Technologies - UDDI

The Universal Description, Discovery, and Integration (UDDI) specification defines a standard set of Web service operations that can be used to store and look up information about other Web service applications. UDDI defines a standard SOAP-based interface for a Web services registry. Generally, a UDDI registry is used to find a particular type of Web service or about the Web services hosted by a specific organization. UDDI registry is often referred to as the "Yellow Pages" for Web services. When you look up information about a Web service in a UDDI registry, you can define criteria based on various categories such as technologies used, business types, industry, etc. The entries in a UDDI registry provides information on where the Web service is located and how to communicate with it. The UDDI registry also provides information about the organization that hosts a particular Web service. A figure showing a UDDI Registry is shown below:

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-uddiregistry.jpg
Figure: UDDI Registry

UDDI can also be used to store data about other types of services. This could be a phone service or a Web site. The UDDI specification was created originally by a multi-vendor organization called that was led by Microsoft and IBM but is now maintained by the Organization for the Advancement of Structured Information Standards (OASIS). There is a free UDDI registry that is available for everyone to use to develop, test and publish their web services. The majority of UDDI registries are for private systems deployed by individual companies or trade organizations. General Electric could set up a private UDDI registry containing information about all the Web service applications offered within the corporation or a trade organization like the Association of American Manufacturers could set up a UDDI registry containing information on all of its members as well as their Web service applications.

Of the core Web services technologies, UDDI is the only one technology that the Basic Profile considers optional. Although you don’t need UDDI, if you are planning to publish a Web service. You need a Web service registry, UDDI is the preferred technology. The Basic Profile specifies the use of UDDI version 2.0.

The Java Web Service APIs

There are four Java Web Service APIs. These are JAX-WS, SAAJ, JAXR, and JAXP. They are the APIs you will need to understand in order to implement Web service applications using the Java EE 5 Platform. The most important Web service API is JAX-WS, which is used to implement Java EE 5 Web service clients and endpoints (services).


JAX-WS stands for Java API for XML Web Services. It specifies the invocation subsystem for Java Web Services. JAX-WS is a technology used for building web services and clients that communicate using XML. With JAX-WS, developers can write message-oriented as well as RPC-oriented web services.

A web service operation invocation is represented by an XML-based protocol such as SOAP in JAX-WS. SOAP messages are complex. The SOAP specification defines the envelope structure, encoding rules, and conventions for representing web service invocations and responses as well as the use of HTTP as the transport protocol. The JAX-WS API serves to hide this complexity from the developer. On the server side, the developer defines the methods in the interface in the Java programming language as well as implementing these methods. This specifies the web service operations. Client programs are easy to code as the client creates a proxy and then simply invokes methods on the proxy. With JAX-WS, there is no need for the developer to generate or parse SOAP messages. This is done by the JAX-WS runtime system that converts the API calls and responses to and from SOAP messages.

Another advantage of JAX-WS is that it is platform independent of Java is conferred on to the client and web services that use it. JAX-WS is not in any way restrictive. You can use a JAX-WS client to access a web service running on any platform. This is because JAX-WS uses technologies the core web services technologies such as XML, SOAP and WSDL in addition to the transport protocol of the World Wide Web (W3C), HTTP. Below is a table showing the many feature available in JAX-WS:

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-jax-wsfeatures.jpg
Table: JAX-WS Features

Java/WSDL Mapping
The JAX-WS 2.0 specification defines a standard Java/WSDL mapping, which is part of the JWS deployment subsystem. It determines how WSDL operations are bound to Java methods such as when a SOAP message invokes a WSDL operation, the Java/WSDL mapping determines the Java method that is invoked as well as how that SOAP message is mapped to the method’s parameters. Note that the mapping also determines how the method’s return value gets mapped to the SOAP response.

You can use a JAX-WS processor such as java2wsdl or wsgen to pass through a Java class, and with standard mapping, generate a WSDL description of a Web service endpoint. The developer can tweak the generated WSDL by annotating the Java source code as we discussed in the article, "Tutorial:Review of JAX-WS Client Side for the Web Service Developer Exam". The generated WSDL is always consistent with the WS-I Basic Profile 1.1.

You can also start with a WSDL document and generate Java classes and interfaces. In this case the standard mapping can be customized through embedded binding declarations via annotations to the WSDL source made by using the jaxws:bindings extension element or by supplying an external binding file that contains the declarations. The generated Java classes are wrapper classes that needs to be completed by adding business logic to implement the Web service. These classes include source code annotations that describe the WSDL/Java mapping.

Static WSDL
You can use static WSDL documents that doesn’t require automatic generation of the WSDL by JAX-WS. This is quite useful when you need to publish a Web service that conforms to a specific WSDL. This is the most common situation when you’re doing systems integration using SOA. You can then use this capability in order to publish WSDL based on existing schemas instead of with JAXB-generated types. This approach using the static WSDL approach when you want to start your development based on a WSDL.


We previously mentioned the SOAP with Attachments API for Java API (SAAJ) when we were discussing SOAP. It is a low-level SOAP API that conforms with SOAP 1.1 and SOAP Messages with Attachments specifications. You can use SAAJ to build SOAP messages from scratch or to read and manipulate SOAP messages. It can be used on its own to create, transmit, and process SOAP messages, but most likely you will use it in conjunction with JAX-WS to process SOAP header blocks holding SOAP message meta-data.

The Java API for XML Registries (JAXR) is a client side API for accessing UDDI registries. It’s purpose is twofold. It models the data structures managed by ebXML and UDDI registries and provides an API for searching registries and publishing data to registries. It simplifies the process of publishing and searching for Web service endpoints. Although it was originally intended for ebXML registries, it has been adapted for UDDI. But it is still used equally with ebXML registries which originally competed with UDDI registries. The figure below shows the data structures of UDDI and JAXR:

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-uddijaxrmapping.jpg
Figure: Data Structure Mappings for UDDI and JAXR

The figure shows that the mapping between UDDI data structures and JAXR interface types is very similar. Although the JAXR names are a little different since they are originally derived from ebXML, the purposes of the types and their relationships are the same. Once you dive down deeper into the fields of these types, it becomes clear that JAXR actually has a richer, more object-oriented model than UDDI because the model supports both ebXML and UDDI. The set of business-domain types of JAXR includes Organization, PostalAddress, and Contact as well as more technical-domain types such as ServiceBinding, ExternalLink, and Classification. These domain models map nicely to UDDI data types.

JAXR also defines APIs for publishing and searching for information in a UDDI registry. The JAXR API hides many of the UDDI’s Inquiry and Publishing APIs behind Java. For example, to navigate from an Organization to its WSDL Concept, the JAXR implementation sends several inquiry messages to the UDDI registry without you being aware of it in order to complete the request. Behind the scenes, JAXR creates and sends a number of SOAP messages automatically in order to construct a complete information model so that the registry is easier for you to peruse.


The Java API for XML Processing (JAXP) provides a framework for using working directly with XML documents. You can use either of the two parts of the standard APIs (i.e. DOM 2 and SAX2) for reading, writing, and modifying XML documents.

The Document Object Model (DOM) is a set of interfaces and classes that is used to model XML documents as a tree of objects called nodes. The DOM interfaces and classes represent XML documents, elements, attributes, text values, and all the other constructs from the XML language. It is a Java API that models XML documents as trees of objects. DOM 2 tends to be used in situations where we are less concerned with the speed and memory used in parsing the XML document but more interested in doing complex manipulation of XML documents. DOM 2 serves as the basis of SAAJ 1.1. The figure below shows a DOM Parser handling a XML document:

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-domparser.jpg
Figure: DOM Parser Handling a XML Document

The SAX2 (Simple API for XML, version 2) is very different in functionality from DOM 2. The Simple API for XML (SAX2) uses an event-based architecture for processing XML documents. When you use SAX, you create a class to implement one of the three SAX listener interfaces and register the instance of that class with the SAX parser at runtime. The SAX parser then reads an XML document from a data stream sequentially from beginning to end and sends events to the listener object that you registered while reading the stream. When a SAX parser reads an XML document, it fires events as it encounters start and end tags, attributes, values, etc. You register listeners for these events and are notified by the SAX2 parser as it detects changes in the XML document it is reading. The figure below shows a SAX parsing handling a XML document:

Tutorial:Review of Java Web Services for the Web Service Developer Exam-b13-saxparser.jpg
Figure: SAX Parser Handling a XML Document

JAXP version 1.2 is part of Basic Profile 1.1.


Here we have only provided an overview of the Web Services capabilities provided by Java Web Services. The purpose was to ensure that for a generic SOA application you would be clear as to where Web Services fit in. We also described some of the runtime implementation details of Web Services within Java EE 5 and Java SE 5. We did a review of the development and deployment features of JAX-WS 2.0, JAXB 2.0, WS-Metadata 2.0, WSEE 1.2, and some of the other specifications related to Web Services. You should now have a good overview of Java Web Services as well as some ideas as to the advantages and disadvantage of its use as a platform for Service Oriented Architecture development.

Note that we have always framed the majority of the discussions in the context of the Web Services Interoperability Organization's Basic Profile 1.1. This is because it is very important for you to understand WS-I Basic Profile 1.1 in order to achieve Web service interoperability easily not only with within your organization but also with third parties. Any experienced Web service developers can tell you horror stories around interoperability due to poorly defined standards aligned to an overly broad vision. That is why standards like SOAP, WSDL, and UDDI and the WS-I Basic Profile helps to eliminate many of the ambiguities inherent in these primary standards, all the while making interoperability among disparate Web service platforms possible.