SOAP's Request/Response Model

CIC uses a request/response model to process SOAP requests.  This mechanism should be familiar to anyone who has used a web browser. 

1. A client (e.g. web browser) connects to a server and passes a request (fetch a web page).  The client then waits for the server to respond. 

2. The server responds in one of two ways.  It either returns the requested information, or it responds with an error message that tells the client why the request could not be completed.

3. Once the server has responded to the client, it closes the connection, discards all state information about the transaction, and listens for another request. 

Web Services

In the world of SOAP, the client is a computer program that asks a server (another computer program) to execute a method (sometimes called a web service). 

In CIC configuration, HTTP requests are received by SOAP Listener—an ISAPI DLL that runs on an IIS web server.  SOAP Listener passes requests to the CIC Notifier subsystem for processing.  Notifier alerts the Interaction Processor subsystem, which in turn starts the handler needed to process the request.  Response data from the handler is passed back to the Listener task for transport to the remote computer. 

In general, SOAP Listener translates HTTP requests into notifications and acts as a gatekeeper to prevent denial of service attacks.

On the receiving end, the response message is decoded and used by the requesting computer in some way.  This low-overhead approach permits a single server to share information with many clients. 

Requests and Responses are XML Documents

In order for the request/response model to work, messages must be formatted in a way that both computers understand.  SOAP uses XML to accomplish this.