Distributed Systems notes-web Service design patterns__distributed

CMU 95702 Distributed Systems notes. A brief introduction to XML-RPC, SOAP, REST Three Web service implementations and RPC, message, Resource three kinds of patterns.
Web Service Implementation Scenarios

There are three major Web services implementations, because XML-RPC is gradually replaced by soap, so it can be said that the mainstream Web services implementation is only REST and SOAP two kinds. REST: Characterizing state transitions (representational states Transfer SOAP: Simple Object Access Protocol (easy access Protocol) XML-RPC: Remote Procedure Call (Sqlremote Procedure Call,rpc) XML-RPC

XML-RPC is a distributed computing protocol for Remote Procedure calls (Sqlremote procedure Call,rpc), which encapsulates the function by using the HTTP protocol, and uses it as a transport mechanism. Later, with new features being introduced, the standard slowly evolved into today's SOAP protocol. The XML-RPC agreement is a registered patent project. XML-RPC sends an HTTP request to a server that has this protocol installed. The client that makes the request is generally the software that requires a call to the remote system.

eg. Long-lived image
If you need to often upload large pictures to the front, then you can set the picture Cache-control larger, such as 30 days, if you need to update the picture, then upload a new picture to the new URI, and then change the HTML, point to the new URI.

Html

1

Server

1 2 3 4 5

http/1.1 Ok date:thu Aug 2008 23:26:31 GMT Server:apache content-length:50753 cache-control:max-age=259200

Html

1

</pre>

SOAP

SOAP (Simple Object Access Protocol) is a complete solution for implementing WEB services.

The Web Service Description Language (WSDL) in a soap-way Web service together with Simple Object Access Protocol (SOAP) constitutes the structural unit of a Web service in SOAP mode. The client understands through WSDL that the Web service exposes the methods that can be executed and the format of the message that the Web service can send or receive (resolves the issue of how to advertise access to resources). The client serializes the information required by SOAP to invoke the service on the remote system to the message (resolving the problem of how to invoke the remote method). Note that WSDL describes the services and the SOAP messages are both compliant and machine readable.

WSDL is based on an XML format used to describe WEB services. A WSDL document can be viewed as a pact between the client and the server. With the WSDL tool, you can automate the process by allowing applications to integrate new services with little or no manual coding. WSDL is therefore the foundation of a WEB services architecture because it provides a common language for describing services and consolidating platforms for these services.

SOAP itself provides a way to exchange information with WEB services. SOAP is the standard way to serialize the information needed to call services on a remote system, which can be sent over the network to a remote system in a format that is readable by a remote system, regardless of the platform on which the remote system is running or the language in which it is written. SOAP provides a simple, lightweight mechanism for exchanging structured and type information in a decentralized or distributed environment in XML format. In fact, it defines a simple mechanism for representing application semantics by providing a package model with standard components and a mechanism for encoding data in the module.

Using a simple example of soap usage, a SOAP message can be sent to a Web site with Web Service functionality, for example, a database containing information about the price of a room, and the message's parameters indicate that this is a query message, and this site returns an XML-formatted message containing The query results (price, position, feature, or other information). Since data is passed in a standardized, analytical structure, it can be used directly by Third-party sites. REST

Representational State Transfer (representional states Transfer) is a software architecture style that Dr Roy Fielding (one of the main authors of the HTTP specification) presented in his doctoral dissertation in 2000. It is not a standard, but rather a principle that describes the transmission state by means of representations (representional). Its purpose is to look at the entire network from the perspective of resources, and the resources distributed around it are determined by the URI, and the application of the client obtains the token of the resource through the URI. Obtaining these representations has led these applications to change their state. With the constant acquisition of resources, client applications are constantly changing their state.

There are no WSDL-like things in REST that describe a list of resources (services) and resource metadata. So we need other strategies to implement the "Advertise Access resource Approach" problem instead of WSDL.

Because there is no authoritative protocol similar to SOAP as a specification, the rest implementations of each Web site have a set of different implementations that are significantly higher in performance and usability than the Web service for SOAP releases, but there are too many areas of detail that are not bound, Its unified general aspect is far less than SOAP.

For example: Suppose a organization, B organizations all implement the RESTful API to query personnel information through the work number, because there is no uniform specification.

A's API might be this:

1	http://A/api/person/001

The API for B may be this:

1	http://A/api/person/id=001

Third-party clients must consider the differences between these APIs when implementing remote calls, and view the A,b API documentation separately.

If an authoritative protocol is used as a guideline, and the API should be implemented as follows, then a Third-party client can simply invoke the remote API in accordance with this standard instead of looking at the A,b API documentation:

1	HTTP://A/API/PERSON/{001}

And OData is such an authoritative protocol for the design and use of the Restful API. OData defines some standard rules (like an interface that defines a bunch of methods) and implements these Standard rules when implementing the Restful API (just as implementing an interface must implement all its methods). Third parties can access the Restful API according to the rules defined by the Odata protocol. characteristic

Resources URI
One of the important principles of REST is addressability, where each resource has a URI. The format is scheme://host:port/path?querystring#fragment. Scheme can be HTTP, FTP, HTTPS, and so on. Uniform Interface
Methods, use several methods of HTTP to manipulate resources.
Representation provides a variety of formats to represent web pages, such as XML, JSON, and so on. HTTP uses the Content-type header to define the format.

Protocol Client-server
Customers and servers communicate with each other through a unified interface. Stateless
Each request is independent, and the client needs to provide enough information each time it is sent, and the server does not keep any state of the customer. Cacheable
REST systems can cache requests appropriately, minimizing information transfer between servers and clients to improve performance layered (intermediaries)
The client does not fix a server

Supplemental to HTTP method: Get-safe, idempotent, cacheable put-idempotent delete-idempotent head-safe, idempotent POST

Cacheable:response can be cached
Idempotent: This operation can be performed several times
Safe: This operation has no side effects (does not affect other operations) HATEOAS

Another major part of REST is HATEOAS. Hateos in Chinese explanation is hypertext as the engine of state transfer , which is an example of late binding. The user initiates an HTTP GET request to the resource by entering the URL in the browser, and the server returns response, which contains information about where you should go next in this response, and you can find references to other resources in this response: links, pictures, scripts, and so on. That is, a typical rest service does not require additional documentation to identify which URL accesses a particular type of resource, but rather the response returned by the server to indicate what action can be performed on that resource. The client of a rest service also does not need to know any information about where the resource is.

For example, a client might receive a reference to the primary restful service that we described above for the reporting service:

http://company1.com/report/

If a request is made through a browser, an HTML document containing the following references may be returned:

Http://company1.com/report/sales

Users can click into and find a list of years to browse. The explanation is that the browser has no particular knowledge of the structure of the URL, but it knows how to parse the results and return the content with the results that the user can browse.

The same is true for other MIME types, such as requesting quarterly reports in XML format for 2009 years:

Http://company1.com/reports/sales/2009/qtr

May be:

1 2 3 4 5 6

<reports> <description>2009 quarterly reports</description> <report name= "A-quarter" src= "Http://company1.com/reports/sales/2009/qtr/1"/> <report name= "Second Quarter" src= Reports/sales/2009/qtr/2 "/> <report name= third quarter" src= "HTTP://COMPANY1.COM/REPORTS/SALES/2009/QTR/3" > </reports>

You can think of a URL as a vector that runs through the information space. Each level further points you to the ultimate resource. Different paths may produce the same result. The client needs to know how to analyze these results, but by giving the response a recognizable type, we can trigger the appropriate parser. This structure can be crawled in descending order from the crawler, or it may be displayed to the user in some kind of interface. A RESTful interface becomes a way for clients to request information based on known. They start with a known or discovered point, just like you browse the Web to browse through the information.

This is what HATEOS is referring to. The state of the application is shifted and found in the hypertext response. Just as browsers need to know about HTML, pictures, sound files, and so on, a restful client also needs to know how to parse the results of a resource reference. However, the whole process is simple, constrained, scalable, and flexible-which is exactly the nature of the network software system that we expect.

Many people build "RESTful" systems that require the client to know the meaning of each level of the URL in advance. If the service side reorganizes the information, the clients of these systems will crash. The client that truly embodies the hateos is more loosely coupled than the server they are communicating with.

More meetings to the resource architecture: the other side of rest linked Services pattern

Is the core of HATEOAS. Publish only part of the root Web services address and return the address of the relevant service in each response, allowing the client to discover the URI after this response.

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. Network Performance

Client-> service side.

Client-proxy-gateways-origin Server

REST of the advantage. Efficiency
Caching can improve efficiency without the need to reach gateways and Origin Server;data control means we can compress data to improve efficiency. Scalability
Caching: Reasons ditto.
Stateless: If the server records user-related states, then the user-related state of the cluster expansion should be synchronized among the servers in the cluster in a timely manner, and synchronization of the user's state would be a tricky one, and when the relevant state of a user has changed on a server, when, Under what circumstances are these states synchronized. If the state synchronization is synchronized, refreshing the user state on multiple servers at the same time will cause the processing of user requests to become unusually slow. If the synchronization is asynchronous, the other server may not be able to properly process the user's request because the user's state is not synchronized because of the next request being sent by the user. In addition, if the cluster is scaled horizontally, the synchronization of the user's state needs to be done.
Different gateways, it is very convenient to increase intermediaries. User Perceived performance
Implemented by reduce media types, caching, and so on. simplicity/evolvability/extensibility/customizability/configuration/reusability/visibility/portability/ simple comparison of three schemes of reliability

XML-RPC has slowly been replaced by soap, and it is now rarely used, but it is still copyrighted. Maturity: SOAP is superior to rest efficiency and ease of use in maturity: Rest wins better security: SOAP security is higher than rest because rest is more concerned with efficiency and performance issues

Overall, because the rest-mode Web services are significantly simpler than complex SOAP and XML-RPC comparisons, more and more Web services are being designed and implemented in restful style. For example, Amazon.com provides near-rest-style Web services for book lookups, and Yahoo offers Web services that are restful. REST is appropriate for resource-oriented service interfaces, and is particularly suited for scenarios where efficiency requirements are high, but security requirements are not high. And the maturity of SOAP can give the need to provide for the development of languages, for the security requirements of the interface design more convenient. So I think that the pure design pattern will occupy the dominant position does not have any significance, the key or to see the application scene, it is the old saying: suitable is the best

At the same time, it's important not to twist the rest. Now many sites have followed the development of rest-style interface, in fact, are learning its shape, do not know its heart, and finally made nondescript, performance does not go, security and guarantee, there is a seemingly like a sample of the skin.

Three major Web services implementations (REST+SOAP+XML-RPC) Overview and comparison API styles RPC

RPC refers to remote procedure calls, that is, two servers A, B, an application deployed on a server, want to invoke the function/method provided on B server, need to express the calling semantics and convey the data of the call over the network.

The message at this time includes procedure name and parameter List,service descriptor is usually WSDL and xsdl or non-xml approach (JSON-RPC), which is used to generate a Service connector (proxy) on the client.

Framework:soap, Jax-ws (Java), WCF (Microsoft)

The RPC model is tightly copuled system, and if the parameter list changes, then the client will break. If the descriptor changes, then the connector must be regenerated to connect to the client.

Request/response is the default mode for RPC, Request/acknowlege will less coupled (seperation of concerns), which can wait in the queue before processing, which can improve Scalability. If the client does not want to wait for block, then you can use asynchronous response handler. Why

Invoking processes/methods on other machines via HTTP
Why RPC? Is the need not to be done within a process, or even within a computer, by local invocation, such as communication between different systems, or even between different organizations. Because computing power needs to be scaled horizontally, applications need to be deployed on a cluster of multiple machines.

RPC has many protocols, such as the RPC style of the earliest Corba,java rmi,web service, the Hessian,thrift, and even the Rest API.

Communication details
The service consumer (client) invokes the service in a local invocation, and the client stub is responsible for assembling the method, parameter, etc. into a message body capable of transmitting the network, after receiving the call; the server stub decodes the message; Invokes the local service based on the decoding result; the local service executes and returns the result to the server stub, which packages the returned results to a message and sends it to the consumer; The client stub receives the message and decodes it; the service consumer gets the final result.

The goal of RPC is to 2~8 these steps and let the user be transparent about the details. Message

Send command commands, notifications, and other information to other machines via HTTP, without having to direct coupling with other processes, or to know the signature of the method of the other machine. The message contains only one parameter.

The message at this time does not include procedure name and parameter List,service descriptor is usually WSDL and xsdl, which is to generate a service connector (proxy), servi The main task of CE is to distribute, to require service to be smarter, to evaluate message content and to decide which process to call which method to execute.

Response includes the address (URL) of the associated service.
Framework:soap, Ws-policy, ws-security

The default is Request/acknowledge mode rather than request/response.
It is simple to append a new message type. Resource

Manipulate the data on another machine without having to direct coupling with other processes, minimizing the need for domain specific API ' s.
The message content is an HTTP method, a URI, and a media type.

The Resource API may be Restful.
Request/acknowledge or Request/response.
will generate security risk because the URI is hackable summary

If you want to build a distributed system, high performance (speed) is the most important requirement, then choose which of the following options. REST sytle Web Service JAVA RMI SOAP based Web service Javascript using JSON Plain old XML (POX) over HTTP

Choose Java RMI, because Java RMI encodes the message into binary form, reducing conversion time at each terminal. Postel ' s

Finally, add a Postel ' s rule. In short , you are strict with yourself and tolerant to others . "Conservative when sent" is a warning to Web developers that the HTML code should be written as closely as possible to the standards that can be easily interpreted by others (browsers). "Open on reception" basically says that for a Web page that does not follow a fixed standard (such as not following an HTML standard), or one or more errors that appear in a Web site, the browser is still able to parse and render as much as possible. In addition, the browser must be backward compatible is also "open to receive" a typical example, not because everyone uses HTML5 to write a Web browser will no longer support the previous HTML version.

Reference Links:
You should know the principle of RPC
Rest Introduction
Two ways of WebService soap and Rest comparison (turn)
A brief introduction and comparison of three kinds of mainstream Web service implementation schemes (REST+SOAP+XML-RPC)

Original address: http://www.shuang0420.com/2016/11/02/Web-Service-Design-Patterns/