Create a callback client for asynchronous Web Services (figure)

Web Services is a promising technology that plays an important role in service-oriented Architecture (SOA. A key aspect of this emerging technology is the ability to provide asynchronous services. Although the current standard Web Service Specification includes content that provides asynchronous services, the foreground details of client applications are still confused and vague. Web Services callback is an important factor in implementing these asynchronous services. This article provides practical guidance for creating customer applications with callback operations on Web Services. All the code segments in this article come from examples that you can download. These examples contain the complete implementation and Usage Guide of these code segments.
　　
　　 Terms
　　
It is important to clarify related terms before discussing clients that support callback. Displays the main entities involved when the client uses a web service with callback operations.
　　 　
　　 Figure 1. Client that calls Web Service
　　
Describes the client's call to the web service. Web service can respond to the client callback after a period of time. Therefore, the special feature of the web service client that contains callback operations is that the client itself must provide an endpoint. We call this callback endpoint and define this endpoint as a unique address determined by the URI. the SOAP request message will be sent to this URI.
　　
After a SOAP message is sent to the Web service endpoint, the client starts to interact with the web service. The request message sent by the client to the Web Service and the Response Message constitute the initialization operation of the client. As mentioned above, the customer can process the request message sent from the Web service to the callback endpoint. Related requests and response messages are called a callback operation together.
　　
After understanding these terms, let's take a closer look at the concept of Web Service callback and Its Relationship with Session Web Services and asynchronous web service calls.
　　
　　 Asynchronous, callback, and session
　　
The concept of asynchronous web service calling is sometimes confusing with Web Services callback and session Web Services. Although these three concepts are quite relevant, they are different.
　　
Asynchronous Web Services calls allow clients to send SOAP message requests without blocking the response messages sent from the server. The asynchronous web service calling process on BEA Weblogic Platform 8.1 web services has been detailed in the software documentation. Therefore, we will not discuss it further in this article.
　　
Web Services callback refers to the situation where the web services provider sends a SOAP message back to the client. Web Services Description Language (WSDL) specifications defines this operation as a "request/response ". The Web Services Client that supports callback must have a web services endpoint, so that the Web service can use this Web Services endpoint to send callback requests at any time, that is, it can be asynchronous. Note that this is not related to the asynchronous call discussed above.
　　
If a series of messages that can be sent back and forth between two endpoints can be tracked by a unique session ID, and this ID identifies the beginning and end of the message stream by a specific operation, this web service is a session. The Web services that provide callback are also defined as session-based. This is because under normal circumstances, if Web services can perform callback access to the client, it must have its own callback endpoint information. This happens only when the client makes the initial call. Therefore, at least the initialization operations initiated by the customer and the callback operations performed by Web services are correlated and tracked by the unique session ID. Otherwise, the client cannot identify the callback operations associated with different initial calls.
　　
Now we will consider these issues and create a client that supports callback. As we can see just now, these clients form the foundation of request-response and session Web Services.
　　
　　 Create a client that supports callback
　　
As discussed earlier, the Web Services Client that supports callback must provide a callback endpoint that can receive and process callback messages asynchronously. To avoid the need to provide callback endpoints, a polling technology can be used as an alternative. However, this technology requires the client to periodically call the server to verify the callback event. If such events rarely occur, the call overhead will be too large. This overhead can be avoided if the client provides a callback endpoint and directly processes the callback operation.
　　
We should also note that although we can use web services on JMS (if this connection is provided) to create a client that supports callback, this method has some limitations, an important constraint is that the client must adopt the same JMS implementation as the web services provider. Therefore, we will focus on HTTP transmission to complete our tasks. There are two areas for creating such a client: creating an appropriate client to start soap messages and processing callback operations.
　　
When the client starts a web service operation with callback, it needs to include the URI of the callback endpoint in some way so that it can listen in the request message. Both the web services addressing and soap conversation protocol specifications define SOAP header elements, allowing you to achieve this goal. Theoretically, it is not important to specify the callback endpoint specification. However, most Web Services containers (including BEA WebLogic Server 8.1) do not yet contain the implementation form of the Web Services Addressing specification. Currently, Web Services of BEA WebLogic Workshop 8.1 support the soap conversation protocol specification, which will be used in the example client.
　　
According to the soap conversation protocol, the SOAP header is different in different stages of the session. For the first client start (start) operation in the session, we need to provide the Web service with the callback endpoint through the callbacklocation Header element. All operations (including the first operation) also require a unique ID, which is used in our SOAP message throughout the session. This can be done through the conversationid element. The following is an example of starting a SOAP request message that supports callback sessions:
　　
<Soapenv: envelope soapenv: encodingstyle = "http://schemas.xmlsoap.org/soap/encoding"
Xmlns: soapenv = "http://schemas.xmlsoap.org/soap/envelope"
Xmlns: XSD = "http://www.w3.org/2001/XMLSchema"
Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
Xmlns: ENC = "http://schemas.xmlsoap.org/soap/encoding"
Xmlns: ENV = "http://schemas.xmlsoap.org/soap/envelop"
Xmlns: SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/">
<Soapenv: Header>
<Con: startheader soapenv: Actor = "http://schemas.xmlsoap.org/soap/actor/next"
Soapenv: mustunderstand = "0"
Xmlns: con = "http://www.openuri.org/2002/04/soap/conversation/">
<Con: conversationid> [123456]: 192.168.1.100: 8181 </CON: conversationid>
<Con: callbacklocation>
Http: // 192.168.1.100: 8181/stockicationicationcallback
</CON: callbacklocation>
</CON: startheader>
</Soapenv: Header>
<Soapenv: Body>
<N1: registerforthresholdnotif xmlns: n1 = "http://www.openuri.org/">
<N1: stockticker> CCC </N1: stockticker>
<N1: threshold> 10 </N1: threshold>
</N1: registerforthresholdnotif>
</Soapenv: Body>
</Soapenv: envelope>
Most existing Java Web Service sdks (such as BEA Weblogic's clientgen, Apache axis, and jwsdp) allow you to create a proxy library, which can be easily used by client programs to call web services operations. However, none of these frameworks support callback operations. The main problem is that their proxies do not generate the required headers. Before providing such support, this benefit is needed by extending their support for callback operations to utilize these frameworks (such as complex class XML ing. A technology used to achieve this effect is the application of SOAP message processing programs.
　　
All the Web Services toolkit mentioned above can support SOAP message processing programs. The message processing program is a Java class that implements javax. XML. RPC. handler. the generichandler interface also contains a method called sending (or receiving) soap messages first. Here we introduce the message processing program in our client, which can identify the current stage of a specific session and expand the request message with the required header accordingly.
　　
It is important to note that the client SOAP message processing program must be able to determine the stage of the message in the session to create a proper Header element. Generating a session ID is also a task to be completed by the client processing program.
　　
Once the Web Services endpoint receives the extended request message, it sends the request message to the callback endpoint specified by the callbacklocation element of the Start message. In most cases, the client itself needs to provide this endpoint and properly process the callback message. If the client runs in a Web Services container, you can deploy the web services with callback operations in the same container. However, if the client is not running in a container, this task depends on executing the callback endpoint in a lightweight container embedded in the client process itself. This allows us to call the operations generated by the client and process the incoming callback operations in the same process context. Note that the process entity behind the callback endpoint (and in the client) requires that not only code operations on the appropriate domain can be assigned, but also XML ing can be processed.
　　
Of course, the client can also set the appropriate callbacklocation Header element to specify a callback endpoint in the container, which is separated from the access process.
　　
As we can see, creating a client for Web Services with callback operations is not meaningless. It contains complex elements, such as processing soap messages and managing sessions (including stages and IDs) parameter ing and operation allocation. When the Web Service is accessed through BEA WebLogic Workshop service control, the complexity does not exist and it automatically performs all operations for the user.
　　
　　 Use a service control to create a client that supports callback
　　
Web services access through WebLogic Workshop service control has been described in detail in the software documentation. If the client entity can use controls (that is, Java