TCP/IP, HTTP, WebService, soap, and ice are all used.

TCP is the layer-3 Transport Layer of TCP/IP, corresponding to the layer-4 Transport Layer of OSI;
IP is the Layer 2 Interconnection layer of TCP/IP, corresponding to the Layer 3 network layer of OSI.

 

Internet communications engine (ICE) is a high-performance middleware provided by zeroc. It can implement telecom-level solutions based on ice. As mentioned above, when designing a website architecture, you can use ice to perform basic object operations on website applications and encapsulate basic object operations and database operations on this layer, in the business logic layer and the presentation layer (Java, PHP ,. net, Python) to implement a better architecture. The ice-based data layer can be easily expanded in the future. Ice supports distributed deployment management, message-oriented middleware, and grid computing.

After talking about the truth, let's get down to the truth. Recently, children's network has added many new services, and services often need to call data from each other. For example, the user center needs to retrieve the data from the blog system.ArticleAh, you need to add user points in the points system after posting in the Forum. Because these services are designed only based on a unified user center, services are basically independent, therefore, to implement these calls, you can only add the service-_-on each service to provide services for other services -_-!. There are several optional solutions at this time. We started to select XML-RPC and HTTP-and XML-based process selection calls. After a while, we found that there were problems in both maintenance costs and access performance.

Because these intermediate services are deployed together with their respective services, it is very difficult to make overall changes to these services and it is difficult to maintain them. In addition, because HTTP and XML are used as communication protocols and PHP is used to implement business logic, performance problems are also obvious, and these HTTP requests will leave a footprint in the HTTP log, this results in inaccurate log analysis. This is not a big problem, but it is very depressing. Therefore, we consider using ice to solve this problem. We will not consider soap or anything, and the efficiency is also low.

The implementation process is still relatively smooth. It took three days to use C ++ to implement most of the commonly used interfaces. The server runs in deamon mode, the error log is recorded in syslog (/var/log/messages). The PHP client is compiled into icephp, and the call method is very simple. There are still some problems. It may take some time to solve the problem. A dog is added for the moment and a restart is started once the process is gone.

Since cross-platform communication involves object descriptions, ice uses slice to define structures, classes, and methods. After this is done, the client calls and implements this method. Ice's built-in deamon implementation solution in the Linux background is very simple. You only need to derive a class from ice: service to implement the run method, and create the adapter object in this method, add servants to the adapter object, and then activate the adapter. The network layer communication is taken over by ice. Because it is based on TCP/IP direct communication, it is much more efficient than the higher-level HTTP Communication.

We also encountered some minor problems when implementing the client. A built-in $ ice object sometimes needs to be declared using global statements; otherwise, an error may occur. In addition, the struct in slice corresponds to the PHP type as a class instance by default, instead of an array, smarttemplate and other template systems may have problems when assigning values to pages. You can modify the values of the template system to display values.CodeSolution.

We did some performance tests, and it also took about 28 seconds to run 1 thousand requests using XML-RPC and more than 3 seconds to implement using ice, the performance gap is still very large. At the same time, no memory leakage is found in this process, and the effect is quite satisfactory.
//////////////////

The SOAP protocol followed by WebService is based on the HTTP protocol.

Simple Object Access Protocol (SOAP) is a note organized by W3C. It describes a lightweight protocol for exchanging information in a distributed or distributed environment. Soap is an XML-based protocol. It consists of three parts: Soap encapsulation (envelop), which defines a description of the content in a message and who sent the message, framework for who should accept and process it and how to process them; soap Encoding Rules (encoding rules), used to represent the applicationProgramAn instance of the data type to be used; an RPC (RPC representation) indicates the protocol for remote process calls and responses; a soap can be bound to multiple transmission protocols (binding ), use the underlying protocol to exchange information. This document only defines how soap is bound to HTTP and HTTP extensions.

Soap is a communication protocol. Based on the HTTP protocol, soap writes the Request Parameters in XML and submits the processing of web service servers (servlet, ASP or something) on the HTTP body, the results are also written in XML as response and sent back to the user end. To make the user end and Web Service correspond to each other, you can use WSDL as the description file for this communication method, the WSDL tool can be used to automatically generate WS and user-end framework files. Soap can be used to serialize complex objects and bind them to XML.

The predecessor of soap is RPC, which is the remote call processing protocol. This protocol is not secure. Most firewalls Block RPC communication packets, while soap uses HTTP as the basic protocol, port 80 enables soap to implement RPC through the firewall.

the SOAP protocol and HTTP protocol are both underlying communication protocols, but the request package format is different. The soap package is in XML format, now we do not need to understand soap in depth when writing Web Services. If the service and client use soap in the same environment, generally there are tools to automatically generate the soap Program Framework, so it doesn't matter if you don't know the details. however, if the environment of the client and service is different, such as the Java client and.. net service, or the Java service under Tomcat and the VB client, it is better to know some details. in particular, neither WSDL nor UDDI is a standard. If it is not used, you have to manually prepare the SOAP message.