Hello. In this video, we will examine the web services that are supported in Java 6 EE. Let's get started. Web services are client and server applications that communicate over the Worldwide Web's hypertext transfer protocol, also known as HTTP protocol. As described by the World Wide Web consortium, also known as W3C, Web services provide a standard means of inter operating between different software applications running on a variety of platforms and frameworks. Web services are characterized by their great interoperability and extensibility as well as their machine processable descriptions, thanks to the use of XML. They can be combined in a loosely coupled way to achieve complex operations. Programs providing simple services can interact with each other to deliver sophisticated added-value services. On the conceptual level, a service is a software component provided through a network-accessible endpoint.

The service consumer and provider use messages to exchange invocation request and response information in the form of self-containing documents, that make very few assumptions about the technological capabilities of the receiver. On a technical level, web services can be implemented in different ways. There are two types of web services that can be distinguished as Big web services and RESTful web services. In Java EE 6, JAX-WS provides the functionality for big web services. Big web services use XML messages that follow the Simple Object Access Protocol (SOAP) standard, which is an XML language defining a message architecture and message formats. In such systems, there is often a machine-readable description of the operations offered by the service written in the WSDL, which is an XML language for defining interfaces syntactically.

The SOAP message format in the WSDL interface definition language have gained widespread adoption, and there are many development tools available, such as net beans, IDE or Eclipse, that reduce the complexity of developing web service applications. A SOAP based design must include some elements. Let's look at what these are. A formal contract must be established to describe the interface that the web service offers. The WSDL can be used to describe the details of the contract, which may include messages, operations, bindings, and the location of the web service. You may also process SOAP messages in a JAX-WS service without publishing a WSDL. The architecture must address complex non-functional requirements. Many web service specifications address such requirements and establish a common vocabulary for them. Examples include; transactions, security, addressing, trust, coordination and so on. The architecture needs to handle asynchronous processing and invocation.

In such cases, the infrastructure provided by standards such as WSRM and APIs such as JAX-WS with their client side asynchronous invocation support can be leveraged out of the box. In Java EE 6, JAX-RS provides the functionality for representational state transfer RESTful web services. REST is well suited for basic ad hoc integration scenarios. RESTful web services are often better integrated with HTTP than SOAP based services are. They do not require XML messages or WSDL Service API definitions. Project Jersey is the production ready reference implementations for JSR 311, JAX-RS, the Java API for RESTful Web services. Jersey implements support for the annotations defined in JSR 311, making it easy for developers to build RESTful web services with Java and Java JVM.

Jersey also adds additional features not specified by the JSR. Because RESTful web services use existing well known W3C and IETF standards and have a lightweight infrastructure that allows services to be built with minimal tooling, developing RESTful web services is inexpensive, and thus has a very low barrier for adoption. You can use one of the development tools, such as Net Beans IDE or Eclipse IDE. To further reduce the complexity of developing RESTful web services, a RESTful design may be appropriate when the following conditions are met. The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server. A cashing infrastructure can be leveraged for performance. If the data that the web service returns is not dynamically generated and can be cache, then the cacheing infrastructure that web servers and other intermediaries inherently provide can be leveraged to improve performance. However, the developer must take care because such caches are limited to the HTTP get method for most servers.

The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged, and on ways to process it meaningfully. In the real world, most commercial applications that expose services as RESTful implementations also distribute so-called value-added tool kits that describe the interfaces to developers in popular programming languages. Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited profile devices such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted. Web service delivery or aggregation into existing websites can be enabled easily with a RESTful style.

Developers can use technologies such as JAX-RS, Ajax and tool kits such as direct web promoting as DWR to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing website architecture. Existing developers will be more productive because they are adding to something they are already familiar with rather than having to start from scratch with new technology. Let's have a little break now. In the next lesson, we will examine the packaging in Java EE. See you in the following lesson.