Monday, August 15, 2011

Mainframe Enablement for SOA: Part IV


Over the last two decades, CEOs of large corporations are finding themselves locked in a vicious cycle. Maintenance of legacy system are taking a bigger share in their IT budgets each year, as a result of which only very less is available for developmental upgrades.  But without developmental upgrades, maintenance on outdated systems is only going to create more problems in the long run. Now the industry has found a solution though Service Oriented Architecture (SOA), which offers a low-cost methodology to integrate, update, and manage data, applications, and utilize effectively any existing legacy system.

By moving to a SOA environment, you can gain a significant return on the investment by reusing components of your legacy systems. However, migrating to an SOA environment is neither automatic nor easy.  First step in moving towards SOA consists of providing access to mission critical business data and application in a technology neutral way. As pointed out in a  previous blog “Mainframe Enablement for SOA: Part I “of mine, Mainframe still enjoys a special status in many Fortune 500 companies and world’s largest corporations, including banking, finance, health care and insurance companies as they still run the business and contain critical business logic that is unique, difficult and costly to replicate. So in this blog we will explore the ways to enable mainframe application so that they can be part of the SOA world.

There are many solution approaches to enablement including few we have discussed in “Mainframe Enablement for SOA: Part I and Part II”. However, the making use of ESB is a better way. It provides many advantages in the area of governance, flexibility, quality of service (QoS).

Architecture


Note that ESB such as WebSphere Enterprise Service Bus supports z/OS and other distributed platforms like Linux for System, AIX and Windows. This approach requires the following software:  IMS Version 9 and IMS Connect Version 9 or above and for IMS enablement, CICS Transaction Server and CICS Transaction Gateway for CICS enablement. Other things required is J2C connectors like IMS TM Resource Adapter which implements the J2C Common Client Interface (CCI), a programming interface that allows your application to communicate with IMS Transaction Manager and CICS TG Resource Adapter, which allows communication with CICS Gateway.

Advantages of this approach

There are many advantages in using ESB as part of the solution since ESB are designed to avoid the point-to-point connectivity between services provider and service consumer, whereby it provides location transparency. 

ESB routes messages between services thereby removing the direct one-to-one relationship between end points.

ESB also provides built-in transformation capabilities for both message formats (for example binary into XML) as well as transport protocol transformation (example SOAP to MQ). 
And with CICS TG and IMS Connect providing two-phase commit, advanced security and system management, and the fact that no change is required in the CICS programs or IMS programs it turns out to be, the ideal way to enable Mainframe for SOA.

Thursday, August 4, 2011

Mainframe Enablement for SOA: Part III


In Mainframe Enablement for SOA Part I and II, we have discussed the approaches to enable CICS applications and IMS; now let us explore an approach to expose DB2 data or application as service.
JDBC Solution

The DB2 application or data can be exposed as Web services, implemented in J2EE Application Server via Java Database Connectivity (JDBC).  These Web services can be accessed directly from a Web service consumer using the Web Service protocols.

The Java Database Connectivity (JDBC) is an application programming interface (API) that the Java programming language uses to access relational database, such as DB2. The actual implementation of the JDBC interface is provided by the database vendor as a driver. This provides portability because all access using the JDBC is through standard calls with standard parameters. This enables an application developer to write code with little regard to the database being used, because all of the platform-dependent code is stored in the JDBC drivers.

There are 4 types of JDBC driver and z/OS supports Type 2 and Type 4. A type 2 driver is platform- and database-specific implementation.  Type 4 drivers are implemented using Java and are platform independent but are database-specific as they use proprietary database protocol to connect. For example, DB2 Type 4 driver access DB2 through DRDA. These pure Java drivers deliver high performance, scalable remote connectivity and manageability for Java-based enterprise applications to a remote DB2 running in z/OS database server


Architecture


Advantages of this approach
  • Extremely easy to use and quite popular approach with Java developers.