Basic Principles of Web Services

Basic Principles of Web Services
Web services are guaranteed through a series of standards and protocols Program Dynamic connection between them. The most basic protocols include SOAP, WSDL, and UDDI.

Soap: the abbreviation of "Simple Object Access Protocol". Soap is the message transmission protocol, which specifies how information is transmitted between Web Services. Simply put, soap stipulates:
1. The format of transmitted information is XML. This enables web services to be implemented in any language on any platform.
2. Format of Remote Object method call. Specifies how to represent the called object and the name and parameter type of the called method.
3. ing between parameter types and XML formats. This is because the called method sometimes needs to pass a complex parameter, for example, a person object. How to use XML to represent an object parameter is also the scope defined by soap.
4. Exception Handling and other related information.

WSDL: the abbreviation of "Web Services Description Language". Its name is as follows. WSDL is the definition language of Web Services. When you implement a certain service (such as the stock query service), you must inform everyone of your service interface to make other programs call it. for example, the service name, the name of the machine where the service is located, the listening port number, the type, number and sequence of passing parameters, and the type of returned results. in this way, other applications can call your service. The WSDL Protocol defines the standards for web services description.

UDDI: the abbreviation of Universal Description, discovery, and integration. To put it simply, UDDI is used to store and find the WSDL description file in a centralized manner and serves as a Directory Server.

Implement a web service to enable it to accept and respond to soap messages (many tools can help implement it now ).

Write a wsdl file to describe this web service. (Currently there are many tools that can automatically generate the WSDL file ).

Publish the WSDL to UDDI.

Other applications (clients) Search your WSDL from UDDI.

Based on your WSDL, the client can write a program (currently many tools can automatically generate a calling program) to call your web services.

Disadvantages of Web Services
Because it is an XML-based application, Web services inevitably inherits some restrictions brought by XML while having all the advantages brought by XML.

Web services usually require a large amount of CPU resources. Because XML data must be processed in multiple steps before it can be used by the system. The first is validate, which checks whether the format complies with the XML specification and whether it complies with the semantic specification according to the application definition (DTD or schema; then we need to parse (PARSE), break down a single element from the XML file, and finally convert it into the Binary Expression required by the application (for example, converts "12" to the binary representation of integer 12 ).

Web services also occupy a large amount of memory resources. A large number of temporary memory objects are generated during XML parsing. Especially when processing DOM objects. These large numbers of temporary objects are a burden on the language and system that automatically recycles memory such as Java. A large number of temporary objects will cause the system to recycle memory at intervals, this reduces system performance. Of course, some web services products (such as axis) now use the sax technology, greatly reducing the memory usage. For more information, see: (http://xml.apache.org/axis/index.html ).

The consumption of network resources is also a limitation of web services applications. Because XML-based data transmission usually has a larger data volume than binary protocols (such as RMI/IIOP. This extra consumption will have a certain impact on applications with tight network resources or frequent network transmission.

In addition to the restrictions imposed by XML, Web Services has some disadvantages:

So far, Web services can also be said to be a stateless service.
Stateless means that it does not save any information of the Client Service caller. This is determined by the nature of Web Services. In essence, Web services must provide data communication standards between applications and dynamically provide services with a large granularity between enterprise applications, therefore, Web services is not suitable for very fine session-based method calls and complex transaction processing.
Someone may disagree with me! Because many web services products (such as wasd) can not only save session information, but also make the service stateful, remote Object handles can be passed in Web Services sessions, allowing clients to manipulate the delivery of remote objects (for details, see: http://www.systinet.com ). In principle, this is not difficult to implement, because in XML data, any data can be transmitted to each other, including sessionid and transactionid. With these IDs, technically speaking, implementing stateful is not complicated. However, this feature lacks standard support, and the WSDL of the current version cannot represent these complex services. Within an enterprise, you can use any of these special functions to define the interaction protocol of the session state, because communication between the service provider and the service caller is under your control; however, to publish these services to the Internet, other applications cannot identify these special features according to standards.

Data Binding also has some shortcomings.
Because all data transmission uses the XML format, there must be a conversion between binary data and XML data. However, not all binary data can be conveniently expressed in XML, and not all Java objects can be expressed in XML. Therefore, semantic loss often occurs during the conversion process.

high technical requirements and long learning curve.
each web service product has a wide range of tools to generate client programs according to Web Services definitions (such as WSDL files, it is easy to package it into a Web Services Service. Therefore, all web services products claim that their platforms are easy to use, and they do not need to understand XML or WSDL, UDDI, or soap to publish Web Services. In particular, a friend told me that he had published a Web Service in. Net in 15 minutes without knowing anything!
do not be obsessed with this simplicity. This may be true for simple demos. However, you must understand all aspects of Web Services for serious applications, design the overall structure and solution, and adjust the performance according to the specific application. All of these require a comprehensive understanding of Web Services.