WebService:In the 90 's, popular distributed technology, such as Dcom,corba,rmi, the paradigm is RPC, but the system data types are inconsistent, the implementation/invocation mechanism is different, the interoperability between the systems is not possible. The advent of XML makes the data type consistent, and the advent of soap makes it possible for systems to call each other. Simple Object Access protocol is intended to be xml-rpc, but people quickly find that method calls are too narrow and message passing is more generic. WSDL supports rpc/encoded also supports document/literal, but the former has become a legacy of history.
WebServices is the incarnation of SOA, and the webservices of RPC mode is the legacy of history.
Rest is the incarnation of Roa. (I'm not familiar with that)
RMI CORBA DCOM
XML-RPC Soap WSDL
The Dcom,sun of Microsoft's RMI, JMS, and OMG CORBA
Rmi:romote method Invocation, remote methods call. JRMP communication based on Java Remote Message Exchange protocol; JRMP is a protocol designed for Java remote objects. is a 100%java solution for distributed applications. RMI has insufficient support for non-Java language applications and cannot interoperate.
RMI is an object-oriented programming model. Widely used in the EJB architecture system.
RMI is based on the invocation of the pattern, the calling process is as follows: The client program calls the client agent of the service object, the agent is responsible for packaging parameters and sent to the server via the JRMP protocol, the server uses the same protocol resolution, performs the business logic processing, and returns the result to the client using the same method.
RPC:RPC is a general designation of these categories (which is somewhat inaccurate, but can be understood). RPC (remote Procedure Call) is a technology for distributed computing. Carry information data on some kind of transport protocol (TCP\HTTP, etc.) and request service from a remote computer program over the network. In the OSI model, RPC spans the transport and application tiers, making it easy to develop distributed applications on the network. The client code calls the remote method as if it were a local method.
RPC is based on the request answering mode, the client sends the call information (the remote method name, parameters are packaged into the request information) to the service side, the server resolves to the object to be called and the method executes after the execution of the response information, the client accepts the corresponding fetch reply information.
RPC is a cross-language communication standard, both sun and Microsoft have their implementations, and Microsoft's DCOM is built on the ORPC protocol.
RPC is a process-oriented programming model.
Xml-rpc:xml remote Procedure Call, the XML remoting method invocation, makes RPC calls with the Http+xml encapsulation. Based on HTTP protocol transmission, XML as the information encoding format. A XML-RPC message is a http-post request with the request body as XML, which is also returned in XML format after the server executes. This standard has evolved into the following SOAP protocol. You can understand that soap is an advanced version of XML-RPC.
Soap:simple Object Access Protocol is a lightweight, simple, XML-based remote access protocol. Can be used in conjunction with a variety of existing transport or application layer protocols, such as TCP, HTTP, SMTP, and so on. SOAP is widely used in HTTP and XML protocol-based implementations (Soap=rpc+http+xml), which is a common communication protocol used by Web service users. A SOAP method can be simply considered an HTTP request and response that follows a SOAP encoding rule.
Comparison: XML-RPC is the easiest way to start a Web service and is much easier to use than soap in many ways, but unlike soap, XML-RPC does not have a corresponding service description syntax, which hinders the automatic invocation of XML-RPC services.
Json-rpc:json remote Procedure Call, which is the JSON remoting method invocation. Similar to XML-RPC, the difference is that JSON is used as the information Interchange format.
REST:
Some ' RESTful ' APIs is really just RPC over HTTP
The REST architecture reuses the World Wide Web infrustructure where possible
Xml
Json:javascript Object Notation
Ajax:
Http:get, POST, PUT, DELETE
Url:
Xml-rpc:xml Remote Procedure Call
This remote procedure call uses HTTP as the transport protocol, and XML as the encoding format for transmitting information. The definition of XML-RPC is as simple as possible, but simultaneously capable of transmitting, processing, and returning complex data structures.
XML-RPC is a remote procedure call protocol that works on the Internet. A XML-RPC message is a http-post request with an XML request, and the called method executes on the server side and returns the execution result in XML format.
The main difference between RMI and RPC is how the method is called. In RMI, the remote interface enables each remote method to have a method signature. If a method executes on the server, but no matching signature is added to the remote interface, the new method cannot be called by the RMI client.
Simple description:
How Rpcclient works: Rpcclient locates a command package based on the URL rpcserver, calls a method of a service on Rpcserver, receives the return of the Rpcserver, parses the response packet, and takes out the returned result of the call.
How Rpcserver works: Start a webserver (in the case of a built-in webserver), register each service that you can provide, and enter the service listening state for one handler class, per service.
1. History
First round: HTTP, bringing the Internet and e-commerce
Second round: Java,cross-platform, the earliest RMI
Third round: XML, standard data encapsulation technology, the exchange of data between various apps is no longer difficult.
Fourth round: Rpc,webservice, REST, high-performance communication protocol
2. What is RPC?
Easy to understand: interoperable Web services
RPC (Remote Procedure Call)
– Carrying information data on a transport protocol (TCP\HTTP, etc.), requesting services from a remote computer program over the network
– In the OSI model, RPC spans the transport and application tiers
– based on request response mode
– Cross-language communication standards
Any RPC specification and implementation includes:
– Service layer: RPC Interface definition and implementation
– Protocol layer (protocol): RPC message format and data encoding format
– Transport Layer (transport): implements the underlying communication (e.g. socket)
Application Communication Performance Comparison: Ipc<tcp
3. RPC
Introducing XML-RPC as a representative
Xml-rpc (XML Remote Procedure Call)
– Protocol layer: XML
– Transport Layer: HTTP (many firewalls are also configured to allow only HTTP connections)
A XML-RPC message is a http-post request with the request body as XML, which is also returned in XML format after the server executes.
4. WebService
The WebService platform is a set of standards that define how applications can interoperate on the web. Standards include:
– Methods for describing data: XML
– Protocol For information exchange: SOAP
– Transport protocol: HTTP
– Web Service Description Language: WSDL
– Release registration: UDDI
– Service Specific implementation technology: Java,c,ptyhon ...
SOAP Introduction
– Can be seen as an advanced version of XML-RPC
–soap is a lightweight, simple, XML-based protocol that allows applications to exchange information over HTTP. Or, more simply, SOAP is the protocol used to access the Web service.
– A SOAP request is actually a http-post request
Learn more about the reference "webservice/soap/wsdl explanation"
5. REST
Rest Introduction
– Representational State transfer (representational Transfer)
– New standards for open services in the industry
– Development for resource opening
– Public Directory-structured URI (HTTP://TWITTER.COM/STATUSES/USER/ZHANGXU)
– Return HTTP protocol nature (GET, POST, PUT, DELETE)
6. High-Performance Application communication protocol
The traditional RPC
– Low efficiency, whether it's JSON or XML data transfer
Rmi
– High efficiency, only available in Java
Direct Socket Connection
– Need to develop their own protocols, high cost
Therefore, high-performance communication middleware that needs to be transmitted via binary HTTP, where high performance can be understood as:
– Serialization of objects, high performance of deserialization
– Compression algorithm High performance
– High performance transmission
Often used for inter-enterprise interaction between systems
Common technology
–hessian, thrift, protocol buffer
6.1 Hessian
Hessian is an open source remote communication protocol. The Hessian uses the binary RPC protocol, which is based on the HTTP transmission, and the server does not have open firewall ports. The specification of the Hessian protocol is public and can be used in any language.
Hessian is typically serviced through a Web application, so it is very similar to webservice. It does not use the SOAP protocol and is transmitted in binary.
The process of one call:
The client-to-serialization writes to the output stream--The remote method (server side)--serialization writes to the output stream--the client reads the input stream and outputs the result
6.2 Thrift
Reference article "cross-platform communication middleware Thrift Learning" Java version "
6.3 Protobuf
Protocol buffer is a format for Google's data interchange, which is language independent and platform independent. Google offers implementations in several languages: Java, C + +, and Python, each of which contains compilers and library files for the respective language. Because it is a binary format, it is much faster than using XML for data exchange. It can be used in data communication between distributed applications or in heterogeneous environments.
Protobuf has only one means of serialization and deserialization and does not involve a transport layer
PROTOBUF serialization efficiency the highest in the industry!
What is rest?
Rest, or rest, representational state Transfer, is a design and development approach to network applications that reduces the complexity of development and increases the scalability of the system.
Rest Features:
1. Rest is a design style, not a standard.
2. Rest usually uses popular protocols and standards such as http,uri,xml,html
3. Rest is the view of the network from a resource perspective, and the resource is specified by a URI.
4. The types of operations that rest has on resources typically include: Fetch, create, delete, and modify, and these four operations correspond to the get,post,delete and put methods of the HTTP protocol request, respectively.
5. The expression of a resource can be: Xml,html,json text.
6. Rest is an application approach in the server-to-client fabric.
7. Rest uses the HTTP protocol and is therefore stateless.
Next, let's find out why we want rest. To figure this out, first of all, to understand the development of communication technology between computer software. In the computer communication, the TCP/IP protocol is the most common standard protocol, TCP is the Transmission Control protocol, IP is the Internet protocol, but both protocols are very primitive (raw), the TCP protocol is the Transport Layer protocol, and IP is the network layer protocol. It is true that TCP/IP is capable of passing information from one computer to another. But we all know that the underlying things are often more difficult to understand. Therefore, some application layer protocols are operating, the initial application layer protocol has smtp,pop3,ftp,http, and so on, today, the most use of the day is still these old application protocols. But these protocols are also subject to application conditions.
RMI (remote method Invocation, object-oriented, long-distance methods call)
RPC (Remotely procedure call, remote procedure calls)
SOAP (Simple Object access Protoal)
REST (representational state transfer, express status transfer)
These are understood as some communication technology "styles" that call remote methods.
1.TCP/IP (Socket,rmi)
Earlier, programmers in order to allow the communication between two applications, usually using the socket developed TCP/IP communication program, and all are their own definition of data format specification, the advantages of this model is personalized, usually more efficient, but at the same time because all fragmented, often developed a lot of programs , but each one is different, this is for the lazy programmer, it is really a cup!
RMI is like it is working locally, using the TCP/IP protocol, the client directly invokes some methods on the service side. The advantage is the strong type, the compile time can check the error, the disadvantage is only based on the Java language, the client and the server tightly coupled.
2.RPC
Some programmers began to think that if a method called a remote could be as simple as calling a local method, it would be much simpler, so the RPC mode communication was generated. RPC uses the C/S method, uses the HTTP protocol, sends the request to the server, waits for the server to return the result. This request consists of a set of parameters and a set of text, usually in the form of "Classname.methodname". The advantage is cross-language cross-platform, c-side, s-side has greater independence, the disadvantage is that the object is not supported, the compiler can not check the error, only at run time check.
3.SOAP
Then, in order to standardize, the cross-platform generates the message communication model based on the SOAP protocol. SOAP is based on XML-RPC, which describes the RPC request information (uri/class/method/parameter/return value) using standard XML. Because XML-RPC can only use a limited number of data types and some simple data structures, SOAP can support more types and data structures. The advantages are cross-lingual, well suited for asynchronous communication and for loosely coupled C/s, with the disadvantage of having to do a lot of run-time checks.
4.REST
But with the passage of time and the spread of soap, we quickly found that there is already a most open, most common application protocol in the world, that is HTTP, using SOAP does make interprocess communication easy to use, but not every vendor is willing to upgrade their old system to support soap , and SOAP parsing is not a built-in support for every language, such as JS. and HTTP is perfect to solve this problem, well, let's design a way to use HTTP protocol to complete the service-client communication, rest comes into being.
Rest is generally used to compare with soap, it uses a simple URL to replace an object, the advantages are light weight, good readability, no other class library support, the disadvantage is that the URL may be very long, not easy to parse.
In conclusion, the process of computer communication can be used to illustrate:
Comparison of rest and RPC styles
The schema of the RPC (remote procedure Call) is applied in a Web service based on XML-RPC (or RPC-style) soap. The client issues a command to enable the service to make a specific operation. In other words, RPC has a tendency to verbs.
Rest emphasizes that resources (nouns) have a uniform interface to address them, whereas RPC emphasizes that the process (verb) has a uniform interface to excite them. An RPC-based architecture with no limit to the number of verbs. Rest says that we use four verbs-very familiar, HTTP standard get, POST, put, and delete--to make requests and responses, and rest uses resource addressing to handle its variability.
Comparison of rest and soap styles
RESTful Web services rely on a simple set of "verbs", http-standard GET, POST, put, and delete, which transfer all the complexities to the "nouns" of a given resource. Compared to the REST architecture, the soap frame composition is significantly different: All SOAP message sending uses the HTTP POST method, and all SOAP message URIs are the same, which is the basic practice characteristic of soap-based WEB services.
In the early days of the development of Web services, the first major use of XML format messages was to apply to the XML-RPC protocol, where RPC represented a remote procedure call. In an XML remote procedure call (XML-RPC), the client sends a specific message that must include the name, the program that runs the service, and the input parameters. Instead, the rest-style request does not care what the running program is, it simply requests a named resource.
XML-RPC can only use a limited number of data types and some simple data structures. It was thought that the deal was not strong enough, so there was soap--. Its initial definition is a Simple Object access protocol. After that, it was gradually realized that soap was not simple, and that there was no need to use object-oriented language, so now people are just using the name soap.
XML-RPC has only a simple set of data types, and instead, SOAP defines data types by leveraging the evolving XML schema. At the same time, soap can take advantage of XML namespaces, which are not needed by XML-RPC. As a result, the beginning of a SOAP message can be any type of XML namespace declaration, at the cost of adding more complexity and incompatibility between the systems.
Also, it is important to note that rest is a request for HTTP, compared to SOAP, which can be transmitted by all the methods that can handle Unicode text, unfortunately, this is not usually recognized by people. The fact is that because HTTP is easy to penetrate through firewalls and developers are familiar with the web, people continue to emphasize HTTP transmissions.
With the awakening of the computer industry, the commercial potential of XML-based Web services has been discovered, and companies are beginning to explore ideas, opinions, arguments, and standardized attempts. The World Expo has tried to organize the results exhibition in the name of "Web service Activity", which also includes the XML Protocol Working Group (XML Protocol Working Group) that actually made soap. The standardized results related to Web services-in part, the number of soap-related or dependent soap---have multiplied to a surprising degree.
A simple example of rest
Suppose we want a Web service to expose a subset of the directories from which users will be able to get descriptions, pictures, installation instructions, and so on. In order to get a description of the number "n1996-01", the user needs to format a GET request, similar to the following URL:
Http://company.com/catalog/description/n1996-01
When the request is processed, "/catalog" is mapped to a service, and then the "description/n1996-01" is interpreted by the service to locate the resource. When you create a response, the service needs to use the header file of the content type (content-type) to specify the return format. In this case, it is assumed that the return format is HTML or XML, which the client can use to control the layout of the page. If a picture is to be obtained, the request will be addressed to "/catalog/picture/n1996-01", and the response returned will be the picture content type (content-type).
Rest-style Web service and Soapweb service selection
Here are three ways to choose between maturity, efficiency and ease of use, and security:
Maturity (overall soap is better than rest in terms of maturity)
Although soap is now out of the original intention, the release and invocation of heterogeneous environment services, as well as vendor support, have reached a mature situation. Different platforms, the development of the language through soap to interact with the Web service can be good interoperability (in some complex and special parameters and return object parsing, the protocol is not very detailed provisions, resulting in the need for partial correction)
Rest many of the big Web sites have published their own development API, many of which provide soap and rest two web Service, according to the survey part of the site's rest style usage is higher than soap. But since rest is just an idea for resource manipulation based on the HTTP protocol, the rest implementations of each Web site have their own set of the rest API styles for each major website. It is also because of this individual implementation that the performance and usability are much higher than the soap-published Web service, but the unified common aspect is far less than soap. Because the SP of these large websites tend to focus on the API development of this website, the generality requirement is not high.
Since there is no authoritative protocol similar to SOAP as a specification, the various protocols that rest implements are only private, and of course need to follow the rest idea, but there are too many areas of detail that are unconstrained. Rest of the future development of the norm will also directly affect the design of this part can have a good vitality.
Efficiency and ease of use (rest wins)
The SOAP protocol defines both the message body and the message header, while the extensibility of the message header provides an extended basis for various Internet standards, and the WS-* series is the more successful specification. However, the performance of soap processing has declined due to the fact that soap constantly expands its own protocol content due to various requirements. There has also been an increase in ease of use and learning costs.
Rest is a big part of people's attention, but also because of its high efficiency and simple and easy-to-use features. This efficiency stems from its resource-oriented interface design and operational abstraction, which simplifies the developer's poor design and maximizes the use of HTTP's initial application protocol design philosophy. At the same time, it seems to me that rest has a very attractive developer is the ability to integrate the current Web2.0 of many front-end technology to improve development efficiency. For example, many large Web sites open the rest-style API will have a variety of return forms, in addition to traditional XML as a data bearer, as well as (Json,rss,atom) and other forms, which for many site front-end developers can be a good mashup of various resource information.
Security:
This can actually be put into maturity, but in the current Internet application and platform development design process, security has been referred to a high degree, especially as an external interface to third-party calls, security may be higher than the business logic itself.
Soap is security controlled by the use of xml-security and xml-signature two specifications ws-security to achieve security control, currently has been supported by various manufacturers,. NET, PHP, Java have already had a good support for it (although there are some incompatibilities in some details, interoperability is basically possible).
Rest does not have any specifications for the security aspects, while the open Rest-style API Web site is mainly divided into two, one is to customize the security information encapsulated in the message (in fact, there is no difference between soap), and the other is to rely on hardware SSL to protect, but this can only guarantee the point-to security, If there is a need for multi-point transmission, SSL can do nothing. Security this is actually a big problem, this year at the BEA summit to see the demonstration using SAML2 implementation of the inter-site SSO, in fact, the direct use of xml-security and xml-signature, efficiency does not look very high. It is unknown whether security in future rest normalization and generalization will be used in both of these specifications, but the more you join, the more benefits rest loses in its efficiency.
Examples of specific choices:
In the developer's mind, rest and soap styles are unique to the development of Web services. SOAP has more detailed standardized results and open source tools. In addition, there are now many integrated development environments that can automatically generate SOAP based on an interface method, on the basis of existing code. If you need to use WSDL to publish your service, or if you need some security features such as message signing and encryption, then soap can ensure the security of the message. Rest, on the other hand, might be the best choice if you want to use simple interfaces to advertise some information without tedious processing.
If the two applications we want to communicate are all of the same architecture, such as. Net application, or both Java application, or if they are other programs that are better for soap, then we recommend using SOAP as a way to communicate. But if the customer of the service has to use the browser to invoke the service, there is the need to use the JS call service, then the best service is best designed to rest style. That is to say, in fact, the openness of rest, universality is better than soap.
WebService restful RPC
