Single Service creation for existing CICS or IMS Applications

Single Service creation for existing CICS or IMS Applications
Featuring Rational Developer for System z version 7.6 Reginaldo Barosa - IBM Software Group This presentation will look at the XML Services for the Enterprise (XSE) component of Rational Developer for System z V7.6 (RDz), the follow-on product to Rational Developer for System z V7.6 (RDz). Updated May 2010 Single Services and IBM Rational Developer for System z

Presentation objectives
After completing this session, you should be able to: Understand the capability of Rational Developer for System z to work with XML and CICS or IMS Services Define Generic use cases for Rational Developer for System z and XML enablement Be able to follow the lab Some of the slides will not be covered and are designed to be future references.. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Single Services and IBM Rational Developer for System z
Agenda SOAP/XML/WSDL and Web Services Overview Rational Developer for System z and Single Web Service Enablement Styles Web Service Request into IMS Single service support using CICS TS Version 3.x XML to COBOL Mapping (Meet in the middle) Batch Processor Support  Some of the slides will not be covered in detail and are designed to be future references.  Lab assignment Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

What is a Web service? A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols. Service Requester Request Response Interface Service Provider HTTP WSDL 1 2 3 What’s behind the interface is not part of the standard. That’s all hidden by the standard interface. The function and format of the SOAP envelope The function and format of the WSDL file Some of the industry standards that help vendors know how to implement the interface Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

What is XML ? SOAP ? WSDL? Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

The Importance of XML in Web Services
You will see that XML is the common mechanism to exchange information in a web services environment. What is XML, and why is it valuable? A series of “tags” that mark the beginning and end of blocks of XML It holds both the data, as well as description of the data <CustNo> provides an indicator of what the data is; “3” is the actual data. It is both machine readable and human readable, which makes things relatively easy to understand Contrast with bit-format protocols, where bits within bytes meant certain things. Machine readable yes; human readable less so. Characters use “Unicode” encoding, which means it’s universally understood As opposed to the old EBCDIC vs. ASCII debates <SOAP-ENV:Envelope> <SOAP-ENV:Body> <q0:DFHCOMMAREA> <CustNo>3</CustNo> </q0:DFHCOMMAREA> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Example of XML SOAP envelope we’ll use in our labs It is “Self Describing” It can be “parsed” In the middle of this whole discussion is something called “XML,” which stands for “eXtensible Markup Language.” It plays a central role in Web Services. Here’s what XML is and why it’s so valuable: XML consists of a series of “tags,” delimited in brackets < and >, that mark the beginning and end of data and blocks of data within a file. The example above is what we’ll use in the CICS web service lab later. Look at the very center of that … you see <CustNo>3</CustNo>. That digit 3 is the input to the Web Service we’ll create. The tag <CustNo> indicates what the data is (a customer number). The “end tag” </CustNo> indicates the end of the data. The <q0:DFHCOMMAREA> marks the beginning of the Web Service input data; the </q0:DFHCOMMAREA> marks the end. In this example there is only one data input element -- <CustNo>, which a value of 3 supplied. The file is both machine-readable and human readable, which makes it much easier to work with for us humans than a packed binary format would be. The files use Unicode encoding, which means the requester and provider don’t need to coordinate on character encoding. XML is “self describing,” which means that computer programs can understand what XML tags to expect by reading a separate file, called an schema definition file. That tells what tags to expect, what kind of data will be included by each tag, which tags are required and which are optional. When a program reads the XSD, it then knows what to expect when it reads the actual XML. (The program of course needs to understand how to read the XSD … which is one aspect of being a Web Service requester or provider.) The XML can be “parsed,” which means a computer program can sweep through and extract the contained data by looking for the start and stop tags. Let’s look a bit more closely at the SOAP envelope, which is XML, and HTTP, which is one transport mechanism that can be used to send the XML from requester to provider. Something called a “Schema Definition” (XSD) is used to tell a program what XML tags to expect. The WSDL file has XSD information If a program knows what tags to expect (the WSDL supplies this), then the program can “parse” (extract) information from the XML. XML =eXtensible Markup Language Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

“SOAP over HTTP” You’ll frequently hear this phrase. What it’s referring to is the passing of an XML document -- a SOAP “envelope” -- using the HTTP protocol Web Service Client Web Service Provider XML File HTTP Protocol (TCP/IP Network) <SOAP-ENV:Envelope xmlns:SOAP-ENV=" xmlns:q0=" xmlns:xsd=" xmlns:xsi=" <SOAP-ENV:Body> <q0:DFHCOMMAREA> <CustNo>3</CustNo> </q0:DFHCOMMAREA> </SOAP-ENV:Body> </SOAP-ENV:Envelope> The SOAP input for our CICS lab Knowing the layout is not that important to us at this point One of things you’ll hear frequently is the phrase “SOAP over HTTP.” And what that means is that the standard request and response file format -- called SOAP (Standard Object Access Protocol). The XML that makes up the SOAP envelope needs to be sent from requester to provider. At the lowest level that goes over an IP network, but higher up in the protocol stack HTTP is frequently used to carry the XML. HTTP -- Hyper Text Transfer Protocol -- is the same protocol we all use to browse websites. The layout of the SOAP envelope is an agreed-to standard, and both requester and provider must understand what it is and how to read it. Inside of the SOAP envelope is the input parameters the requester sends to the service. In our example it’s the integer “3”, which is the customer number. Knowing the exact layout of the SOAP envelope is not really important to us. What is important is that we know what a “SOAP envelope” is (an XML document); we understand that it is an industry standard format; and we understand that it’s what goes back and forth between a Web Service requester and provider. You can well imagine how difficult it would be to have a services architecture be widely adopted if requesters had no idea how to form up the basic unit of exchange with the provider. By defining a standard exchange format -- the SOAP envelope -- it facilitates a wider acceptance of Web Services. Now let’s look at the WSDL file -- the “Web Services Definition Language” file … ========================= SOAP: An XML lightweight messaging protocol Request and Response messages Request invokes a method on a remote object Response returns result of running the method SOAP defines an “envelope” “envelope” wraps the message itself identifies the package as a “SOAP Message” message is a different vocabulary namespace prefix is used to distinguish the two parts The most common transport mechanism for SOAP is HTTP, even though HTTP is not thought to be reliable enough for key B2B transactions. Rational provides a proprietary alternative - Apache SOAP – which provides an SMTP transport mechanism. Apache SOAP has been included as the WebSphere SOAP engine since WebSphere version 4. It is being superseded by Apache AXIS and ultimately by “Web Services for J2EE”. There is currently no specification for SOAP JMS; each vendor chooses its own implementation technique. Therefore, interoperability is not possible using this protocol at this stage. Documents containing multiple markup vocabularies pose problems of recognition and collision. Software modules need to be able to recognize the tags and attributes which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element type or attribute name. These considerations require that document constructs should have universal names, whose scope extends beyond their containing document. This specification describes a mechanism, XML namespaces, which accomplishes this. The URIs used as XML namespace names are not guaranteed to point to anything, so there is generally no reason to resolve them. Furthermore, there is nothing in the processing of XML namespaces that requires you to resolve these URIs. The key is that the client program knew what the provider expected -- what data elements and what XML tags to use. How did it know that? It had the WSDL file. SOAP = Simple Object Access Protocol Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

The WSDL File WSDL contains information about the service -- where it’s located, what parameters it takes as input, what it gives back as output, what XML tags to use, etc. It is sometimes known as a “bindings file”. It can be long and complicated … what follows is a boiled-down snippet to show essence <complexType name="DFHCOMMAREA"> <sequence> <element name="CustNo"> <simpleType> <restriction base="int"/> </simpleType> </element> </sequence> </complexType> <wsdl:service name="LAB3POTService"> <wsdl:port binding="tns:LAB324Binding" name="LAB324Port"> <soap:address location=" </wsdl:port> </wsdl:service> What service will return was here … removed to save space Client knows input XML and data requirements based on this Client knows where service is located based on this Web Service Provider We have mentioned serveral times how important it is that the request know not only that a service exists, but also where that service is located, what that service’s input requirments are, what can be expected in return. To provide that information the Web Services standard defines something called the WSDL file … Web Services Definition Language … which contains information about the service offered. The WSDL file uses XML, and is in Unicode encoding. The example above is a shortened version of an actual WSDL file. It can be somewhat long and complicated. What’s shown above is just a snippet. In the upper portion of that example we see that the WSDL file is defining the input requirements of the offered service. The “complexType” is the set of input parameters defined by the service program. In this case the name is DFHCOMMAREA. (We’re using as an example the WSDL created by RDz for the CICS Web Services lab we’ll do in a bit.) This service has one input parameter -- CustNo. If it had three, for example, we’d see three <element> tags within the <complexType> block. But as it is we see only one <element>, and that’s for “CustNo.” What kind of data is “CustNo”? We see that it’s defined as an integer. So using this, the service requester knows that one input parameter is expected (“CustNo”) and that it’s an integer. Note: a bit later we’ll show how the WSDL also contains what the requester can expect in return. We didn’t show it here because the chart would get too busy. How about where to send the request? That’s later in the WSDL. There we see the host and port where the service is located. We also see the “context root” of the service -- the text that follows the host and port and identifies which service is to be invoked. The requester program reads this WSDL file to understand what the service expects, what can be expected in return and where the service is located and how it’s invoked. But where does the WSDL file come from? That’s next. <SOAP-ENV:Body> <q0:DFHCOMMAREA> <CustNo>3</CustNo> </q0:DFHCOMMAREA> </SOAP-ENV:Body> Web Service Client WSDL = Web Services Definition Language Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

WSDL File is a generated by the Development Tool
You could hand-code the WSDL. More likely you’ll use a development tool to create the web service, and that tool will produce the WSDL. Web Service Provider Service Program With WSDL, client knows where service is and how to drive it Web Service Client WSDL File Rational Application Developer Rational Developer for System z CICS Batch utilities Other Development Tools The WSDL file doesn’t magically appear. Something needs to create it. That something is typically the development program used to create the web service itself. For IBM, that development tool is increasingly coming to mean an “Eclipse” based tool, such as Rational Application Developer (RAD) or WebSphere Developer for zSeries (RDz). As part of the process of creating the code that implements the interface for the service, a WSDL file is also created. So what’s required is for that WSDL file to be made available to the web service client so it can know how to form up its request SOAP envelope and where to send it to. With only a handful of services and requesters, it’s relatively easy to manage the manual process of making this file available to Web Service requesters. But when the number of services and requesters increases then the task becomes much more complicated. Ultimately some kind of “registry” is needed -- a place where service requesters can go get the most current WSDL file for a given service. With that we’ll revisit the role of UDDI. With only one service and one client, this is easy. What about a hundred difference services and a thousand clients? Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

A Few Ways to Get Web Service Request into IMS
Several of the ways involve front-ending IMS with a web service in WebSphere Those make use of standard adapters to get back to IMS Local WebSphere z/OS IMS DB RAR IMS DB SOAP/HTTP ODBA SOAP/JMS JMS/MQ IMS/MQ Web Service Client SOAP/HTTP OTMA Applications IMS DC RAR Remote WebSphere (any platform) Java IMS DC RAR TCP IMS Connect TCP IMS SOAP Gateway SOAP/HTTP TCP Notice that none involve web service interface running inside of IMS There are many ways one can access IMS data as a Web Service, but none of them involve accessing IMS directly with HTTP. In all cases there’s something between the client and IMS. This picture illustrates five different scenarios: The top-most box illutrates WebSphere Application Server for z/OS running on the same MVS image as the IMS region. We learned earlier that WebSphere itself is an excellent host of a Web Service interface, and from there a long list of data connection options is available. Two of those are data connectors to IMS. One is called “IMS DB RAR,” which is really a JDBC implementation to access the IMS database. This can only be used when the application using the files in the RAR is local to the IMS region. The second is something called “IMS DC RAR,” which is a way to access IMS applications using OTMA. If the application is “local” (same MVS image) then it can directly access without need of IMS Connect. But even if it is local you may opt to connect via TCP through the IMS Connect function. You can also access your Web Service through JMS, then go MQ back to the IMS/MQ bridge and into IMS. If WebSphere is “remote” (not on the same MVS image) -- either WebSphere z/OS or WebSphere on any platform -- then IMS connect is required as the communication from the application to IMS will be over TCP. (Note: not shown is flowing JMS/MQ to IMS/MQ Bridge. It’s possible, but the picture was getting too cluttered.) The final means is through something called the “IMS SOAP Gateway,” which is function implemented on a distributed box (it is not available for z/OS). The SOAP gateway is capable of handling the SOAP envelope and communicating with IMS Connect to execute the service. The focus of this discussion will be on the IMS SOAP Gateway. The other methods are really more related to WebSphere and traditional data connector access. Note: Why would someone choose the IMS SOAP Gateway over WebSphere? One reason -- if there’s not at present any built-up skills in WebSphere. If WebSphere already exists then going that route would be relatively easy. But building up WebSphere skills just to handle SOAP might be more effort than one desires. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Different Architectural Approaches to CICS and Web Services
WebSphere z/OS HATS CICS BMS (3270) Applications 1 TN3270 Web Service Client 2 EXCI COMMAREA Applications Java SOAP/HTTP SOAP/MQ 3 Suppose you have some existing applications that are in CICS, and you want to expose them as a Web Service. There’s a couple of different ways you can do that: If your application is a BMS 3270 application, you can expose it to the web using an IBM product called HATS (Host Access Transformation Services). HATS provides a way to make the 3270 application available either to browsers (it provides a terminal-to-HTML mapping facility), or to Web Service clients. HATS runs in WebSphere Application Server You can develop your own Web Services application that runs in WebSphere Application Server. The implementation of the service behind the Web Service interface could make use o the JCA connector to access CICS via EXCI. This is accessible as SOAP over HTTP or SOAP over JMS. You can develop a Web Service that runs inside of CICS itself. This Web Service would be accessible via either SOAP over HTTP or SOAP over JMS. The Web Service would then turn and invoke the CICS application using function within CICS designed to do this. Note: this is what we’re going to do in lab. Note: please do not think this picture is the definitive list of all possible ways to access existing CICS applications using Web Services. There are other variations on this theme that provide slightly different approaches. This picture represents three key ones we wished to highlight at this point in time. SOAP/HTTP to Host Access Transformation Services (HATS), an application that runs in WebSphere and provides a web service interface (or browser interface) for BMS (3270) applications in CICS SOAP/HTTP or SOAP/JMS to custom web service running in WebSphere. Web service interface running inside of CICS, and accessed either through HTTP (using CICS HTTP Listener) or through MQ (using a CICS MQ listener) Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web services support in CICS TS Version 3.x and UP
Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Provider vs. Requester -- CICS Can Do Both
We typically consider CICS as a provider of web services: Appl CICS Web Service Client The case where existing (or new) CICS applications are exposed as reusable services. But it can also be a consumer (or requester) of web services: Appl CICS Web Service Client External Service This web service could be anywhere accessible to CICS -- inside your company or outside We need at this point to make sure a key concept is communicated. And it is this: CICS can be a Web Services provider (the typical scenario, and the one we’ll focus on most in this workshop), and it can be a Web Services requester. That is, a program in CICS can call out and invoke a Web Service outside of CICS. This would be done, for example, if the CICS program needed some piece of data that resides in a service outside of CICS. As we said, we’re going to focus on the top scenario. Our focus is going to be exposing existing CICS resources as Web Services. But we wish you to know that CICS applications can call out to a Web Service as well. We’ll focus on the top one. The concepts you’ll see are mostly applicable to both environments. See “CICS Web Services Guide” (SC ) for more. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS as a Web service provider
CICS TS Service Requester Service Provider Server Application Transport HTTP listener Pipeline Client Application WebSphere MQ trigger monitor Handler chain HTTP or WebSphere MQ SOAP body XML Data Mapping Language structure Dynamic install 3. Configure TCPIPSERVICE or WebSphere MQ URIMAP WEBSERVICE PIPELINE Pipeline configuration HFS CSD 1. Develop WSDL or Language structure Server Application 2. Generate Language structure or WSDL WSBIND Pipeline config URIMAP WSDL PIPELINE WSBind WEBSERVICE Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS as a Web service requester
CICS TS Service Requester Service Provider Client Application Pipeline Transport HTTP Server Application WebSphere MQ Handler chain HTTP or WebSphere MQ SOAP body XML Data Mapping Language structure Dynamic install HFS CSD 1. Develop WSDL or Language structure Client Application 2. Generate Language structure or WSDL WSBIND 3. Configure TCPIPSERVICE or WebSphere MQ URIMAP WEBSERVICE PIPELINE Pipeline configuration Pipeline config WSDL PIPELINE WSBind WEBSERVICE Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Tools for developing CICS Web services
CICS Web services assistant  batch utilities which can help you to transform existing CICS applications into Web services and to enable CICS applications to use Web services provided by external providers with the minimum of programming effort. Rational Developer for System z wizards. When use Rational Developer for System z?  CICS Web services assistant does not support OCCURS DEPENDING ON and REDEFINES on data description. `  We allow to map WSDL to existing COBOL ( our Meet-in-the-Middle scenario )  Test Services created IBM has a complementary set of WebSphere tools that make it straightforward to build and deploy new composite applications from new and existing programs. Model One of the key attributes of an SOA is the ability to reuse existing program assets – so the process starts with discovering which program assets you already have that you can reuse in new applications. WebSphere Studio Asset Analyzer helps you discover these hidden assets by determining which programs are good candidates for reuse in Web applications based on the number and type of changes required. Once you understand what business operations you already have coded and available, you can use WebSphere Business Modeller (WBM) to create end-to-end process models that represent key business processes throughout the enterprise – some of which are represented by the assets discovered by WSAA. WBM helps you to understand and transform your business through business modeling, simulation, analysis, and collaboration capabilities. You can use the models you build with WBM to direct your Assemble and Deploy activities for creating composite applications. There are other tools (not shown in the slide) that can help you to reuse your existing applications. Many enterprises use CICS to run their core business, and they have large amounts of reliable and trusted CICS code. CICS Interdependency Analyzer helps you to understand, preserve, evolve and integrate existing CICS applications with new on demand application models. In addition, Asset Transformation Workbench helps you identify the business rules coded within your core applications, and helps in restructuring large applications into more manageable segments and removing dead code. At the end of the modeling phase, you should have a clear idea of the assets that you have available, and where they can be used in the new business processes that you have modeled. The next stage is to create services and assemble them into deployable composite applications. Assemble Rational Developer for zSeries V6 (RDz) includes capabilities that make traditional mainframe development, Web development, and composite application development faster and more efficient. If you use CICS, IMS or WebSphere transactional environments, RDz simplifies the development of new Web user interfaces, traditional terminal interfaces, and back-end business logic. You can wrap your CICS and IMS transactions as Web services and, because so much business is transacted using CICS applications, you can model and reuse core assets from CICS systems with Service Flow Modeller (SFM, part of Rational Developer for zSeries). SFM models and renders CICS transactions of all kinds (3270, comm area) into callable web services. WebSphere Integration Developer V6 (WID) is a new tool for rapid assembly of business solutions that allows you to construct all styles of processes with one programming model based on Business Process Execution Language (BPEL). It requires relatively minimal skills, with easy-to-use authoring tools, so it’s highly productive, and offers features for integrated development, testing of the models. When you’re happy with your composite application model, then you can deploy it to the WebSphere Process Server in the next stage. WID combines well with other development tools from IBM, for example, Rational Application Developer (not shown on the slide) and WebSphere Business Modeler in the Model stage of the process. Deploy WebSphere Process Server V6 (WPS) is the runtime engine that controls the execution of all the Web services created in the previous steps, and drawn together via the WID tool. It is the culmination of discovering assets and business rules, bringing them into a model of a business process, and then plugging individual executable Web service components into the model. WPS deploys the composite applications, and controls the execution of the process, choreographing the individual programs in the process into an automated flow. The runtime process is very flexible -- for example, you can replace, say, a human task (like an approval) with a business rule without changing anything else in the entire solution. This is an extremely powerful capability that fully delivers on the promise of SOA for delivering greater flexibility and responsiveness to your business. This is possible because of the ESB. Message Broker is IBM's advanced ESB, and has the ability to handle connectivity to any application, whether standards-based or not. This means that you can choreograph any of your applications through WPS, making it particularly attractive to the established customer with a large base of trusted existing applications - the typical zSeries customer. The power of the Message Broker is that it can mediate and transform messages in flight to meet the needs of the receiving applications, offloading the mediation processing to a zAAP processor, with an immediate benefit in performance and throughput. Manage WebSphere Business Monitor V6 (WBMonitor) measures the actual performance time of every process and process step. This provides you with accurate information about how the process is executed by and for its users, and the knowledge you need to design the site, up the capacity or any other changes that will benefit the majority of your users. Furthermore, because the information is dynamic, anything of interest –like a group of users having really long response times—can be investigated on the spot by clicking and drilling down on the data. The answers are immediately available and presented in graphical form as well as in columns and text. There are other tools (not shown in the slide) that can help you to reuse your existing applications. The real power of the Business Monitor is the ability to take your real time data and load it back into the Business Modeler for analysis. The ONLY way to optimize your processes is to run simulations and ‘what-if’ scenarios using your REAL business data – and that’s what Business Modeler does, completing the loop of continual improvement, re-using existing assets. Summary IBM, through the WebSphere family, provides a complete set of tools that enable you to build dynamic new flexible processes that capitalize on your existing applications, reusing them in new and profitable ways. All aspects of the development cycle, from identifying what existing assets you can use, through deploying them in new and flexible processes, to monitoring the efficiency of your new processes, are covered with easy-to-use and effective tools. The slide shows a virtuous circle, a beneficial loop of continual improvement based on reuse of existing, trusted assets. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Enterprise Service Tools (EST) Perspective
Goals Provide a single place to work on all Enterprise Service Artifacts  Provide a better environment for Integration between Enterprise Servicing components.  Provide Simple Integration between XML Services for Enterprise (XSE) & Service Flow Modeler (SFM) Limitations Meet-in-the-middle (mapping) scenario is not supported It is supported in General projects It is planned to be supported in EST in the next release (~08/07) Integrating single-service project (SSP) into a service flow (SF) is not reversible SSP still exists and maintains its ability to run the SSP generation wizards If new generation is run, the results will not be reflected in SF (~08/07) It is accessible through the Navigator view but not in the Project explorer view Generation folder content is regenerated every time generation action is run Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

EST Project Explorer 1 Service Flow Projects XSE Related Projects CICS Web Services SOAP for CICS XML Transformation for CICS Project (CICS 4.1) IMS SOAP Gateway IMS Web 2.0 Project BATCH, TSO, USS 2 New on 7.6 Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Enterprise Service Tools (EST)
Lets Focus on Web services for CICS we will cover CICS Service Flow Modeler (SFM) Later… XML Services for Enterprise Web Services for CICS SOAP for CICS XML Transformation for CICS Project IMS SOAP Gateway IMS Web 2.0 BATCH, TSO, z/OS UNIX Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS as a Web service provider - Compiled
CICS TS (Compiled XML Conversion) SOAP Web Service Pipeline SOAP RDz DFH-BODY Program XML Adapter DFHPITL COBOL Compiled Converters DFH-DATA COMMAREA / CONTAINER Target Application Converter Driver COMMAREA / CONTAINER Inbound Converter DFH-DATA Outbound Converter DFH-BODY DFHRPL CICS SYSTEM COMPONENT Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS as a Web service provider - Interpretive
CICS TS (Interpretive XML Conversion) SOAP Web Service Pipeline SOAP Interpretive XML Conversion DFH-BODY Program XML Adapter DFHPITL DFH-DATA COMMAREA / CONTAINER Target Application COMMAREA / CONTAINER ICM Metadata DFH-DATA DFH-BODY DFHRPL CICS SYSTEM COMPONENT Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web Services for CICS: “Interpretive” versus “Compiled”
What is meant by Interpretive XML Conversion? Interpretive XML Conversion refers to using a built-in runtime component for XML (part of CICS) to language structure conversion (after CICS 3.x only). XML parsing done by CICS using CICS Web Services Assistant Java classes What is meant by Compiled XML Conversion? “Compiled XML Conversion” refers to using the COBOL or PL/I converter program generated by RDz for XML to language structure conversion. XML parsing done by the COBOL or PL/I converter generated. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web Services for CICS: “Interpretive” versus “Compiled”
Why use Interpretive XML Conversion? No COBOL compilation or source code management All parsing done by CICS and possibly better performance (?) Why use Compiled XML Conversion? Your CICS program’s language structures are not supported by interpretive. Prefer readable conversion code You need to map existing COBOL to existing WSDL (and don't want to write adapter code) With COBOL Enterprise version after version 4.1 can use z/OS special processors (ZAAP) for XML Parsing. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

XML Services for the Enterprise Web Service Enablement Styles
Bottom-up Top-down Meet in the middle New service WSDL & Converters Existing service description (WSDL) Existing service description (WSDL) Converters / Marshallers/ Aggregators Generates Maps and Generate Generates XML Services for the enterprise tools let you easily adapt COBOL or PL/Ibased business applications so that they become web services – and can both publish and consume Web Services and XML messages. This kind of interface to a called application allows – for example – an internet user to access an existing CICS or IMS application as an open invokable service. The XML Services for the Enterprise or XSE tools consist of: 1. The Web Services enablement wizard that allows a user to generate a new web service interface. Typically, this is called the “bottom up” approach since the existing COBOL application can be at the bottom or endpoint of the Web Services creation process. The XML to COBOL mapping tools that allow a user to map an existing or defined web service interface (WSDL) or an XML data definition to the existing COBOL program interface. Typically this is called the “meet in the middle” approach since the existing Web Service definition “meets” or “maps” to the existing COBOL interface. The Bottom Up scenario enables a user to generate a web service interface or WSDL from an existing COBOL interface. Different users complete different use cases, sequentially or in parallel, to comprise multiple usage scenarios, such as Meet-in-the-middle An existing service interface is implemented by a sequence flow consuming CICS applications Bottom-up Create a new service interface for a sequence flow consuming CICS applications Top-down scenario is not supported in the literal sense SF does not generate stubs for new back-end applications from web service definitions. Other non-linear scenarios possible New Business App & Converters / Marshallers Existing COBOL or PL/I Programs Existing Business Apps Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

XML Services for the Enterprise
Web Services Enablement wizard (bottom-up) Rational Developer for System z Generates Web Service interface from existing COBOL or PL/I program Bottom-up approach since COBOL or PL/I at the bottom (base) of the creation process Web Services Enablement wizard (top-down) Rational Developer for System z Generates COBOL or PL/I (*) Program and copybooks or includes (*) from existing WSDL Web Services Enablement wizard (meet-in-the-middle) Rational Developer for System z Maps existing WSDL or XML to existing COBOL or PL/I program. Meet-in-the-middle since Web Services/XML definition “meets” or maps to the existing COBOL or PL/I interface. XML Services for the Enterprise tools let you easily adapt COBOL-based business applications so that they become web services and can process and produce XML messages. This new kind of interface to a called application allows (for example) an Internet user to access an existing CICS or IMS application. The tools also can help you to embed a COBOL application in a larger system that uses XML for data interchange. The XML Services for the Enterprise tools consist of: The Web Services Enablement wizard that allows to generate a new web service interface. Typically, this is called "bottom-up" approach since the existing COBOL application is at the "bottom" of the new Web services creation process. This used to be called XML Enablement wizard. The XML to COBOL mapping tools that allow to map an existing web service interface or an XML data definition to the existing COBOL program. Typically, this is called "meet-in-the-middle" approach, since the exiting Web services definition "meets" or "maps" to the existing COBOL interface. The Batch processor that allows to run generate the web service interface in unattended ("batch") mode. The Batch processor currently supports the "bottom-up" Web services creation. The functionality of the Batch processor is equivalent to those of the Web Services Enablement wizard described above. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Example: Web Services for CICS 3.x (Compiled)
Input Converter Input XML schema definition (.xsd) Output Converter WSDL WSBIND Converter Driver Output XML schema definition (.xsd) RDz XML Enablement Copybook or complete program There's been requests from IBM's enterprise customers to support the processing of XML messages from COBOL. XML Enablement for the Enterprise lets you easily adapt COBOL-based business applications so that they can process and produce XML messages into native COBOL data, one to transform COBOL data into an XML output message. The converter programs use the new high-performance XML parsing capabilities of the IBM Enterprise COBOL compiler. The tool also generates a template COBOL program that shows how to invoke the converter along with the existing application. By using XML Enablement for the Enterprise, you can use data produced by existing COBOL programs to communicate with systems that use XML for data interchange, including systems based on Web services. The XML parsing is done using SAX. Original Program unchanged Single Services and IBM Rational Developer for System z

Web Services for CICS 3.x Example Bottom-up Compiled XML Conversion - 1 of 2 Web service WSDL & Converters 1 2 Existing COBOL or PL/I XML Services for the enterprise tools let you easily adapt COBOL or PL/I based business applications so that they become web services – and can both publish and consume Web Services and XML messages. This kind of interface to a called application allows – for example – an internet user to access an existing CICS or IMS application as an open invokable service. The XML Services for the Enterprise or XSE tools consist of: 1. The Web Services enablement wizard that allows a user to generate a new web service interface. Typically, this is called the “bottom up” approach since the existing COBOL application can be at the bottom or endpoint of the Web Services creation process. The XML to COBOL mapping tools that allow a user to map an existing or defined web service interface (WSDL) or an XML data definition to the existing COBOL program interface. Typically this is called the “meet in the middle” approach since the existing Web Service definition “meets” or “maps” to the existing COBOL interface. The Bottom Up scenario enables a user to generate a web service interface or WSDL from an existing COBOL interface. Different users complete different use cases, sequentially or in parallel, to comprise multiple usage scenarios, such as Meet-in-the-middle An existing service interface is implemented by a sequence flow consuming CICS applications Bottom-up Create a new service interface for a sequence flow consuming CICS applications Top-down scenario is not supported in the literal sense SF does not generate stubs for new back-end applications from web service definitions. Other non-linear scenarios possible Bottom-up Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS Web Services Compiled Conversion – Example – 2 of 2
RDz XML Enablement (Bottom-up) 5 3 4  Select language structures from a complete COBOL program or a COBOL copybook included by the program  Syntax check of COBOL source during import. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Example: Web Services for CICS 3.x (Interpretive) WSDL RDz XML Enablement Copybook or complete program No COBOL Converter is created There's been requests from IBM's enterprise customers to support the processing of XML messages from COBOL. XML Enablement for the Enterprise lets you easily adapt COBOL-based business applications so that they can process and produce XML messages into native COBOL data, one to transform COBOL data into an XML output message. The converter programs use the new high-performance XML parsing capabilities of the IBM Enterprise COBOL compiler. The tool also generates a template COBOL program that shows how to invoke the converter along with the existing application. By using XML Enablement for the Enterprise, you can use data produced by existing COBOL programs to communicate with systems that use XML for data interchange, including systems based on Web services. The XML parsing is done using SAX. Original Program unchanged WSBIND Single Services and IBM Rational Developer for System z

Web Services for CICS 3.x Example Bottom-up Interpretive XML Conversion Web service WSDL & Converters 1 2 Existing COBOL or PL/I XML Services for the enterprise tools let you easily adapt COBOL or PL/I based business applications so that they become web services – and can both publish and consume Web Services and XML messages. This kind of interface to a called application allows – for example – an internet user to access an existing CICS or IMS application as an open invokable service. The XML Services for the Enterprise or XSE tools consist of: 1. The Web Services enablement wizard that allows a user to generate a new web service interface. Typically, this is called the “bottom up” approach since the existing COBOL application can be at the bottom or endpoint of the Web Services creation process. The XML to COBOL mapping tools that allow a user to map an existing or defined web service interface (WSDL) or an XML data definition to the existing COBOL program interface. Typically this is called the “meet in the middle” approach since the existing Web Service definition “meets” or “maps” to the existing COBOL interface. The Bottom Up scenario enables a user to generate a web service interface or WSDL from an existing COBOL interface. Different users complete different use cases, sequentially or in parallel, to comprise multiple usage scenarios, such as Meet-in-the-middle An existing service interface is implemented by a sequence flow consuming CICS applications Bottom-up Create a new service interface for a sequence flow consuming CICS applications Top-down scenario is not supported in the literal sense SF does not generate stubs for new back-end applications from web service definitions. Other non-linear scenarios possible Bottom-up Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS Web Services Interpretive Conversion - Example
1 RDz XML Enablement (Bottom-up) 4 No COBOL Converter is created 5 3  Select language structures from a complete COBOL program or copybook included by the program  Syntax check of COBOL source during import. 2 Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web Services Enablement wizard (bottom-up) Rational Developer for System z Generates Web Service interface from existing COBOL or PL/I program Bottom-up approach since COBOL or PL/I at the bottom (base) of the creation process Web Services Enablement wizard (top-down) Rational Developer for System z Generates COBOL or PL/I (*) Program and copybooks or includes (*) from existing WSDL Web Services Enablement wizard (meet-in-the-middle) Rational Developer for System z Maps existing WSDL or XML to existing COBOL or PL/I program. Meet-in-the-middle since Web Services/XML definition “meets” or maps to the existing COBOL or PL/I interface. (*) - XML Services for the Enterprise tools let you easily adapt COBOL-based business applications so that they become web services and can process and produce XML messages. This new kind of interface to a called application allows (for example) an Internet user to access an existing CICS or IMS application. The tools also can help you to embed a COBOL application in a larger system that uses XML for data interchange. The XML Services for the Enterprise tools consist of: The Web Services Enablement wizard that allows to generate a new web service interface. Typically, this is called "bottom-up" approach since the existing COBOL application is at the "bottom" of the new Web services creation process. This used to be called XML Enablement wizard. The XML to COBOL mapping tools that allow to map an existing web service interface or an XML data definition to the existing COBOL program. Typically, this is called "meet-in-the-middle" approach, since the exiting Web services definition "meets" or "maps" to the existing COBOL interface. The Batch processor that allows to run generate the web service interface in unattended ("batch") mode. The Batch processor currently supports the "bottom-up" Web services creation. The functionality of the Batch processor is equivalent to those of the Web Services Enablement wizard described above. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

XML Services for the Enterprise Example Top-down – Creating Service Requestor – 1 of 2 Top-down Existing service description WSDL 2 1 COBOL or PL/I Program & Copybooks or Includes XML Services for the enterprise tools let you easily adapt COBOL based business applications so that they become web services – and can both publish and consume Web Services and XML messages. This kind of interface to a called application allows – for example – an internet user to access an existing CICS or IMS application as an open invokable service. The XML Services for the Enterprise or XSE tools consist of: 1. The Web Services enablement wizard that allows a user to generate a new web service interface. Typically, this is called the “bottom up” approach since the existing COBOL application can be at the bottom or endpoint of the Web Services creation process. The XML to COBOL mapping tools that allow a user to map an existing or defined web service interface (WSDL) or an XML data definition to the existing COBOL program interface. Typically this is called the “meet in the middle” approach since the existing Web Service definition “meets” or “maps” to the existing COBOL interface. The Bottom Up scenario enables a user to generate a web service interface or WSDL from an existing COBOL interface. Different users complete different use cases, sequentially or in parallel, to comprise multiple usage scenarios, such as Meet-in-the-middle An existing service interface is implemented by a sequence flow consuming CICS applications Bottom-up Create a new service interface for a sequence flow consuming CICS applications Top-down scenario is not supported in the literal sense SF does not generate stubs for new back-end applications from web service definitions. Other non-linear scenarios possible Full validation of WSDL on import Conversion type is always Interpretive Generates COBOL or PL/I skeleton for Web Service Requestor Or Web Service Provider Generate Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

XML Services for the Enterprise – COBOL example Top-down – Creating Service Requestor – 2 of 2 5 4 6 3 XML Services for the enterprise tools let you easily adapt COBOL based business applications so that they become web services – and can both publish and consume Web Services and XML messages. This kind of interface to a called application allows – for example – an internet user to access an existing CICS or IMS application as an open invokable service. The XML Services for the Enterprise or XSE tools consist of: 1. The Web Services enablement wizard that allows a user to generate a new web service interface. Typically, this is called the “bottom up” approach since the existing COBOL application can be at the bottom or endpoint of the Web Services creation process. The XML to COBOL mapping tools that allow a user to map an existing or defined web service interface (WSDL) or an XML data definition to the existing COBOL program interface. Typically this is called the “meet in the middle” approach since the existing Web Service definition “meets” or “maps” to the existing COBOL interface. The Bottom Up scenario enables a user to generate a web service interface or WSDL from an existing COBOL interface. Different users complete different use cases, sequentially or in parallel, to comprise multiple usage scenarios, such as Meet-in-the-middle An existing service interface is implemented by a sequence flow consuming CICS applications Bottom-up Create a new service interface for a sequence flow consuming CICS applications Top-down scenario is not supported in the literal sense SF does not generate stubs for new back-end applications from web service definitions. Other non-linear scenarios possible Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web Services Enablement wizard (bottom-up) Rational Developer for System z Generates Web Service interface from existing COBOL or PL/I program Bottom-up approach since COBOL or PL/I (*) at the bottom (base) of the creation process Web Services Enablement wizard (top-down) Rational Developer for System z Generates COBOL or PL/I (*) Program and copybooks or includes (*) from existing WSDL Web Services Enablement wizard (meet-in-the-middle) Rational Developer for System z Maps existing WSDL or XML to existing COBOL or PL/I program. Meet-in-the-middle since Web Services/XML definition “meets” or maps to the existing COBOL or PL/I interface. XML Services for the Enterprise tools let you easily adapt COBOL-based business applications so that they become web services and can process and produce XML messages. This new kind of interface to a called application allows (for example) an Internet user to access an existing CICS or IMS application. The tools also can help you to embed a COBOL application in a larger system that uses XML for data interchange. The XML Services for the Enterprise tools consist of: The Web Services Enablement wizard that allows to generate a new web service interface. Typically, this is called "bottom-up" approach since the existing COBOL application is at the "bottom" of the new Web services creation process. This used to be called XML Enablement wizard. The XML to COBOL mapping tools that allow to map an existing web service interface or an XML data definition to the existing COBOL program. Typically, this is called "meet-in-the-middle" approach, since the exiting Web services definition "meets" or "maps" to the existing COBOL interface. The Batch processor that allows to run generate the web service interface in unattended ("batch") mode. The Batch processor currently supports the "bottom-up" Web services creation. The functionality of the Batch processor is equivalent to those of the Web Services Enablement wizard described above. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Meet-in-the-Middle - XML to COBOL Mapping example
XML documents do not identically match COBOL data items Derived from sources other than target COBOL data structure Mergers and Acquisitions “Not-quite-compatible” program interfaces Define mappings between WSDL, XML, XSD or COBOL data items Generate converter and driver from mapping XML to COBOL Mapping tools allow you to enable existing COBOL applications to process and produce XML documents when the XML documents do not identically match the COBOL data items in terms of names or even data types. This situation occurs, for example, when the XML documents are derived from sources other than the target COBOL data structure. After defining the mappings, you can generate converter and driver programs. The converters are generated in COBOL and their function is to transform the content of the mapped XML elements to the content of COBOL data items and the content of COBOL data items to the content of mapped XML elements. A sample COBOL converter driver program is also generated that illustrates how to invoke the converters in conjunction with the existing COBOL program. These tools are very useful when, for example, company A acquires or merges with one or more other companies, and intends to merge and consolidate various parts of the enterprise information systems (EIS) resulting from the merger or acquisition. The interfaces between various enterprise applications most likely do not precisely match. Also, these tools are very useful when an existing enterprise application is required to process an XML document described by a schema originating from a third party such as a standards committee. The XML to COBOL mapping editor allows you to map one or more existing source XML documents to an existing target COBOL data structure and inversely, from a source COBOL data structure to an existing target XML document. Specifically, elements of the XML documents can be mapped visually to COBOL data items. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

1 CICS Web services 3.x Example Meet in the middle – 1 of 4 2 Existing service description WSDL Converters / Marshallers/ Aggregators 3 4 XML Services for the enterprise tools let you easily adapt COBOL based business applications so that they become web services – and can both publish and consume Web Services and XML messages. This kind of interface to a called application allows – for example – an internet user to access an existing CICS or IMS application as an open invokable service. The XML Services for the Enterprise or XSE tools consist of: 1. The Web Services enablement wizard that allows a user to generate a new web service interface. Typically, this is called the “bottom up” approach since the existing COBOL application can be at the bottom or endpoint of the Web Services creation process. The XML to COBOL mapping tools that allow a user to map an existing or defined web service interface (WSDL) or an XML data definition to the existing COBOL program interface. Typically this is called the “meet in the middle” approach since the existing Web Service definition “meets” or “maps” to the existing COBOL interface. The Bottom Up scenario enables a user to generate a web service interface or WSDL from an existing COBOL interface. Different users complete different use cases, sequentially or in parallel, to comprise multiple usage scenarios, such as Meet-in-the-middle An existing service interface is implemented by a sequence flow consuming CICS applications Bottom-up Create a new service interface for a sequence flow consuming CICS applications Top-down scenario is not supported in the literal sense SF does not generate stubs for new back-end applications from web service definitions. Other non-linear scenarios possible Existing Business Apps Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

5 CICS Web services 3.x Meet in the middle – 2 of 4 6 RDz 7 8 XML to COBOL Mapping tools allow you to enable existing COBOL applications to process and produce XML documents when the XML documents do not identically match the COBOL data items in terms of names or even data types. This situation occurs, for example, when the XML documents are derived from sources other than the target COBOL data structure. After defining the mappings, you can generate converter and driver programs. The converters are generated in COBOL and their function is to transform the content of the mapped XML elements to the content of COBOL data items and the content of COBOL data items to the content of mapped XML elements. A sample COBOL converter driver program is also generated that illustrates how to invoke the converters in conjunction with the existing COBOL program. These tools are very useful when, for example, company A acquires or merges with one or more other companies, and intends to merge and consolidate various parts of the enterprise information systems (EIS) resulting from the merger or acquisition. The interfaces between various enterprise applications most likely do not precisely match. Also, these tools are very useful when an existing enterprise application is required to process an XML document described by a schema originating from a third party such as a standards committee. The XML to COBOL mapping editor allows you to map one or more existing source XML documents to an existing target COBOL data structure and inversely, from a source COBOL data structure to an existing target XML document. Specifically, elements of the XML documents can be mapped visually to COBOL data items. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS Web services 3.x Meet in the middle – 3 of 4 9 RDz 10 XML to COBOL Mapping tools allow you to enable existing COBOL applications to process and produce XML documents when the XML documents do not identically match the COBOL data items in terms of names or even data types. This situation occurs, for example, when the XML documents are derived from sources other than the target COBOL data structure. After defining the mappings, you can generate converter and driver programs. The converters are generated in COBOL and their function is to transform the content of the mapped XML elements to the content of COBOL data items and the content of COBOL data items to the content of mapped XML elements. A sample COBOL converter driver program is also generated that illustrates how to invoke the converters in conjunction with the existing COBOL program. These tools are very useful when, for example, company A acquires or merges with one or more other companies, and intends to merge and consolidate various parts of the enterprise information systems (EIS) resulting from the merger or acquisition. The interfaces between various enterprise applications most likely do not precisely match. Also, these tools are very useful when an existing enterprise application is required to process an XML document described by a schema originating from a third party such as a standards committee. The XML to COBOL mapping editor allows you to map one or more existing source XML documents to an existing target COBOL data structure and inversely, from a source COBOL data structure to an existing target XML document. Specifically, elements of the XML documents can be mapped visually to COBOL data items. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS Web services 3.x Meet in the middle – 4 of 4 11 12 13 XML Services for the enterprise tools let you easily adapt COBOL based business applications so that they become web services – and can both publish and consume Web Services and XML messages. This kind of interface to a called application allows – for example – an internet user to access an existing CICS or IMS application as an open invokable service. The XML Services for the Enterprise or XSE tools consist of: 1. The Web Services enablement wizard that allows a user to generate a new web service interface. Typically, this is called the “bottom up” approach since the existing COBOL application can be at the bottom or endpoint of the Web Services creation process. The XML to COBOL mapping tools that allow a user to map an existing or defined web service interface (WSDL) or an XML data definition to the existing COBOL program interface. Typically this is called the “meet in the middle” approach since the existing Web Service definition “meets” or “maps” to the existing COBOL interface. The Bottom Up scenario enables a user to generate a web service interface or WSDL from an existing COBOL interface. Different users complete different use cases, sequentially or in parallel, to comprise multiple usage scenarios, such as Meet-in-the-middle An existing service interface is implemented by a sequence flow consuming CICS applications Bottom-up Create a new service interface for a sequence flow consuming CICS applications Top-down scenario is not supported in the literal sense SF does not generate stubs for new back-end applications from web service definitions. Other non-linear scenarios possible Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Miscellaneous…. Application Deployment Manager integration with Web Service for CICS wizard  Batch Processor Support for Bottom-UP and Top-Down Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Application Deployment Manager integration with Web Service for CICS wizard User will be able to “define, install, scan, re-install, re-scan and new copy” CICS resources without opening a CICS terminal session Supports Bottom-up, Meet in the Middle and Top-down For PLI, this is applicable for Bottom-up Interpretive XML conversion only 1 3 … Will be enabled, if the z/OS Unix File Subsystem with the same server as the CICS connection, is connected. Takes the user to the Connections section of preference page. The user needs to click Refresh to see the new target CICS region(s) that are created this way 2 Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web Services Batch processor
Major U.S. brokerage firm saved 5 person years of development effort on 600 services by cutting time to generate and maintain a single service from 2 days to 2 hours “Engineers hate GUIs. We cannot imagine sitting at a GUI and expect to efficiently deploy hundreds of configurations” - SOA and Security Architect involved in web services. One user built their own tooling around CICS utility (DFHWS2LS) because he did not know that Rational Developer for System z had the Batch processor Use a scriptable command-line interface when generating artifacts for a large number of Web service provider or requestor implementations Recreate the resources generated previously without having to remember and specify all of the options and selections for the Launch pad and Web service Wizard. Repeatable Generation support in EST Single-service projects requires a way to record the specified options and selections. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Rational Developer for System z wizard to Test Web Services

Test Using Rational Developer for zSeries Web Services Explorer
Web Services Test explorer Test Using Rational Developer for zSeries Web Services Explorer WSDL There's been requests from IBM's enterprise customers to support the processing of XML messages from COBOL. XML Enablement for the Enterprise lets you easily adapt COBOL-based business applications so that they can process and produce XML messages into native COBOL data, one to transform COBOL data into an XML output message. The converter programs use the new high-performance XML parsing capabilities of the IBM Enterprise COBOL compiler. The tool also generates a template COBOL program that shows how to invoke the converter along with the existing application. By using XML Enablement for the Enterprise, you can use data produced by existing COBOL programs to communicate with systems that use XML for data interchange, including systems based on Web services. The XML parsing is done using SAX. Test the Web Services created invoking CICS via HTTP Single Services and IBM Rational Developer for System z

Some of the New Features on Version 7.6
CICS 4.1 Integration and new capabilities XML Transformation for CICS CICS MTOM Support for Bottom Up COBOL and PL/I Interpretive XML Conversion (CICS 3.x and CICS 4.1). Multi Container CICS web services (CICS 4.1) Single Services and IBM Rational Developer for System z

XML Transformation for CICS 4.1
New project category in EST projects XSDBind Deployment bundle Bundle manifest Single Services and IBM Rational Developer for System z

Generation for MTOM/XOP CICS transactions
Generation of web services for CICS MTOM/XOP, common with CICS and DataPower Aids in offloading MIPS for Web Services DataPower WS-Consumers IBM B X Potential new path WS-Consumers B Binary data X X XML data Existing path Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS MTOM Support (CICS 3.x and CICS 4.1).
The scenario “Create New MTOM/XOP Service Interface (bottom-up)” is now available when creating a new Web Services for CICS single-service project. The generation Wizard begins with a simplified language structure page; granular item selection does not apply for MTOM. Single Services and IBM Rational Developer for System z

Multi Container CICS web services – for CICS 4.1
In the “Create New Service Interface (bottom-up) interpretive conversion” scenario, CDD shows up as a new program interface. Upon its selection, the user is required to specify the location of CDD for the request/response. Single Services and IBM Rational Developer for System z

Session summary – We discussed..
SOAP, XML, WSDL and Web Services Overview Rational Developer for System z and Single Web Service Enablement Styles Web Service Request into IMS Single service support using CICS TS Version 2.2 or 2.3 Single service support using CICS TS Version 3.2 XML to COBOL Mapping (Meet in the middle) Batch Processor Support New Features on Version 7.6  You are able now to play with the tool… Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

You can use this chart to show that the formal presentation is finished and to open up a Question and Answer session. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Moving legacy COBOL/CICS/VSAM to iPhone
Optional “Demo” Breaker Slide Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Existing COBOL/CICS 3270 Application z/OS Texas ZSERVEROS EXEC CICS READ FILE (‘POTVSAM') INTO (WORK) EXEC CICS RETURN EXEC CICS LINK LAB3POT VSAM COBOL Client COBOL Server Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Ajax Proxy and EGL Rich UI code
Invoking CICS Web services from iPhone Using COBOL/CICS/VSAM System z Ajax Proxy and EGL Rich UI code on Application Server z/OS CICS EXEC CICS READ FILE (‘POTVSAM') INTO (WORK) EXEC CICS RETURN Existing CICS/COBOL COBOL Wrapper Generated by RDz Optional “Demo” Breaker Slide WSDL VSAM zserveros.demos.ibm 8 Minutes More at: Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

z/OS Texas PART #1. Create a CICS Web Service and WSDL using Rational Developer for System z (RDz) PART #2. Create a Web 2.0 Interface using Rational Developer for System z with EGL (RDz/EGL) EXEC CICS READ FILE (‘POTVSAM') INTO (WORK) EXEC CICS LINK LAB3POT VSAM COBOL Client COBOL Server z/OS Texas EXEC CICS READ FILE (‘POTVSAM') INTO (WORK) VSAM COBOL Server Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Invoking CICS Web services from iPhone (Real iPhone screen captures) Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

BACKUP Rational Developer for System z Single Service creation for existing CICS or IMS Applications * Those slides are optional, you might want to add some of these to the Single service Creation in case you are interested in more details…. Click here for the next session. Go to LAB3 You can use this chart to show that the formal presentation is finished and to open up a Question and Answer session. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web Services are a good start…
Turn this … …into this (web services). Service Service Service Service Service Service Service = Interface = Application = Interface = Service Rich business abstractions describe the application interface Decouples the interfaces from the business applications The number and complexity of the interfaces is reduced Business applications and their interfaces become reusable ** Main Point: Midmarket companies have built many custom connections between applications, and have started using Web Services So how does web services decouple the interfaces from their applications? 1) It uses a programming model that allows a rich abstraction of both the business app and the interface. 2) By abstracting the interfaces, they can be clearly separated from the business applications. 3) This enables you to reduce the number and complexity of those interfaces and. 4) It allows you to reuse both the interfaces and the business applications. The problem is that you still have to build, find, and manage all of those interfaces somewhere. Linkage: There is still room for further improvement. But separate connection points still leaving bloated interfaces …. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

The Enterprise Service Bus shrinks those interfaces further
Turn this (web services)… …into this (SOA) Service Service Service Service Service Service Enterprise Service Bus Service Service Service Service Service Service Service Service = Interface = Service = Interface = Service Decouples the point-to-point connections from the interfaces Allows for dynamic selection, substitution, and matching Enables more flexible coupling and decoupling of the applications Enables you to find both the applications and the interfaces for re-use ** Main Point: Shrinking interfaces further enables greater reuse, flexibility and business responsiveness. The ESB shrinks the interfaces further. 1) It virtualizes the interface, or in other words, it decouples the point-to-point connections from the interfaces themselves. 2) The interfaces are put into a third party broker which helps you manage the interfaces better. 3) The enables faster and more flexible coupling and decoupling of applications. 4) Because you can find all of the applications and the interfaces, you can then reuse both. Reconfigure services to change how your company operates - e.g. increase the level of reported loss before a claims adjuster must review, or increase the loan amount that loan officers are allowed to approve without going to a branch manager. Linkage: Let’s look in more detail at why you should care about SOA for business flexibility. RESULT  Greater Business Responsiveness Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

IMS Enterprise Suite SOAP Gateway
Runs on multiple platforms(*), it acts as a front-end SOAP handler. It provides the web services interface and forwards XML body back to IMS. IMS Web Service Client IMS Connect XML Adapter and Converter OTMA Appl XML Body Windows XP, Windows 2000, zLinux, AIX Process here bears a bit more exploration Application COBOL Copybook WSDL File Used by the SOAP Gateway. This is how the GW knows about the various IMS applications exposed as services Correlator File Also used by the SOAP Gateway … this is what relates messages to/from IMS with the WSDL so the SOAP envelope can be built. XML converter driver code Used in IMS Connect to convert XML to application data and back. Optional … The SOAP Gateway function is something that runs on a non-z/OS platform (Windows XP or 2000, AIX or z/Linux). It’s role is to act as an HTTP and SOAP handler out front of IMS. It receives the SOAP request, strips the request body out of the SOAP envelope and passes that back to IMS Connect for processing. The message is still in XML format at this time, so more handling is required. IMS Connect receives the message and then prepares to pass it back to IMS (via OTMA). Here a decision needs to be made -- should the XML be converted by IMS connect? Or passed back to the application for conversion? If converted by the IMS Connect function then the XML Adapter and Converter function needs to be employed. If passed back to the application, then the application needs to be prepared to do XML conversion. We’ll look at this process in a bit more detail next. To make this work you need some key components that are produced by WebSphere Developer for z/Series: The WSDL file -- this is used by the SOAP Gateway to understand this exposed web service. Any single instance of the SOAP Gateway can handle multiple services in the backend, so having all the WSDL files allows the SOAP gateway to understand what services it supports. The Correlator File -- also used by the SOAP Gateway, this allows the SOAP Gateway to relate messages it sees coming back from IMS to the specific web service it came from. The XML converter driver code -- if used (it is optional), it is what gets invoked by IMS Connect to convert the data contained in XML to the format that can be handled by IMS via OTMA. The same happens in reverse -- when the data comes back from IMS, the converter driver re-formats the XML response and passes it back to the SOAP Gateway. As mentioned, the XML converter function is optional. Let’s explore that component a bit more closely. Rational Developer for System z (*) including z/OS, Microsoft Windows XP, Windows 2000, AIX, Linux for System z, and z/OS (z/OS support is for IMS Enterprise Suite SOAP Gateway and IMS SOAP Gateway Version 10.1 only). Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

XML Adapter and the XML Converter Driver and IMS
In all cases the Gateway is going to pass XML back to IMS Connect. Two choices: XML handled by converter, or XML handled by the application. IMS OTMA Appl IMS Connect XML Adapter and Converter IMS Connect Service Converter Driver XML Adapter Converter driver code produced by RDz IMS Connect Config: ADAPTER=(XML=Y | N) Option to use XML Adapter is set at the IMS Connect level. If on, then XML converters expected. If off, then XML sent to application. You may have multiple IMS Connect Regions -- one that uses XML Adapter, another that does not. SOAP Gateway will route to one or other based on WSDL and Correlator files for application request It knows what XML converter to invoke based on information in header created by SOAP Gateway The SOAP Gateway will, in all cases, pass XML back to IMS Connect. The SOAP envelope will be stripped out, but the XML body will be passed back. That XML needs to be handled by someone, and the choice is yours -- have it handled by a new feature called the XML Adapter and Converter, or have it handled by your application. The choice to enable or not enable the XML converter is done at the IMS Connect level. If you turn it on (ADAPTER=(XML=Y) then IMS Connect expects to invoke some converter driver code. If not enabled, then IMS Connect expects to pass XML back to your application. Let’s say you have it enabled. Then IMS Connect is going to look to invoke XML converter code. That code is something produced by RDz and is compiled into load libraries accessible by IMS Connect. IMS Connect knows which converter driver to invoke based on information in the header created by the SOAP Gateway, which is then passed back to IMS Connect. IMS Connect reads the converter driver information and then passes the XML to that converter. When the conversion is done, the data is then passed back to your IMS application through OTMA. On the way back, the response is again passed through the XML converter driver, which formats up the XML and passes it back to the SOAP Gateway, which wrappers it in a SOAP envelope and passes it back to the client. Why would you use one vs. the other? It really has to do with the impact to the application in the background. If you employ the XML converter you don’t need to touch your application -- it remains unchanged. But if you don’t use the XML converter, then your application is going to be expected to handle the XML. So you’d have to make sure your application is prepared to do that. So you have two options: XML Adapter/Converter -- no changes to your application XML handled by your application -- may require changes to application Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Web services support in CICS TS Version 2.2 or 2.3

What is the SOAP for CICS Feature?
No Charge feature for both CICS TS V2.2 and V2.3 Implements the functionality of a SOAP 1.1 processing node Supports HTTP or WebSphere MQ transports Allows CICS applications to be Web service providers For language structure applications, a message adapter is needed to convert from XML (built by Rational Developer for System z) Allows CICS applications to be Web service provider Applications can flow SOAP messages to a remote server Programs in Assembler, C and PL/I also supported XML/HTTP XML/WMQ Transport SOAP pipeline Message Adapter Business Logic Request Body Response SOAP Client What do I need as well as the Feature? CICS TS V2.2 or later With the PTFs for APARs PQ76073 & PQ72017 applied If using WebSphere MQ transport, BTS datasets required for Container support CICS must be configured to support the Language Environment runtime Language Environment requires the following PTFs in order to enable the XML parser: For OS/390 V2.10, PTF UQ61947 for APAR PQ53267 and PTF UQ62918 for APAR PQ57816 For z/OS V1.2, PTF UQ62894 for APAR PQ57008 For z/OS V1.3, PTF UQ67085 for APAR PQ60925 For z/OS V1.4, PTF UQ70042 for APAR PQ66155 Enterprise COBOL or PL/I V3 Not specifically required by the Feature, but applications will need to parse XML Created by RDz Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS 3.x and UP Web Services support overview
SOAP server admin. --Configure CICS SOAP Pipeline *  Generated by RDz z/OS HTTP/SOAP or MQ CICS Web Service Client (Java, .NET, SAP,…) CICS SOAP PIPELINE COBOL APP CICS Web Service Client-Side Proxy Deploy (per CICS described procedure) WSBind File * XML COBOL Converters * (Rational or .Net) Generate COBOL Copybook WSDL & XSD * XML Services for the Enterprise generated artefacts “plug” into CICS 3.x runtime. Complements CICS-provided conversion for COBOL types and constructs which are not covered natively by CICS Legend: Execution (runtime) Rational Developer generates/uses Generation (development) Java or .Net developer Generates client proxy from WSDL (Writes end client app if it does not exist) Java or Web Service developer -- generate WSDL, WSBind file & converters (from the copybook) -- Publish to UDDI/repo (optional) System programmer compile and link the XML COBOL converters - Deploy WSDL and WSBind to CICS Web Services Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

WebSphere Service Registry and Repository (WSRR) integration
After installing the WSRR Eclipse user interface product on top of Rational Developer for System z, the context menu for a Web Services Description Language (WSDL) document in EST project explorer shows the actions shown in the picture User will be able to publish the service into WSRR from EST project. User will be able to import the service (along with any dependent XSDs) from WSRR. 1 2 WSRR is an industry leading solution that enables users to publish, find, enrich, manage and govern services and policies in SOA world. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS MTOM Support Value (CICS 3.x/4.1)
When using XSE to enable CICS applications as Web services, XML Schemas (XSDs) are derived from the I/O language structures of the application and are included in the generated Web service description (WSDL) file. In order to meet the binary interface of a CICS application and the SOAP or REST interface of a Web client, XML instance documents must be converted to/from language structures at runtime. Currently, whether Compiled or Interpretive XML conversion is used, XML conversion executes on the z/OS Host processor. Significant CPU time and memory are required to perform XML conversion and, as a result, IBM clients are interested in offloading this CPU-intensive task. What about XMLSS (z/OS XML System Services Parser) offload? While the XMLSS parser can be offloaded to zAAP, XML parsing is just one part of XML conversion. For example, XMLSS is not at all involved with XML generation. To fully offload XML conversion, possibly to the middle-tier, one can employ MTOM/XOP. Single Services and IBM Rational Developer for System z

CICS MTOM Support Scenario example
Using MTOM/XOP, a Web service requester and provider can exchange the actual binary/native request and response language structures without having to use an intermediate XML representation of language data. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Batch Processor Support Example
3 1 2 Use a scriptable command-line interface when generating top-down artifacts for a large number of Web service provider or requestor implementations Recreate the resources generated previously without having to remember and specify all of the options and selections for the Launch pad and top-down Web service Wizard. Repeatable Generation support in EST Single-service projects requires a way to record the specified options and selections. Therefore the Batch Processor has been extended to support a top-down variant of generation properties files Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS Listens for Web Services Requests
(1 of 6 ) CICS TS V3 TCPIPSERVICE CSOL SOAP message Service Requester TCPIPService definition tells CICS to listen Systems Programmer defined Tells CICS what port to listen on (example 9036/9046 in our labs) What z/OS host address (example zserveros.demos.ibm.com) If encryption should be used (SSL) Receiving message is performed under the CSOL transaction (can be changed by Systems Programmer) The next series of slides builds on each other and can be used to explain what CICS does (plus what you have to define or build) to support Web services. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS Decides what to do with the Request
CICS Listens for Web Services Requests… (2 of 6 ) CICS TS V3 TCPIPSERVICE CSOL SOAP message CWXN Service Requester matching URIMAP URIMAP CICS finds a match on endpoint ‘path’ based on URIMAP resource definitions Defined by Systems Programmer, and can be dynamically defined by CICS CICS returns an error if a match on URIMAP is not found Work is performed under the CWXN transaction (by default) This is part of a series of slides that build on each other and can be used to explain what CICS does (plus what you have to define or build) to support Web services. Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

URIMAP points to Web Service definition
(3 of 6 ) TCPIPSERVICE CICS TS V3 CSOL SOAP message CWXN Service Requester HFS matching URIMAP URIMAP WSDL WSBIND WEBSERVICE This is part of a series of slides that build on each other and can be used to explain what CICS does (plus what you have to define or build) to support Web services. Messages can optionally be validated (to verify they comply with the rules in the WSDL) WEBSERVICE Definition points to WSBIND and WSDL (optional) Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

URIMAP points to Pipeline
(4 of 6 ) TCPIPSERVICE CICS TS V3 CSOL SOAP message CWXN Service Requester HFS matching URIMAP pipeline config URIMAP WSDL PIPELINE WSBind This is part of a series of slides that build on each other and can be used to explain what CICS does (plus what you have to define or build) to support Web services. WEBSERVICE PIPELINE resource definition points to a Pipeline Configuration File Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Pipeline Configuration File
(5 of 6 ) CICS TS V3 TCPIPSERVICE CSOL SOAP message CPIH CWXN Service Requester Pipeline HFS matching URIMAP handlers pipeline config URIMAP handlers WSDL PIPELINE handlers WSBind This is part of a series of slides that build on each other and can be used to explain what CICS does (plus what you have to define or build) to support Web services. WEBSERVICE ??? The Pipeline Configuration File specifies a list of optional programs (called Handlers) that can look at or massage the message before it reaches the target application program Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS: Web Service Flow (provider)
CICS as a Service Provider – HTTP Transport (6 of 6 ) CICS TS V3 TCPIPSERVICE CSOL SOAP message CPIH CWXN Service Requester Pipeline matching URIMAP handler URIMAP HFS handler pipeline config dynamic install handler Just included this slide in case there were any points that hadn’t already been covered that I thought should be covered. WSDL PIPELINE CICS Web Services Assistant data mapping dynamic install Business Logic WSBind WEBSERVICE Language structure Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

CICS Usage of WSBind File
CICS as a service provider CICS as a service requester CICS Web services Service Requester business logic pipeline SOAP body Data mapping HLL data structure WEBSERVICE resource WSDL WSBind file CICS CICS Web services business logic Service Provider HLL data structure Data mapping SOAP body pipeline WSBind file WEBSERVICE resource WSDL CICS Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

LAB 3 - Creating CICS Services from COBOL
This lab will take you through the steps of using the Enterprise Service Tools (EST) feature of Rational Developer for System z version 7.6 to transform an existing COBOL CICS program so that it can be accessed as a Web service through the CICS Web Services facilities of CICS Transaction Server for z/OS V3.2 Key Activities 1. Get familiar with the programs and run them using the 3270 terminal 2. Import the COBOL program into a Web Services for CICS Project 3. Generate the converter driver, input and output converters, XML schemas, WSDL, and CICS required file (WSBind) 4. Optional: Configure CICS Web Services on z/OS (pro forma, already done) 5. Optional: Deploy the generated COBOL to CICS Transaction Server for z/OS 6. Use the Web Services Explorer to test the CICS-based Web service 7. Optional: Regenerate the Web Service. 8. Optional use EGL Rich UI interface to invoke the CICS Service (Web 2.0) Duration: 60 Minutes Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

LAB 3 - Creating CICS Services from COBOL Existing COBOL/CICS/BMS application EXEC CICS LINK LAB3POT LAB3CLI z/OS Dallas ZSERVEROS EXEC CICS READ FILE (‘POTVSAM') INTO (WORK) EXEC CICS RETURN LAB3POT VSAM Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

LAB 3 - Creating CICS Services from COBOL Create the COBOL/CICS Web Services Test the Web services WSDL LAB3POTD Converter Driver z/OS Dallas ZSERVEROS EXEC CICS READ FILE (‘POTVSAM') INTO (WORK) EXEC CICS RETURN LAB3POT VSAM Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

LAB 3C - Accessing existing CICS/VSAM using an iPhone

LAB 3B - Creating IMS Web Services from COBOL
This lab will take you through the steps of using the Enterprise Service Tools (EST) feature of Rational Developer for System z version 7.6 to transform an existing COBOL IMS program so that it can be accessed as a Web service. Key Activities Generate the artifacts by using IBM Rational Developer for System z Transfer the generated XML converter to z/OS. Prepare the converter for IMS Connect XML adapter 3. Enable the IMS application as a Web service by deploying the generated WSDL file and configuring the correlation properties using the IMS Enterprise Suite SOAP Gateway Deployment Utility 4. Deploy a client application to access the IMS PhoneBook Web service 5. Invoke the Java application 6. Test the IMS Service using Rational Developer for System z 7. (Optional) Call the IMS Web Service using Web 2.0 client created with EGL Rich UI Duration: 60 Minutes Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

LAB 3C - Accessing existing CICS/VSAM using an iPhone
This Lab will show you how you can easily create a Web 2.0 application that reuse and existing z/OS application in and easy and efficient way using IBM Rational products Key Activities 1. Part 1 - Creating the service requester using Web 2.0 (User Interface). 1. Using RDz create a Rich UI EGL project and import the WSDL 2. Test the COBOL/CICS Service already deployed 3. Create the Rich UI EGL project and the Rich UI EGL handler 4. Create the EGL Rich UI widgets 5. Create the EGL code to consume the CICS Service 6. Complete the EGL Rich UI code to invoke the CICS Service 7. Testing the Rich UI Application 8. Measuring the Service Call response time Part 2 (Optional) – Extending the Web 2.0 to invoke Google map services. 9. Modify the EGL Rich UI to add more controls and invoke the Google Map Service. 10. Testing using external Web Browser 11. Using an iPhone Browse emulator 12. Deploying the code to an Application Server 13. Modifying the HTML generated to avoid iPhone resizing. 14. Executing this code that is deployed in a System z WebSphere Application Server Duration: 60 Minutes Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Creating CICS Services from COBOL – Using Sandbox 1 of 4 1 Where to get it? 2 2 2 3 3 Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Creating CICS Services from COBOL – Using Sandbox 2 of 4 Two options: Option #1. Using RDz installed in the System z Sandbox (needs Citrix client)  Assets etc.. On the VMWARE image provided by Citrix Option #2. Using your RDz natively (don’t need z/OS connections).  Download and unzip to C:\ and follow PDF from Sandbox: for Creating CICS Web Services  for invoking the web services using RDz with EGL (iPhone). Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Creating CICS Services from COBOL – Using Sandbox 3 of 4 OPTION #1 -Using VMWARE via CITRIX 1 2 3 Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Creating CICS Services from COBOL – Using Sandbox 4 of 4 OPTION #1 Using VMWARE via CITRIX 5 4 6 Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Creating IMS Services from COBOL – Using Sandbox 1 of 2 1 Where to get it? 2 3 Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Creating IMS Services from COBOL – Using Sandbox 2 of 2 Two options: Option #1. Using RDz installed in the System z Sandbox (needs Citrix client)  Assets etc.. On the VMWARE image provided by Citrix Option #2. Using your RDz natively (don’t need z/OS connections).  Download and unzip to C:\ and follow PDF from Sandbox: Single Services and IBM Rational Developer for System z Single Services and IBM Rational Developer for System z

Single Service creation for existing CICS or IMS Applications

Similar presentations

Presentation on theme: "Single Service creation for existing CICS or IMS Applications"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Single Service creation for existing CICS or IMS Applications

Similar presentations

Presentation on theme: "Single Service creation for existing CICS or IMS Applications"— Presentation transcript:

Similar presentations

About project

Feedback