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.
View all posts from Gregg Willhoit on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites
Progress collects the Personal Information set out in our Privacy Policy and the Supplemental Privacy notice for residents of California and other US States and uses it for the purposes stated in that policy.
You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.