Java Service Model - XML

The Java service model forms the basis of the Java Web services architecture, which is similar to any other Web services architecture. The Java service model is based on the Service-Oriented Architecture (SOA). The SOA considers a Web service a process or a group of processes that are made up of components. These components are objects that form the building blocks of Web services.

The Java service model is similar to the Java Service Framework (JSF), which is a framework for creating interoperable applications on the Java platform. The JSF is a means of creating cost-effective applications easily and quickly. Also, the applications that the JSF creates are reusable components that several applications on the Java platform can use. In addition, the JSF defines a relationship between an application and its management. The JSF uses J2EE to develop Web services. As a result, the programmers benefit from the components that J2EE provides for easy deployment of the Web services.

Features of the Java Service Model

The Java service model has the following features:

  • Abstraction
  • Encapsulation
  • Modularity
  • Polymorphism

These features are found in Object-Oriented Programming (OOP)-based languages. This implies that the SOA is similar to the Object-Oriented Architecture (OOA). Therefore, as objects are the building blocks in the OOA, similarly, components are the building blocks of services, which are the basic elements in the SOA. At this point, we will discuss the features of the SOA in detail.


Consider a simple example in which a user tries to log on to an authorized site by specifying a username and password. In this case, the user is given access permissions only if the username and password are validated.

This entire process of validating the user data is internally divided into several subprocesses, as discussed in the following list:

  1. A user provides the user data, username, and password.
  2. Validation tests are performed on the username and password. For example, the password should be at least four characters long; the password should consist of special characters, such as @, #, &, *, and so on in addition to letters and numerals; and the username should begin with a letter.
  3. If the validation tests are verified, the username and password are matched against the data in the database that stores the authorized usernames and passwords. To validate a username and password, a query is used.
  4. If the username and password are invalid, an exception is raised and the user is denied access to the site.
  5. If the username and password are valid, the user is allowed to access the site.

All processes mentioned in the preceding list comprise a single process: verification of the user data. However, to the end user, the entire process seems simple. This method of hiding the complex functionality from the end user is called service abstraction. In this method, the end user is cognitively familiarized with the functionality that the Web service performs.


As in OOPs, encapsulation is a method of implementing abstraction. Similarly, service encapsulation is used to implement service abstraction.

In the previous example, we briefly described each of the subprocesses that is performed within the main process of validating user data. To implement the subprocesses and the main process, the programmer needs to write the business logic or the code for the Web service. However, the business logic is separated from the user interface. This implies that the end user does not have access to the code of the Web service. This method of separating the business code from the user interface and, therefore, hiding the business logic from the end user, is called service encapsulation.

In addition to implementing service abstraction, service encapsulation provides several other benefits for the end user and the programmer. For example, the end user or the client application can implement the functionality of the Web service in different ways. This mechanism of implementing functionality in different ways is explained in detail in the later section titled "Polymorphism."

The process of encapsulation benefits both the programmer and the client application. The programmer benefits by having the freedom to modify earlier versions of existing code without affecting any of the client applications. The client application in this case has access to the new and improved version of the Web service without making changes to the framework.


Service modularity is a mechanism of creating modules of services that are closely related to each other. For example, the user validation service that we discussed in the previous example is closely related to the credit card validation service. As a result, the user validation service can be placed in the same module as the credit card validation service. The modules of services, in turn, are grouped together to form the service library. A service library allows you to categorize various services based on their functionality or any other criterion.

As you know, a Web service is a reusable piece of code. Therefore, the concept of a service library allows several users to reuse existing services by customizing an available piece of code according to their needs. Categorizing services into modules enables a user to easily locate a required service, and therefore, provide reusability of Web services.

To understand the concept of service modularity, consider an example of a module of services called the Travel service module. This module consists of a travel Web service, which in turn consists of several other Web services, such as a ticketing Web service that allows you to book your tickets online. Then, it might consist of a tourism Web service that acts as a guide for places you will visit. The travel Web service might also contain hotel reservation and cab booking Web services. All these Web services work together to create a package called the Travel and Tourism package.

It is important to note, however, that the services included in the same module only complement each other. In the absence of any service, the working of other services is not affected. For example, if the Travel and Tourism package does not include the hotel reservation or cab booking Web service, then the functionality of the ticket reservation Web service is unaffected. However, the presence of these services does extend the functionality of the module as a whole. As a result, to implement reusability of the Web services, the user can benefit from the entire module rather than individual Web services.


Polymorphism enables an entity to exist in multiple forms. As in OOP, an object can exist in multiple forms to implement polymorphism. Similarly, in SOA, a service can be implemented in several ways. Polymorphism extends the features of abstraction and encapsulation to enable a client application to differently implement the same Web service. This implies that a generic Web service interface is created, which you can customize according to your needs.

Consider an example of the Travel and Tourism package that we discussed in the previous section. In this case, the package can include a generic code for the ticketing and tourism Web service. The user can then modify the existing code to provide different implementations. For example, he can use the ticketing Web service to book tickets for railways or airplanes. Similarly, the tourism Web service can be tailored to guide you about any place that you specify.

Polymorphism is a result of encapsulation. This is because the business logic of the service is hidden from the end user; therefore, the programmer can modify the existing code to implement a new functionality. As a result, the user can benefit from multiple implementations.

Components of the Java Service Model

The Java service model consists of various components that include the roles in the Web service architecture and the standards or the technologies used in the Java service model. These components are shown in Figure.

Components in the Java Service Model

Components in the Java Service Model

The following sections discuss these components in detail.

Roles in the Java Service Model

The roles that are defined in the Java Web service architecture are similar to the roles in any other Web service architecture. These roles are defined in the following list:

  • Service requestor
  • Service broker
  • Service provider

We will discuss these roles in detail in the following sections.

Service Requestor

A service requestor is a client application that sends in a request for a Web service. A Web service that is created is registered in the service registry. Therefore, whenever it's required, the service requestor application looks for a Web service in the service registry and then binds to the required Web service.

For example, several Web services already exist that perform the same functionality as the Web services in the Travel and Tourism package. These Web services are registered with the service registry. Therefore, a user can reuse an existing Web service by locating it on the service registry.

To access the desired Web service, a client application sends a request for the Web service to the service provider application. You will learn about service providers and service registries in the following sections.

It is important to note that a service requestor application can be any application that is created on any platform and by using any programming language. It is not necessary that a Java Web service be accessible only from a Java client application. In addition, a Web service can act as a client application when a Web service requests another Web service. To summarize, the service requestor application performs the following activities:

  • Identifies the need for a Web service
  • Looks for the Web service in the service registry
  • Discovers the Web service
  • Obtains the proxy address of the provider application that hosts the Web service
  • Binds to the required Web service
  • Accesses the Web service

Service Broker

A service broker is a service registry that provides a list of all existing Web services. When a user creates a Web service, he needs to register it with the service registry. This helps a client look for desired Web services. A UDDI is an example of a service registry. You learned about UDDIs in "Introduction to UDDI."

A service broker provides a mechanism for registering a Web service. The information about the Web service is made accessible to the service clients. In addition, the service broker application manages the request for the Web service. Similarly, when a service provider processes the request and sends in the response, the service broker application manages the response.

After a service requestor application binds to a Web service, a contract is signed between the service requestor application and service provider. The contract can be for a lifetime or for a definite lease period. The service broker application manages this contract. When a lease period of a contract is over, the service broker can renew or terminate the contract, as required. Therefore, as you can see, the service broker application acts as an interface between the service requestor and the service provider application that I will discuss in the following section.

Service Provider

The service provider application hosts a Web service. In other words, it provides the Web service to any application that requests it. A service provider application operates in the following stages:

  • Developing the Web service. This stage includes creating the design of the Web service, creating the Web service, and testing and deploying the Web service.
  • Publishing the Web service. In this stage, the business organization that hosts the Web service publishes the Web service with the service registry.
  • Managing the access of the Web service. In this stage, the service provider application provides the Web service to the requesting application so that the client application can access it.

Figure shows the roles in the Java Web services architecture.

Roles in the Java Web Services Architecture

Roles in the Java Web Services Architecture

Standards Used in the Java Service Model

Similar to the standards used in any Web services architecture, the Java service model uses the following standards:

  • SOAP. As in any other Web services scenario, SOAP is used to communicate between applications that are a part of the Java service model. SOAP generally uses HTTP to transfer data between these applications. All the communication that takes place between the applications is packaged as a SOAP message. For example, the request and response are packaged as SOAP messages to be transferred across the applications.
  • UDDI. UDDI is a standard that is used to register a Web service. It allows a client application to access the registered information about a Web service.
  • WSDL. WSDL provides a standard format for publishing and describing a Web service.
  • WSFL. Web Services Flow Language (WSFL) is an XML-based language that describes the composition of a Web service. WSFL consists of two types of compositions: flow models and global models. The flow model defines a composition of a business process, whereas the global model describes the interactions of the business partners who are involved in a business interaction.
  • ebXML. Electronic Business XML Initiative (ebXML) is an international initiative developed by the United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS). ebXML aims to standardize XML business specifications. ebXML defines a standard that worldwide business organizations can use to exchange data in an XML format.

Figure shows how the standards fit into the Java service model.

Standards that the Java Service Model Uses

Standards that the Java Service Model Uses

Life Cycle of Web Services in the Java Service Model

The life cycle of Java Web services is the same as that of .NET Web services. Therefore, we will just summarize the stages in the life cycle of Java Web services.

Following is the life cycle of Java Web services in relation to the roles in the Java service model:

  1. Develop the Web service by using the J2EE framework or various Java APIs for XML. Developing the Web services involves creating the interface for the Web service and writing the business logic of the application. This step is performed at the service endpoint.
  2. Describe the Web service by using WSDL. This step involves creating the WSDL document that contains a description of the Web service. This step is also performed at the service endpoint.
  3. Register the Web service with the service registry.
  4. Discover the Web service by looking for the required application in the service registry. The service requestor role performs this step.
  5. Send a request for the required Web service to the service provider role. The request is in the form of a SOAP message.
  6. Process the request and send a response in the form of a SOAP message back to the client application.

Figure shows the life cycle of Java Web services.

Life Cycle of Java Web Services

Life Cycle of Java Web Services

Working of the Java Service Model

To understand the role of the Web service standards in the Java service model, you need to understand the working of the Java service model. In this model, a client application, usually a Java application, sends a request for a Web service. The data that is transferred between the applications is in the XML format. As a result, you use the APIs provided in the Java service model to work with this XML data. The APIs allow you to access any Web method that a Web service exposes. This request that a client application sends is then converted to a SOAP message by using a SOAP serializer.

As discussed, SOAP generally uses HTTP as the transfer protocol. Therefore, the SOAP message needs to be converted in the form of an HTTP request. This is performed by an HTTP encoder. Then, the HTTP request is sent over the network to the Web server that hosts the Java Web service.

At the Web server end, a servlet receives the request and then forwards it to the HTTP decoder, which decodes the request back to the XML format. Then the XML request is read by an Enterprise Java Bean (EJB) component, which performs the required processing of the request. Then, again at the server end, a SOAP encoder creates the response of the request and converts it back to the SOAP message.

Next, to transfer the response, the EJB component sends the response over the HTTP protocol. Finally, at the client end, the HTTP decoders decode the HTTP response to the SOAP message, which is further deserialized to an XML message. The entire working of a Java service model is shown in Figure.

Working of the Java Service Model

Working of the Java Service Model

Value Chain of the Java Service Model

Based on the service roles and the steps in the life cycle of the Java Web services, the Java service model defines a value chain for the Java Web services. This value chain is described in the following bulleted list:

  • Standards body. A standards body is a group of organizations that defines the standards of Web services, such as SOAP, UDDI, and WSDL. The standards body includes the consortium, such as W3C, RosettaNet, and so on.
  • Framework. Frameworks comprise the organizations that provide a framework for developing the Web services based on the Web service standards. These organizations involve Sun Microsystems, Inc., Microsoft, Inc., IBM, and so on.
  • Vendors. Due to the increase in popularity of Web services, several small and large vendors in the IT industry provide tools or products that you can use to automate stages in the creation of Web services. The common vendors such as Sun Microsystems, Inc., Microsoft, Inc., and IBM provide toolkits for this purpose.
  • Web Services Developers (WSDs). WSDs are the programmers who create the Web services, their interface, and their business logic.
  • Web Services Marketers (WSMs). As the name suggests, WSMs are the individuals or the business organizations that promote or market a Web service. With the increasing participation of Web services in the e-business, the WSMs contribute by bringing in money for the WSD organizations. To do this, they create a demand for Web services in the market.
  • Note?/td>For a Web service, a WSD and a WSM can be the same person or the same organization.

  • Web Services Providers (WSPs). WSPs host the Web services. They help any client access a required Web service.
  • Web Services Consumers (WSCs). WSCs are the ultimate users of a Web service. They are the beneficiaries who profit from the functionality of a Web service. They form the most important component of the value chain because they bring in the economy for a Web service.

The value chain for a Web service in the Java service model is illustrated in Figure.

Value Chain for a Web Service in the Java Service Model

Value Chain for a Web Service in the Java Service Model

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

XML Topics