Web Service and distribution system

Service_Design_Pattern

---

Chapter 1 -- From objects to web services

1. Terminologies

client	server
requestor	Provider
service consumer	service provider

2. The Promise of Loose Coupling

• Function coupling: Clients expect services to consistently produce certain results given certain types of input under particular scenarios.
• Data structure coupling: Clients must understand the data structures that a service receives and returns, the data types used in these structures, and the character encodings (e.g., Unicode) used in messages.
• Temporal coupling: Clients may use the Asynchronous Response Handler pattern to reduce this form of coupling.
• URI coupling: Reduce the client's coupling to the service's URI and location: Linked Service, Service Connector, Registry, and Virtual Service.

3. About SOA

a design paradigm or methodology wherein “business functions” are enumerated as services, organized into logical domains, and somehow managed over their lifetimes.

Chapter 2 -- Web Service API Styles

1. Web Service API Styles

Pattern Name	Descri
RPC API	How can clients execute remote procedures over HTTP?
Message API
Resource API

2. RPC API

Define messages which identify the remote procedures to execute and also include a fixed set of elements that map directly into the parameters of remote procedures. Have the client send the message to a URI designated for the procedure.

The client sends a message to a remote server process and blocks while waiting for a response. The request message identifies the procedure to be executed, and also includes a fixed set of parameters that map directly to the parameters of the remote procedure. When a message arrives at the server, a server process inspects the message, invokes the procedure (i.e. service) whose name is found in the message, and maps the message parameters directly into the service's input arguments. These tasks are usually performed by service frameworks like JAX-WS and WCF. Once the service has been invoked, it processes the client's request and returns a response. The client can then extract the results and resume execution.

- The problem with this type of API is that it is inherently inflexible and fragile. Clients must send procedure arguments in an exact order, and if the need ever arises to add, remove, or reorder parameters, one can’t avoid a breaking change.

- Proxies are typically generated by client-side tools capable of reading Service Descriptors. These artifacts describe how clients may call one or more services. The most common descriptor language for web services is WSDL.

3. Message API

An API style that recognizes a set of related messages, but does not tie those messages to specific procedures.

Define messages which are not derived from the signatures of remote procedures. These messages may carry information on specific topics, tasks to execute, and events. Have the client send the message to a designated URI. Once the message is received at the server, examine its contents to determine the correct procedure to execute.

Message APIs often receive or send standardized message formats like SOAP;

- Message Types from Client:
Command Messages -- to ask the receiving system to carry out a specific task; 
Event Messages -- notify the receiver about interesting events;
Document Messages -- like business documents;

4. Resource API

A client application consumes or manipulates text, images, documents, or other media files managed by a remote system.

Many web services use messages to form their own domain-specific APIs. These messages incorporate common logical commands like Create, Read (i.e. Get), Update, or Delete (CRUD). This approach, however, can lead to a proliferation of messages, even in relatively small problem domains. Consider, for example, a set of services that manages company and contact information. In this scenario, the client developer would have to use eight or more distinct messages, one for each combination of a domain entity (i.e. company or contact) and CRUD operation. An API like this might include messages like "CreateCompany", "GetCompany", and so forth. The service owner would also have to create response messages for the various service outcomes (e.g. "CreateCompanyResponse", "GetCompanyResponse" etc.). Rather than creating a domain-specific API comprised of messages like these, one could leverage the standards defined in the HTTP specification.

Assign all procedures, instances of domain data, and files a Uniform Resource Identifier (URI). Leverage HTTP as a complete application protocol to define standard service behaviors. Exchange information by taking advantage of standardized media types and status codes when possible.

Services that have Resource APIs use the requested URI and HTTP server methods issued by the client along with the submitted or requested media type to determine the client’s intent. These services often adhere to the principles of Representational State Transfer (REST), but not every Resource API can be considered RESTful. A quick review of the REST architectural style is therefore provided, to help you better understand this pattern.

- Clients manipulate the state of these resources through representations. A database table row may, for example, be represented as XHTML, XML, or JSON.

- Methods: 
 • PUT is used to create or update resources.
 • GET is used to retrieve a resource representation.
 • DELETE removes a resource.
 • POST varies! It can be used to create a subordinate of the target resource identified in the client’s request, or for “nonstandard behaviors” where other methods aren’t a good fit. For example, a mutual fund service might accept requests to execute functions like “Exchange Funds”, “Sell X Shares”, and “Sell Dollar Amount” through POST. This method can also be used as a workaround when PUT and DELETE are disabled on the web server or blocked at the firewall. In this situation, the behaviors that would normally be carried out by other methods are tunneled through POST. Many REST advocates argue against tunneling through POST since it tends to obfuscate the purpose of the request. POSTed requests also can’t be cached by intermediaries.
 • The OPTIONS verb may be used to discover what HTTP methods are supported at the target URI.
 • HEAD is used to acquire metadata about the media types exchanged at a URI. It is similar to GET except that a representation is not returned.
 • While the core methods are static, extensions to HTTP have been added (e.g., WebDAV).

Chapter 3 -- Client-Service Interactions

1. Client-Service Interaction Patterns

Pattern Name	Description
Request/Response	Process requests when they're received and return results over the same client connection.
Request/Ackonwledge	When a service receives a request, forward it to a background process, then return an acknowledgment containing a unique request identifier
Media Type Negotiation	Allow clients to indicate one or more media type preferences in HTTP request headers. Send requests to services capable of producing responses in the desired format.
Linked Service	Only publish the addresses of a few root web services. Include the addresses of related services in each response. Let clients parse responses to discover subsequent service URIs.

Chapter 4 -- Request and Response Management

1 Overview

Common entities used to manage web requests and responses. These patterns seek to decouple clients from the underlying systems used by the service. Developers may select zero, one, or more of these patterns when designing a given service.

Presentation Layer: contains logic that displays information and receives user
input.
Domain Layer: in turn, calls upon the entities in the Data Source Layer, to read and write information to databases or other data stores (e.g., files, messaging systems, etc.).
Service Layer: can be used to create a distinct API for multiple client types. This API establishes a clear boundary between client applications and the logic for a specific domain.

Pattern	Description
Service Controller	Create a class that identifies a set of related services. Annotate each class method with routing expressions that can be interpreted by a Front Controller.
Data Transfer Object	Create distinct classes to represent request and response data structures. Consolidate the mapping logic that reads and writes these structures.
Request Mapper	Create specialized classes that leverage structure-specific APIs to target and move select portions of requests directly to domain layer entities or to a common set of intermediate objects that can be used as input arguments to such entities. Load a particular mapper based on key content found in the request.
Response Mapper	Create a class that consolidates the data mapping and transformation logic used to create a response.

2 Service Controller

All web services are dependent on mechanisms that receive requests, evaluate the request's meaning, and route requests to procedures (i.e. class methods, request handlers) which implement the service behaviors. Service designers may centralize this logic in a Front Controller. This pattern works quite well if the correct service can be selected by simply parsing the requested URI. Unfortunately, this is not always the case. The routing logic can become much more complex if the service must be selected based on the client's preferred media types, message header values, or message body content. Developers could benefit from a simple declarative approach that can be interpreted by a Front Controller.

Service Controllers are classes that contain one or more public methods (a.k.a. Request Handlers, Web Methods) that control the execution of business tasks and coordinate access to resources (e.g. files, documents, images, etc). The rules that define which handlers should be invoked for different requests are provided through annotations known collectively as Routing Expressions. These expressions typically precede each web method in the Service Controller, and are interpreted by the Front Controller of frameworks like JAX-WS, JAX-RS, Axis2, and WCF. When a web server receives a request, the framework selects and invokes the appropriate handler by evaluating various aspects of the request against these expressions. The types of Routing Expressions used in the Service Controller depends on the Service API style. Frameworks that support Resource APIs employ URI Templates, Request Method Designators, and Media Type Annotations. Frameworks that support RPC and Message APIs often use annotations that evaluate SOAPAction or WS-Addressing Action headers.