An introduction to JEE / J2EE web services

The idea of web services, applications with components that could be easily exposed for access by various client applications, began to emerge in the late 1990s. In order for the concept of web services to work in the real world, a standardized method of allowing multiple disparate clients to communicate with web service components was needed. For this reason, a defining characteristic of modern web services is at least partial compliance and alignment with certain widely accepted open standards of communication and architecture models.

Early web service standards like CORBA, DCOM and JMI, as well as SOAP 1.1, typically used web service concepts to make remote procedure calls to services, a basic use of web services that often resulted in somewhat tightly coupled connections that did not take full advantage of the web services model. However, as the benefits of web services became apparent and the model began to be used for increasingly complicated projects, the demand for interoperability and flexibility grew and these early protocols were no longer sufficient. After a rocky time of competing frameworks and arguments about approach, two models of web service emerged as the industry standards - SOAP, a refactoring of the original SOAP protocol backed by major technology players with associated specifications and REST, a lightweight, HTTP-based approach based on work done by Roy Fielding, the creator of HTTP, which has no specifications (although certain implementations, such as the ATOM protocol , are used as "canonical" examples of the architecture). These two models can be used to roughly classify a web service as either "SOAP-based" or "REST-based".

"SOAP-based" web services communicate using XML, which is transmitted and interpreted over HTTP using the SOAP standard, either by itself or in conjunction with WSDL, a markup language that provides information about the available methods of interacting with a given service to any applications with which it communicates. In the SOAP model, the task of transaction and transmission of messages is typically handled by the HTTP protocol, with SOAP providing additional functionalities. In a classic SOAP-based interaction pattern, the client asks to use one of the service's exposed functions, initiating a remote procedure call via a SOAP message contained in the body of an HTTP message and receives a response from the service.

The SOAP standard is made up of a stack of components designed for this purpose, including a processing model, extensibility standards, a protocol binding framework and the message construct itself. At this stage of SOAP's development as an open standard, this entire process may be hidden from the developer of a given application. There are many frameworks that implement the SOAP model and make it easier to integrate into various environments, toolsets and application ecosystems.

By contrast, "RESTful" web services utilize the REST model. Using REST, which stands for Representational State Transfer, applications can transmit the information needed to function as web services using only the native functions of a given protocol. In the context of web services, this generally means that RESTful web services communicate via pure HTTP, using XML or JSON (JavaScript Object Notation) to give structure to the messages. This contrasts with the SOAP model, which advocates binding new application-specific methods to HTTP methods (for example, binding a method such as "createUserProfile()" to the standard HTTP "POST" verb). REST accomplishes communication within the constraints of a protocol's native format by focusing on making clients and servers aware of changes to the state of a given resource that is interesting to one or both parties. Thus, requests are only made when one of the parties wishes to transition the resource to a new state. By contrast, SOAP places a higher value on individual messages sent between the client and the server.

Using a protocol's native vocabulary as the communication channel between web services is seen as beneficial for a number of reasons, including the elimination of application-specific learning curves due to arbitrary methods and the ability to use existing protocol-compliant communication layers such as proxies and caching engines to enhance communication between applications as needed, rather than introducing duplicate components to handle these tasks.

Out of these two models of web service architecture, SOAP is by far the more widely adopted approach. SOAP's popularity is due in no small part to backing by major technology companies. By contrast, REST-based web services as a popular model is a fairly new phenomenon, although the model has existed as a concept since the beginning of the HTTP protocol. Using REST to implement web services currently means sacrificing access to the wide array of tools, libraries and resources that have been created around the SOAP standard. Some developers may choose to implement RESTful services specifically for this reason, as they consider REST-based services a lighter-weight alternative to the complexity of the SOAP model.

Starting with J2EE1.4, the Java EE platform has supported the development of traditional, SOAP-based, remote procedure call oriented web services via a component called JAX-RPC.

With the release of Java 6, the Java platform has been updated to provide much more comprehensive support for web services development. This is accomplished via an integrated stack of APIs and tools designed to ease development of both SOAP-based and RESTful web services, which is now a part of the core Java functionalities. Additionally, rather than being specific to the enterprise edition of Java, the new web services stack is included in both Java SE and EE editions.While the stack is the same in both editions, when used with JavaEE, additional components allow services to be defined and exposed within enterprise container-based environments and interact with JMS, JNDI and other JavaEE components.

The Java web services stack is composed of 5 primary components:

• JAX-WS - This is Metro's core component and provides a complete framework for the development of both SOAP-based and RESTful Java web services.
• JAXB - This component assists JAX-WS in processing XML by allowing easy binding of XML schema to standard Java formats.
• WSIT - This component extends JAX-WS to allow Java-based web services to interact with .NET and other WCF components.
• XWS-Security - This framework can be incorporated into a JAX-WS web service to allow the configuration of security policies for requests and responses at multiple levels throughout the service.
• JAX-RPC - This framework is included to provide legacy support for RPC-based services within the Metro stack, as outlined in the defunct SOAP 1.1 specification.

JAX-WS and the rest of the web services components mentioned above are based on a separate project called Metro, which in turn is maintained as a part of Sun's Glassfish project.

While components of the Metro stack have been incorporated into the Java platform, development of Metro itself currently outpaces the development of the platform itself, with new developments usually based around ease of use. Thus, you may want to considering downloading and trying out the newest version of Metro before using the version included with the Java platform.

Additionally, although they are not included as a part of the Java 5 platform, Metro components are currently fully compatible with Java 5 (although anything lower than Java 5 will not work due to lack of annotations support).

Although it is not yet a part of the official stack, the fledgling JAX-RS component, which aims to separate support for RESTful services from the larger JAX-WS as outlined in JSR 311, is also associated with Metro. While JAX-RS is currently not a part of the core Java library, Jersey, the official reference implementation created by Sun as part of the Glassfish project, is considered "production-ready" and includes an API for extensibility.

The Web Service model facilitates a variety of different technologies based on the fact that the functionalities of one application can be easily exposed to another client application, regardless of what language the client is programmed in or how it will use the data. The key characteristics of web services are flexibility, interoperability and transportability, which has found them used in a wide variety ways, including various Web APIs, integration frameworks and architecture models, such as Service oriented architecture.

Service Oriented Architecture represents the most complex application of the benefits of web services to real-world network architecture. Service Oriented Architecture describes an infrastructure in which consists of a group of web services that provide basic building blocks from which applications can be assembled, instead of a group of applications that encapsulate their own implementations of these functions.

For example, in a Service Oriented Architecture, a shopping cart application could be made up of an inventory management service, a number of secure credit card transaction services, a user database service and more, coupled with a graphical front-end that presented all these services in a unified manner to the end user. Note that this is a simple example - in real world situations, most of the clients accessing web services will not be web browsers, but a variety of internal clients without interfaces that are components of other network functions.

The idea behind Service Oriented Architecture is to leverage the capabilities of web services to eliminate duplication of components and enable organizations to quickly construct new applications to meet new business needs as they become apparent, increasing agility and efficiency for the organization.

If you'd like more information about Service Oriented Architecture and how Anypoint Platform can help solve your integration needs in a scalable, cost-efficient manner, check out the article "SOA from the Bottom Up: The best approach to service oriented architecture".

Want to know more about Anypoint Platform?

The MuleSoft development team has released a number of features to the platform, including:

• Mule enterprise security
• High availability
• DataWeave