ATL Server Web Service Internals


By now you may be wondering how ATL Server Web services really work and what goes on under the covers of attributes, XML, and marshaling. You may also be wondering why ATL Server has the limitations it has or how it s able to achieve the performance it does. In this section you ll examine the inner workings of attributes and ATL Server Web services with the goal of answering some of these questions. In the process of answering these questions, you ll expand upon the set of tools and techniques you ve learned in order to leverage the flexibility of ATL Server so you can take full advantage of the power of ATL Server Web services. We aim to show that there s no great magic going on under the covers, and the full details of the implementation are there for anyone to examine in the ATL Server source code shipped with Visual Studio .NET.

One important disclaimer about this section: Most of what follows consists of implementation details and documentation about private APIs. The information isn t to be used directly in user applications. The information also applies only to Visual Studio .NET and may (and likely will) change in future versions. It s for informational and debugging purposes only ”any other use is at your own risk.

How an ATL Server Web Service Works

You ll first examine what needs to happen to allow the ATL Server Web service to work the way it does. Let s take the Hello World Web service presented in Listing 19-12 and examine what needs to happen at each stage in the lifetime of a SOAP request on the server. The client is by and large the same, except that the order of the operations is reversed : First it generates the output (request) and then it parses the response it gets from the Web service, as shown in Listing 19-13. Unlike the earlier Hello World samples, however, you ll include a SOAP header in this one to show how that processing is done. You ll omit namespaces in the example SOAP packets for ease of understanding. Figure 19-1 shows the basic architecture of ATL Server Web service request processing.

click to expand
Figure 19-1. The architecture of an ATL Server Web service request
Listing 19.12: SOAP Request Packet
start example
 < Envelope>      < Header>          <InputHeader>StringValue</InputHeader>      </Header>      <Body>          <HelloWorld>              <InputParam>John</InputParam>          </HelloWorld>      </Body>  </Envelope> 
end example
 
Listing 19.13: SOAP Response Packet
start example
 <Envelope>      <Header>          <OutputHeader>IntegerValue</OutputHeader>      </Header>      <Body>          <HelloWorld>              <return>Hello, John!</return>          </HelloWorld>      </Body>  </Envelope> 
end example
 

When a Web service receives a SOAP request, it must

  1. Determine the intended recipient of the SOAP request (the HelloWorld Web service method in this case).

  2. Parse the XML of the SOAP request and marshal all the headers ( InputHeader ) and parameters ( InputParam ) into real C++ data types.

  3. Invoke the intended recipient of the SOAP request (the HelloWorld Web service method) with the expected parameters ( InputParam ) and with the expected member variables that correspond to the input headers.

  4. After the invocation of the Web service method, it must take the output parameter and return value and generate the SOAP response. This involves taking the C++ data types and converting them to XML.

  5. Finally, any memory or resources that were allocated during the processing of the request must be freed.

Similarly, the Web service client must produce the request and consume the response ”basically an inverse operation of the server.




ATL Server. High Performance C++ on. NET
Observing the User Experience: A Practitioners Guide to User Research
ISBN: B006Z372QQ
EAN: 2147483647
Year: 2002
Pages: 181

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net