Many customers host critical applications or databases on mainframes. These services are critical for those enterprises and those companies want to make sure the money spent on those services is used efficiently. Many applications in a company will leverage those mainframe hosted services. Each of those applications is probably developed independently within the company.
Problem: Portals and independent applications cause redundant requests on mainframes
Lets say the requests being made from those applications are starting to slow down the mainframe. A common reason for this is portals. Portals present information from different applications on one screen. This makes lots of sense for customers in that they get an integrated view of their situation but this causes headaches for the company. Why?
These applications are probably all fetching the same data from the mainframe. Things like customer profiles, account balances. If there are 5 applications used in the portal then this information will be retrieved 5 times. The same information. This clearly means the mainframe is having to execute the same request 5 time in a row and with customers paying for MIPs to run those requests, this isn't acceptable.
Localized solution: Silo/application based caches
Application level development teams usually do the following when they see a 'slow' backend. Each application team adds a cache. This appears to help within the application teams world. This eliminates redundant requests within the application but the mainframe will still see 5 profile requests in the above example because the caches are application private. Application private caches are therefore not really the answer. Whats needed is an enterprise level solution that addresses the problem for all applications across the Enterprise.
Correct Solution: ESB/Service level DataGrid enablement (cross application)
We need a shared cache thats accessible by all applications and that new ones can utilize without writing any code. This cuts development and testing costs and this would reduce the profile fetch to exactly one which is what it should be. This is exactly what DataGrids like ObjectGrid are designed to do. A data grid can be created and then shared between applications accessing the mainframe. All requests go through this layer and this eliminates any redundant requests.
No-one wants RIP and WRITE
The next issue is that while this sounds great, no one wants to rewrite 5 applications to check a datagrid. The issue now becomes where can they splice in a datagrid without changing any code. Most organizations use SOA now and probably were using SOA before they even knew it was called SOA :) This can help greatly with minimizing "rip and write" to add this capability. The mainframe usually exposes its services using an ESB of some kind, like MQ/390 or a similar product. This allows a new service to be written that has the same interface as the old one but acts as a proxy to the existing mainframe services. The proxy checks the datagrid for already serviced requests before sending them to the mainframe. This allows the DataGrid to eliminate redundant requests without changing any code in the existing silo applications or on the mainframe.
Where should this new proxy service be hosted? zLinux makes a great location. Host the DataGrid in a collection of zLinuz VMs or host it on a distributed platform. The choice would be the customers depending on the specifics.
This shows the value of including a DataGrid component in an ESB rather than in an application. The ESB provides a relatively cheap way of incorporating DataGrid services to eliminate redundant requests to a Z/OS system without incurring high development costs. The time taken to implement this is also considerably shorter than having to line up five development teams on different schedules to do this work.
Summary
So, to summarize. We're seeing this requirement from many customers looking to increase the efficiency of their mainframe applications and databases. Application aligned development teams and portals are aggravating the issue due to different schedules, priorities etc between the teams. Customers that are already using ESBs have the opportunity to leverage DataGrid services to cache service requests and achieve efficiencies at a relatively low cost and implement this quickly. Customers that are not using ESBs may still have some common architectural layer in to which DataGrid services can be exploited. If you don't have an ESB or similar architecture then this is a good reason to start working on adding one because once you have the architecture then enterprise wide efficiencies can become a lot more attainable. Another way of looking at this is that directly accessing shared resources like databases or data serving applications using low level APIs (SQL/JDBC/JCA) doesn't scale. Applications/client accessing the same data through data services scales better because you get more control than you would using SQL/JDBC or other approaches but thats another blog entry.
Comments