Planning a service requester application

In general, CICS® applications should be structured to ensure separation of business logic and communications logic. Following this practice will help you to deploy new and existing applications in a Web service requester in a straightforward way. You will, in almost every situation, need to interpose a simple wrapper program between your application program and CICS Web service support.

Figure 1 shows a typical application which is partitioned to ensure a separation between communication logic and business logic. The application is ideally structured for reuse of the business logic in a Web service requester.
Figure 1. Application partitioned into communications and business logicIn CICS Transaction Server, the business logic issues an EXEC CICS LINK command to link to the communication logic; the communication logic interacts with a server.
You cannot use the existing EXEC CICS LINK command to invoke CICS Web services support in this situation: Either way, it follows that your business logic cannot invoke a Web service directly unless you are prepared to change the program. For the Web services assistant, this option is shown in Figure 2, but it is not advisable in either case.
Figure 2. Simple deployment of CICS application as a Web service requesterIn CICS Transaction Server, the business logic issues an EXEC CICS INVOKE WEBSERVICE command to invoke CICS Web service support; Web service support interacts with a server.

Using a wrapper program

A better solution, which keeps the business logic almost unchanged, is to use a wrapper program. The wrapper, in this case, has two purposes: For the case when the Web services assistant is used, this structure is illustrated in Figure 3.
Figure 3. Deployment of CICS application as a Web service requester using a wrapper programIn CICS Transaction Server, the business logic issues an EXEC CICS LINK command to a wrapper program; the wrapper issues an EXEC CICS INVOKE WEBSERVICE command to invoke CICS Web service support; Web service support interacts with a server.
Start of change

Error handling

If you are planning to use the CICS Web services assistant, you should also consider how to handle rolling back changes when errors occur. If your service requester application receives a SOAP fault message from the service provider, you need to decide how your application program should handle the fault message. CICS does not automatically roll back any changes when a SOAP fault message is received.

If you are planning to implement Web service atomic transactions in your requester application program, the error handling is different. If the remote service provider encounters an error and rolls back its changes, a SOAP fault message is returned and the local transaction in CICS also rolls back. If local optimization is in effect, the service requester and provider use the same transaction. If the provider encounters an error, any changes made by the transaction in the requester are also rolled back.

End of change