![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Next steps
You have seen the basic scenario using CICS as a requester and provider to show the effects of turning WS-AT on and to see message flows between the client and the endpoint. A more realistic, business-oriented application could call multiple web services, update more complex resources, and interact with non-CICS web services gateways.
The example you have run through in this tutorial is a simple one; you are only calling a single web service from a simple application program. This web service updates a recoverable TSQ and can roll back if necessary. More realistically, the recoverable resource would be more complex, such as a VSAM file or DB2® UDB database record.
Using WS-AT does not affect the way in which individual CICS applications can perform transactionally except to provide the additional, cross-system functionality we require. All in-application calls made to DB2 UDB, writing to VSAM files, or any other recoverable task can be dealt with in conjunction with atomic web services by the CICS recovery manager. All tasks must complete successfully for the changes to be committed as expected.
You can also use multiple atomic web service calls from within a single transaction. The requesting application will successfully call several web services and coordinate them all to completion. Similarly the providing application can successfully call several web services and act as both a participant for its requester and coordinator as a requester for it's invoked web services.
You can use the WSDL document from your web service to create a WebSphere Application Server (Application Server) skeleton web service, which you can use to interact with CICS. IBM Rational® Application Developer can import WSDL files and convert them into a web services provider or requester. Atomic transactions support is available and can be implemented for this process. These transactions can then be exported to Application Server (Version 6.02 minimum). The details of how this is done is beyond the scope of this tutorial, however once enabled and running, your CICS set-up need not change to call the WebSphere provider.
Simply change the endpoint URI from your requester application (ACCR URI http://.../accsrv) to call a new endpoint. The WSDL document and specifications define the contents of the message flows, meaning they are standardized and will work independently of the software used to create the application code.
Direct Application Server's web services requester at your CICS endpoint (http://[host]:[port]/accsrv) passing the parameters defined in the WSDL (operation SET or GET with a value). Once enabled, web services atomic transaction coordination works between Application Server and CICS, with message flow and ordering being identical to what you have seen.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular tutorial tags |
My tutorial tagsSkip to tags list
Popular tutorial tags |
My tutorial tags
