Building SOA portfolio Business Services, part 3rd

Part 3rd: Building a Web service that you can use with rest architectural styles in WebSphere

This article is the third article in this series that discusses how to develop composite applications to support business services. The focus of this article is on the representative state Transfer (representational) architecture style. By using the façade component as a REST-style interface, existing SOAP-styled Web services support customizable URLs, multiple resource format representations, browser response caching, streaming of large attachments, and the use of HTTP methods to manipulate resources.

Introduction

The representative state (REST) architecture style provides a lower barrier to the use of WEB services. The external interface of a typical REST-style application includes a large number of Uniform resource Identifiers (uniform Resource Identifier,uri) addressable resources and operations such as create, read, update, and delete (CRUD). The advantage of this architectural style is its simplicity.

Developer and writer Paul Prescod defines the REST Web service as "a WEB service that uses the syntax and semantics of the HTTP protocol to provide its functionality entirely as a set of URI addressable resources" (see Resources). The World Wide Web itself can be seen as a REST-style example. The HTTP protocol at the bottom of the WEB uses the Uniform Resource Locator uniform Resource Locator,url) to represent resources and some widely used HTTP methods, such as GET, POST, put, head, and DELETE for manipulating resources. This simple architectural style provides scalability and interactivity by reusing the Web's loosely coupled and distributed infrastructure.

This article gives an example of a banking business service that publishes loan rates to an aggregator Web site similar to Bankrate (see Resources). Aggregator Web sites typically gather information from a number of different providers and aggregate them into client mashups. This is also known as a transparent combination that can be treated as a composite application. To facilitate the creation of such mashups, service providers need to expose a simplified interface. The REST architecture style is a good fit for this requirement.

This article recommends using a façade component to provide a restful interface to an existing SOAP-style Web service. This article describes the functionality required by the components and captures them in the RATIONAL®SOFTWARE Architect Reusable Asset specification (reusable Asset Specification,ras) pattern. This mode is parameterized by the operations of the endpoint and the existing Web service. You can convert this mode to a deployable java™2 Enterprise Edition (EE) Servlet implementation to invoke an existing WEB service. This generated Servlet supports the required REST style features, such as browser caching, resource content format negotiation, and HTTP streaming of large attachments using the SOAP attachment for Java (SAAJ) standard.

Features required by the REST-style façade component

The following features are required in the REST-style WEB services façade component:

Customizable URLs for resources that indicate the rest style the rest architecture style supports the use of URLs to provide access to fine-grained resources. For example, in a loan application, a bank's lending rate on a specific date is a necessary resource. By using a different URL to represent each fine-grained resource, you can allow other applications, such as e-mail, to easily reference these resources. This also supports the use of WEB 2.0 technologies, such as AJAX, for client resource combinations. Therefore, the WEB service Façade component allows application developers to customize the URL that represents the resource.

HTTP methods for manipulating resources, such as GET, POST, DELETE, put, TRACE, and OPTIONS. RESTful WEB services allow you to access resources through a small number of commonly used operations, such as obtaining representations of resources, obtaining information about resources, and individual operations for manipulating resources. The HTTP protocol has defined such a set of operations (get, POST, put, and so on). (For more information on HTTP methods, see resources.) The façade component supports the use of these HTTP methods. Note that the Web Services Description Language (Web Service Description LANGUAGE,WSDL) 1.1 for the SOAP Web service supports only the HTTP POST method. WSDL 2.0 complements this by including support for HTTP get bindings, but WSDL 2.0 is not yet supported in Websphere®application Server V6.1. Also note that the HTTP DELETE, put, TRACE, and OPTIONS methods are not used frequently and are often blocked by firewalls.

Each resource accessed by the resource representation and the content format negotiation URL can be expressed in a different form, depending on the client accessing the resource. The client can be an HTML browser or other SOAP Web service or Ajax or JavaScript Object notation (JSON) client on a desktop computer (see Resources). The façade component queries the Accept Header field of the HTTP request to determine the response format that the client needs, and then provides the resources in the format that is required.

The results of the browser and gateway agent caching the REST style in resource representations are most often used to access resources using the HTTP get method. For HTTP GET requests, the RESTful Web service can set the HTTP response Header field to provide instructions to determine whether the Web browser caches the returned resource representation and how long it is cached, and what the valid or invalid policy is for the resource representation to be cached. By supporting response caching, you can increase the scalability of your application. The façade component accordingly sets the HTTP Header cache-control response instructions to public, PRIVATE, and so on.

A Web service that uses SAAJ to invoke a soap-styled Web service SOAP style returns the response in XML, which is typically the resource representation required by the REST-style client. Therefore, the façade component avoids unnecessary marshaling overhead due to direct access to XML-formatted SOAP response messages. To do this, the façade component uses SAAJ to invoke an existing WEB service. SAAJ can also use HTTP to stream large amounts of data from the attachments in the Web service response.

The RAS pattern for the REST-style Web service façade

In short, the RAS pattern is a reusable asset that describes a solution to a recurring problem in a given context (see the Resources section, which provides links to the IBM pattern Solution Web site). You can use tools such as IBM Rational Software Architect (RSA) to capture patterns to automate solution development efforts. The following sections describe the RAS pattern to capture the required functionality of the REST-style Web service façade.

Download and install mode

See the Downloads section, which provides a REST mode and a conversion plug-in packaged as reusable assets. Install this asset into RSA by following these steps: