Web Service Development Level

Keywords: Web Service

Web service is a very popular thing in recent years. It has brought a lot of new terms, so it looks quite dazzling. Looking at its flashy surface, it is no longer magical. The following discussions refer to Java.

1. Accessing a web service can actually be seen as calling a function. The only difference is that this function is remote. There is no essential difference between it and RMI.
Since it is a function, of course, a function declaration is required. To do this, it is WSDL. It defines the prototype of the function in detail, including the function name, entry parameter, and exit parameter, this is the work completed by opertion in WSDL.
Since it is a remote function, it also involves binding to a remote address, which is a service task in WSDL.
Axis is a development kit that can generate the corresponding access code through WSDL. It is integrated in JBuilder, and the operations that originally need to be manually completed in the command line are simplified through wizard.

2. Since it is a remote access, there must be an access protocol. The web service access protocol is soap, and soap is built on XML, the difference is that there are some restrictions on the XML format that is not originally restricted, and envelope is required. In envelope, header and body are also divided.
If you use soap to develop a web service program, you need to assemble the soap package from the line according to the definition of WSDL, which is obviously complicated for Billy to directly develop the web service with WSDL.
Jaxm is a development kit that uses soap for communication. It simplifies the packaging process of soap messages.

3. Soap is built on XML, so obviously the XML Development Kit is also suitable for soap.
To develop web services at this level, in addition to completing the work at the previous layer, we also need to assemble soap messages according to the SOAP format, which obviously increases the workload.
There are a lot of XML development tools, from the simplest Sax and Dom to dom4j and JDOM, there are also a lot of tools for binding XML to objects, such as jaxb and Castor.
In fact, it is not uncommon to use XML for communication protocols without considering Web Services. Knowing the existence of XML-RPC makes it easy to understand the meaning of XML communication.

Sun has provided jwsdp (Java Web Service developer pack), which includes a full set of solutions from XML parsing to WSDL generation.

4. All the things discussed above are actually stuck in the message passing content, and do not involve the communication process. Do not assume that the web of a Web service can only be transmitted over HTTP. As we can see from the previous discussion, there is no direct relationship between all the message content and the transmission, so there is no problem with HTTP transmission, SMTP, or custom protocols.
Developing Web services at this level requires manual parsing of XML in addition to various obstacles.
The most common HTTP method is used for discussion.
HTTP development treats the server and client differently. The common choice of server implementation is servlet. It can save a lot of effort for the Web server to complete HTTP Protocol Resolution for us. For the implementation of the client, you can select the built-in HTTP client of JDK. The Commons Sub-project under the Apache Jakarta project also provides an httpclient.

5 Both HTTP, SMTP, and custom protocols are application-level protocols. The underlying implementation is completed by socket. At this level, it is basically the primitive era. Nothing is done, and everything must be done manually.
To develop web services at this level, we have to go through all the previous difficulties. In addition, there are also people waiting for the development of protocols.
At this point, no other tools are required. The socket provided by JDK can be kept safe.

6. Do you want to continue? The next step is the implementation of the operating system. The Java platform has nothing to do with it, and it has no meaning. It is beyond the scope I currently know. Stop here!

The above mentioned should be a basic knowledge structure of web service. I didn't discuss the content of UDDI and so on here. I don't know about it, and I should be an application, it should not be included in the Web Service implementation.

Although we may not develop web services from the bottom layer, it is inevitable to encounter underlying problems.
When I was developing a web service application, I was caught. The case sensitivity of soapaction in the HTTP header is different from that of a so-called specification. I checked the HTTP and soap specifications for half a day, it is known that HTTP is differentiated by size, and soapaction should be written in this way. It is justified to point out the so-called standard error.

After the previous discussion, we can see that there is no mystery in Web Services, and everything is built on the basis of existing things. The development of technology will not be nothing, but a better solution. A solid foundation is the most important before looking for new changes.