Contents

Web Service Extensibility

The widespread use of the Internet by business organizations has led to the development of web services-remote procedure calls that carry out some sort of data processing task, typically to return data of some sort.

Web services allow computers to request and receive information in much the same way that people use a web browser to open a web page. Web services employ the familiar request/response mechanism used by web browsers:

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.
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.
Once the server has responded to the client, it closes the connection, discards all state information about the transaction, and listens for another request.

In the world of web services, the client is a computer program that asks a server (another computer program) to execute a method (web service) that returns data (instead of a web page). For the request/response model to work, messages must be formatted in a way that both computers can understand. Since there are millions of computers connected the Internet, which use many different operating systems, the format of remote procedure calls has been standardized using a technology called SOAP. SOAP stands for Simple Object Access Protocol.

SOAP is an XML-based wire protocol designed for decentralized, distributed networks such as the Internet. SOAP defines conventions that allow one computer to invoke a remote procedure in another. These remote procedure calls (SOAPrequests) can be transported using a variety of network protocols. HTTP protocol is widely used.

XML stands for Extensible Markup Language. XML provides a structured way to define data in plain text format, so that data can be exchanged between computers. SOAP messages are XML documents, which are text files formatted per specific guidelines. (SOAP is the specification that defines the guidelines used to describe remote procedure calls using XML.)

Before a SOAP request can be transported to another computer, the request is structured using XML so that the remote system can interpret the request in accordance with the SOAP specification. Responses from the remote procedure are returned as XML documents.

SOAP uses XML to package the data passed to a method, or received as a response. SOAP itself is nothing more than a set of rules that define how to describe method calls and return values using XML syntax. XML merely describes data, without consideration for the way that the data is processed or presented.

SOAP makes it possible for a remote computer to start a handler on CIC, and to receive data from CIC in response.

Likewise, handlers that use CIC's SOAP tools can call remote web services.

SOAP extends CIC interoperability to the entire Internet. Anything that talks SOAP through HTTP can communicate with CIC.

Any computer platform (Windows, Unix, Linux, Mac, etc.) that can create and transport a SOAP message request can start a handler on CIC. Depending upon the type of request, the handler may or may not send back a response containing values looked up by CIC.

For example, a Unix Server might use Enterprise JavaBeans (EJB) to generate a SOAP Message requesting information about a user's status. When the request is received by CIC, it starts a handler that looks up the user's status, generates a SOAP response, and transports the response back to the requesting server. When the Unix system receives this SOAP payload, it uses another EJB to parse and process the information.

Conversely, handlers created using CIC's SOAP tools can request data from web service sand remote procedures. For example, a handler might request the current price of a stock from a brokerage service, check inventory levels from an inventory management system, conduct a credit card transaction, or obtain a weather report.

SOAP support on CIC is implemented by SOAP Tools in Interaction Designer that define initiators, invoke remote procedures, process requests and payloads. SOAP messages are channeled through a SOAP ISAPI Listenertask that runs on an IIS server.

Developers can optionally use SOAP Notifier COM components to develop applications that directly invoke SOAP handlers. SOAP Notifier COM components are compatible with any language/application that supports Microsoft's Component Object Model.

HTTP protocol is typically used to transport SOAP message traffic (XML text files) across the Internet. In the CIC environment, HTTP requests are received by SOAP ISAPI Listener-an ISAPI DLL that runs on an IIS web server. A listener receives incoming HTTP messages that contain SOAP requests for some type of service. It parses these messages, decides whether to process the request (based upon threshold values and filter configurations), and dispatches the request to the appropriate method for processing. If the service returns a response, the listener packages the response into an HTTP payload, and sends that back to the client. A listener also handles requests for WSDL information about web services.

The SOAP ISAPI Listener looks at incoming SOAP requests, decides whether requests should be forwarded to CIC to invoke a handler, and forwards appropriate requests to CIC's Notifier subsystem, which in turn calls Interaction Processor to invoke the handler associated with the initiator specified in the incoming message.
The SOAP ISAPI listener and packages return values from handlers into outgoing HTTP responses, and sends them to the client. If the listener decides not to forward a request to CIC for processing, it returns a fault message (SOAP and/or HTTP) to the requesting client application.

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. We've covered a lot of concepts in a short time, so let's review them:

SOAP defines conventions needed to invoke the methods of a web service.
A web service is a procedure of some sort that is called by a remote client application to initiate a process or request some sort of data.
CIC's SOAP tools allow web services to be created using Interaction Designer.
SOAP uses existing transport protocols (such as HTTP) to transmit an XML payload to another computer. The payload contains everything that the remote computer needs to execute a function (arguments and data).
Services that understand SOAP requests can be expected to return XML responses in accordance with the rules of SOAP.

Customer Interaction Center supports open standards (SOAP, XML, WSDL, etc.) that promote interoperability and are applicable to many types of application development. SOAP tools are primarily used by developers, advanced handler authors, and professional services personnel. However, the services created using SOAP tools are another matter. Anyone, anywhere on the Internet is potentially a consumer or provider of information processed by SOAP handlers. The possibilities are limitless.

For example, a caller might enter a PIN number into an auto-attendant menu created using Interaction Attendant. In turn, Attendant could start a SOAP handler that passes the PIN number to a remote web service to look up information that is spoken back to the caller using CIC's text-to-speech capability.

A remote procedure invoked by SOAP can perform any kind of data processing tasks, ranging from a simple lookup to complex transactions that accept complex data types as input. SOAP does not impose any limits on the application functionality that can be invoked.

SOAP tools allow developers to create handlers that retrieve data from web services, or which function as web services. Handler-based services can be described using Web Services Description Language (WSDL)-an XML-based language that defines the functionality offered by a web service and how to access it. WSDL makes it possible to describe a service on CIC so that a worldwide audience can find and use it. WSDL describes the service, all parameters required to invoke it, and the location (endpoint) where the service can be accessed.

SOAP makes it possible for programs written in different languages and running on different platforms to communicate with each other. SOAP integrates the PureConnect platform with business-to-business interactions and information services. Once a SOAP endpoint is exposed to the internet, a handler may call into the endpoint, which may be on the Internet or an Intranet.

SOAP is not appropriate for low-level, tightly-coupled transactions, due to network latency and the overhead imposed by the SOAP messaging encoding and decoding. SOAP is best suited for simple, high-level transactions, such as sending a name and PIN number to a service to obtain an account summary.