Ims soa tm and db solutions evgeni oct 2011

Editor's Notes

• #4: Our IMS SOA Integration Suite solutions covers both IMS TM and database. We provides a variety of solutions that fits the your requirements and needs – which allows you to easily modernize and leverage existing IMS transactions as well as providing you direct and open access to IMS data.
• #5: Our IMS SOA Integration Suite solutions covers both IMS TM and database. We provides a variety of solutions that fits the your requirements and needs – which allows you to easily modernize and leverage existing IMS transactions as well as providing you direct and open access to IMS data.
• #19: The synchronous callout function is a V10 SPE item that specially address the need for IMS application to act as a client to go outbound synchronously to invoke external application and receive the output back. This enhancement allows your IMS application to invoke one of the following external applications and synchronously get the output back: (1) an J2EE application (like an Enterprise Java Bean/EJB or an Message Driven Bean (MDB)) or Web service providers running in the WebSphere Application Server using the IMS TM Resource Adapter (2) other Web service providers (e.g. like Microsoft .NET or SAP XI) using IMS SOAP Gateway (3) any other applications (like RYO, SAP apps) using the IMS Connect interfaces This diagram gives you a very high-level overview of the synchronous callout SPE. The red arrow represents the send flow. From the right hand side of the diagram, an IMS application makes a DLI call to send out a synchronous callout request. The OTMA descriptor function inside IMS routes the callout request via IMS Connect to invoke one of the outbound destination as shown in the boxes on the left – i.e. the WebSphere, Web Services or RYO applications. After the callout request has been processed, the output data would be returned back to the same IMS transaction instance as shown in the blue arrows.
• #25: WRT Scenario: Imagine a bank is looking into new placements for Branches and ATMs. A mashup could help by.. Unlocking locations for their current branches/atms and in the same view see where their high value customers are via a map (from IMS or DB2). Also provide a view of where the competition has setup (oringinating from a spreadsheet). Then combine that with other data like where new construction is happening (from another Web Services likely rented - ie demographic info) Mashup would allow them to see all of this to help them make a decision.
• #26: PLI is not fully supported since extensive testing wasn’t done
• #29: IMS Database Resource Adapter (DRA) Allows CICS applications to connect to IMS DB through DBCTL IMS Open Database Access (ODBA) Allows WAS, DB2 Stored Procedures or other z/OS applications to connect to IMS DB IMS Open Database Allows connectivity from any client on any platform to IMS DB using IMS Connect In addition to building IMS Java access on ODBA, SQL/JDBC access is also provided through DB2 II CF.
• #30: New function in IMS V11 taking on the challenge of modernizing IMS DB access and application development Addresses two significant bottlenecks for business growth in client install base Connectivity – IMS DB has been historically grounded to mainframe…certainly ways to get to it but none straightforward and simple Programmatic access – even when connectivity isn’t an issue - skills issue severely impacting client’s ability to develop new application workload which again goes to revenue. DLI isn’t industry standard and skills are lacking. It is one thing to move to DB2 to take advantage of skills – another to move to Oracle – which is what I’ve seen…clients are in fact rolling out new workload – but target is (at times) is a non-IBM solution and clients are stabilizing workload against IMS Value Rolling out a complete suite of Universal drivers in support of IMS database connectivity and programmatic access Intent – access IMS in a uniform way using the most relevant industry standards from any platform and from within the most strategic runtimes Standards-based approach opens a lot of growth and integration opportunity Single Universal driver in support of both type-4 and type-2 connectivity in all supported runtimes – no need to learn another driver’s semantics to toggle between environments and desired connectivity – all built in to the framework Distribution of resources within an IMSplex included Extend the reach of IMS by extending the data IMS DB metadata exposed via standard JDBC API and therefore can be consumed and visualized by JDBC tooling By allowing inspection of metadata, the next step is query Query syntax uses standard query language syntax Differentiators First-time compliance for JCA 1.5 First-time JDBC metadata compliance Standardized the SQL in support of IMS access IMS now hosts a DRDA servers (source and target)
• #31: The Universal drivers have a framework capable of processing any of the three main programming models: J2EE, JDBC, DLI. The Universal drivers are able to connect to any IMS subsystem on any mainframe system. The same application can have active connections to any number of IMS systems on any number of mainframe installations. (click) We have a requirement for providing type 2 access (IMS access from the same LPAR in WAS z/OS, IMS, CICS, DB2 z stored procedures) using these same Universal drivers. Again, the same framework is capable of handling both type 2 and type 4 connectivity so the applications themselves do not change. Only the connection properties.
• #32: Local access: We have a requirement for providing type 2 access (IMS access from the same LPAR in WAS z/OS, IMS, CICS, DB2 z stored procedures) using these same Universal drivers. Again, the same framework is capable of handling both type 2 and type 4 connectivity so the applications themselves do not change. Only the connection properties.
• #33: Local access: We have a requirement for providing type 2 access (IMS access from the same LPAR in WAS z/OS, IMS, CICS, DB2 z stored procedures) using these same Universal drivers. Again, the same framework is capable of handling both type 2 and type 4 connectivity so the applications themselves do not change. Only the connection properties.
• #34: <background>The intent of this chart is to show the current topology and illustrate the evolution to the new one, pointing out the enhancements at each step. As a point of fact, WAS z/OS cannot take advantage of ODBM’s cross-LPAR feature unless WAS itself embraces SCI. Applications can use the out-of-the-box compatibility mode to use AERTDLI and have those calls routed to an ODBM which will still prevent the U113 abend – but WAS and the ODBM address space will still need to be on the same LPAR. It is just an illustrative example showing what can be possible with WAS z/OS as an ODBM client.</background> The current solution (whether or not we are talking about distributed or local access to IMS DB) leverages ODBA as the API to access IMS database resources. ODBA is capable of making address space to address space calls (PC calls) in the same logical partition. The net effect of this is that the ODBA modules need to be on the same LPAR as the IMS CTL region. These modules (ODBA) are loaded in the address space of the application, which is in turn loaded in the address space of the container. In this case the container is WebSphere AS. The result of this is that the WAS installation has to be on the same LPAR as the IMS DB itself. There is no isolation. Click What we are doing is creating a new CSL address space to house the ODBA modules. This interface will use SCI as its communication mechanism. The ODBA modules are no longer tightly coupled with the applications themselves (and therefore the containers). Click By leveraging SCI, the applications can be on any LPAR in an IMS plex. SCI uses either PC or XCF calls to communicate with other SCI components. XCF allows calls to go across LPARs in an IMS plex. This allows applications (and their containers) to be isolated on their own LPARs. Click This leads us to our real goal, which is to leverage IMS Connect as the complete gateway solution for IMS TM, OM, and now DB. IMS Connect will be augmented to be an ODBM client. This will allow distributed applications to leverage the TCP/IP protocol to communicate with IMS Connect, which can then access any database in the entire IMS plex. (Click) ------- IMS Connect becomes the IMS Gateway to both IMS TM and IMS DB. WebSphere and DB2 Stored Procedures no longer have to be on the same LPAR with IMS when they interface with the IMS ODBM (Open Database Manager) address space. The ODBM address space must be on the same LPAR with IMS due to the use of the ODBA (Open Database Access) interface. Distributed clients would now have the option of going directly to IMS Connect for IMS DB requests.
• #35: What we are doing is creating a new CSL address space to house the ODBA modules. This interface will use SCI as its communication mechanism. The ODBA modules are no longer tightly coupled with the applications themselves (and therefore the containers). By leveraging SCI, the applications can be on any LPAR in an IMSplex. SCI uses either PC or XCF calls to communicate with other SCI components. XCF allows calls to go across LPARs in an IMSplex. This allows applications (and their containers) to be isolated on their own LPARs. XCF: In IBM mainframes , a Cross-system coupling facility , or XCF , is a component of z/OS that manages communications between applications in a sysplex . Applications may be on the same system or different systems. ----------- ODBA had a restriction that WAS had to run on the same LPAR as IMS DB. Type 2 connectivity ODBM introduced a new address space (it contains ODBA) IMS Connect was augmented to be a TCP IP gateway into IMS. IMS Connect replaces WAS z. ODBM wraps ODBA SCI Allows cross LPAR communication IMS Connect has access to any Database in any LPAR
• #36: This leads us to our real goal, which is to leverage IMS Connect as the complete gateway solution for IMS TM, OM, and now DB. IMS Connect will be augmented to be an ODBM client. This will allow distributed applications to leverage the TCP/IP protocol to communicate with IMS Connect, which can then access any database in the entire IMSplex. IMS Connect becomes the IMS Gateway to both IMS TM and IMS DB. WebSphere and DB2 Stored Procedures no longer have to be on the same LPAR with IMS when they interface with the IMS ODBM (Open Database Manager) address space. The ODBM address space must be on the same LPAR with IMS due to the use of the ODBA (Open Database Access) interface. Distributed clients would now have the option of going directly to IMS Connect for IMS DB requests. Existing DB Resource Adapter applications are unaffected by Open Database. In order to exploit Open Database from existing DB Resource Adapter applications, a migration to the JCA 1.5 programming model would have to be done.
• #37: DMU is used to generated the so called DatabaseView class (that needs to be deployed within the WAS (WebSphere Application Server) classpath) The DatabaseView class is a relational representation of the IMS database which is hierarchical by nature
• #40: These are the features that are available on our tech preview refresh (for 06/24) The GA is w/ the ISM Enterprise Suite 1.2 scheduled for 10/2011. We don’t plan to add new features to the GA version. For DBDs: you can only add fields or copy book information. The current version of the IMS Explorer **DOES NOT** create new DBDs, change DBD properties, increase segment length For PSB: you can do everything: Create New PSB from scratch, create a PSB based on a existing one, change the PCBs…, change segment and field sensitivity
• #43: The IBM Mashup Center is the IBM offering for the mashup platform and is free for IMS 10 and IMS 11 customers. The mahsup center is an end to end mashup platform that allows to assembly very quickly dynamic application, as for example, mashups. Because we are talking about the enterprise we have to keep in mind security and governance and the mashup center offers the support to keep your data safe. With the mashup center we can create a new application or mashup from existent building blocks as for example a widget or a feed we can also wire this building blocks together to create something new. The mashup cneter also keeps a catalog where we can see all the feeds and widgets that are available to us. One feature from the mashup center that I really like is that we can combine 2 very different data sources as for example a spreadsheet with an IMS feed to create a single new feed. -------------- Main Point : IBM Mashup Center is an end to end mashup platform, supporting rapid assembly of dynamic applications – with the security and governance capabilities needed for enterprise operations, and delivering the ROI required for today’s IT budgets. There are five product capabilities: Create new applications by assembling a mashup from reusable building blocks – widgets and feeds – wiring them together to create something new. Unlock information from a diverse set of information sources – enterprise, web, personal, and departmental sources - creating a fast and cost effective way to get a single view across many information sources and ensure use of accurate data Develop widgets with a code-free step by step approach using Widget Factory. Discover and share reusable assets and mashups from a community catalog – taking advantage of rating, tagging, and comments to find the most appropriate information and assets, with many different ways to search – by URL, by keyword, by author etc. Transform information - remix disparate information sources such as a spreadsheet with a feed from a DB2 database into a single new feed – a data mashup. Using a browser based tool – quickly transform and customize it into exactly the information that’s needed – without coding.
• #47: Some of our customers, are seeing an evolution of integration in their enterprise. New packages are being purchased or built that run outside of the IMS environment. It is becoming a common requirement for an IMS application to execute an external function. This chart shows some outbound flows from an IMS Application to invoke a process outside of IMS. There is a lot of flexibility in how you can integrate enterprise components with your IMS applications. In some cases, asynchronous processing is needed, in other cases synchronous processing is required. With asynchronous flows, the application invokes the service and then continues processing its work and eventually terminates. While this chart focuses on the outbound flow, some of these flows can be synchronous to the application, meaning the call is made to the service and the application waits for the response from the service before continuing its work. SOA is revolutionizing the way business solutions are being designed. Our goal is to leverage IMS as an key part of the enterprise in the evolving business world. We are doing this through support for complimentary standards surrounding IMS connectivity, data representation, and application development. This in turn allows you to realize the promises of building a Service Oriented Architecture to Simplify the business environment and Respond to market changes more quickly and cheaply.