As we know, SOAP is a call-response mechanism, which operates in a client-server paradigm. The client (your application) makes a call to the server (a web server, somewhere on the internet), passing in parameters; and the server provides a response. Both call and response are transported in the form of XML documents. Therefore, to build our own example SOAP system, we need both a client and a server – a caller and a responder.
The example we will follow is a very simple one: we will build a service that will calculate the tax due on a sales transaction. In traditional VB terms well will create a function with the following definition:
Public Function GetSalesTax(ByVal pSalesTotal As Double) as Double
GetSalesTax = pSalesTotal * 0.04
End Function
Crude, but effective (if you live in a state where the sales tax rate is 4%!)
This function defines a method name (GetSalesTax), a parameter (pSalesTotal – representing the total value of the sale) and a return value (the result of the function). In more traditional object-oriented terms, we might think of pSalesTotal as an “IN” parameter, and the GetSalesTax result as an “OUT” parameter. Quite straightforwardly: sales-total in; sales-tax out. A SOAP service can be thought of in terms of “IN” and “OUT” parameters – the client passes “IN” parameters to the server, and then receives the “OUT” parameters in return. So, in order to create our SOAP service, we need a server that will listen for requests to GetSalesTax, accompanied by “IN” parameters, and which will respond with “OUT” parameters, indicating the correct tax amount. Let’s start with the client – the caller. How do we call the SOAP service to make our request.
Comments