In this podcast, Gregg discusses architectural considerations for zIIP exploitation. The podcast runs for 2:31.
To listen to the podcast, please click on the following link: http://blogs.datadirect.com/media/GreggWillhoit_BestPracticeszIIPExploitation_1.mp3
Podcast text:
What are some of the best practices for zIIP exploitation?
Gregg Willhoit:
Some of the best practices for zIIP exploitation begin with the actual philosophical approach to exploiting the zIIP. And that is, exploiting the zIIP in a holistic fashion. That is, an architecture which allows for zIIP exploitation regardless of the type of interface, regardless of the type of client.
This type of architecture can really only be achieved in a product architecture delivered by a single company. You can’t achieve this type of zIIP exploitation, for example, if your product depends on distributing or partnering with another product. This kind of zIIP exploitation requires a unified platform, like DataDirect Shadow for example. And what I mean by this is that some of the major benefits to zIIP exploitation are derived from the use of middleware products to access non-relational data and/or relational data on the mainframe.
The various clients that use this data are typically Web services clients, ADO.NET, JDBC and ODBC. And even from the event side, that is publishing out the XML, change data capture all under a single unified platform. So the only way to truly achieve across the board zIIP exploitation for these major categories of product type, or functional categories in middleware or z/OS, is to have a single unified platform all from one vendor. DataDirect Technologies’ Shadow product can then provide you with zIIP exploitation that is end to end, basically almost achieving 100% offload of the code that executes in the vendor’s address space. That is the vendor’s code or IBM’s z/OS code.
In order to fully exploit the zIIP across product offerings, a company needs basically to take this holistic strategy. And this holistic strategy has as its number one requirement that all products that are offered are developed under the same architecture. One cannot rely on the zIIP if one is relying on partnerships to access SQL to non-relational, for example, one cannot rely on that partnership. One cannot rely on the different vendor to have the same goals with regards to zIIP offloads as the company requesting it. That company may have different goals with regards to zIIP offloads. They may have financials that require that they can’t zIIP offload. They may have technical limitations to the architecture since there is no sure architecture that keeps them from offloading to the zIIP. So it’s absolutely incumbent, and a requirement if you will, for a company if they want to achieve across the board zIIP offload, that is for SOA , SQL and events, to do so under a single unified platform.