Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
In this podcast, Gregg explains what it means to be a fungible virtual appliance, and how this relates to the zIIP specialty engine. The podcast runs for 4:25.
To listen to the podcast, please click on the following link: http://blogs.datadirect.com/media/GreggWillhoit_zIIPFungibleVirtualAppliance_5.mp3
Could you explain the concept of a fungible virtual appliance with coherent memory?
The way I look at a zIIP is that it is an appliance. However, it’s fungible. It can take many shapes or forms. It’s interchangeable with regard to the workloads that it executes on. And unlike other appliances – which there are various XML appliances and SQL appliances out there that are off host – the zIIP operates on workloads on ZOS, sharing the same memory that the general purpose processors share. This is a much more efficient method for employing an appliance, because unlike the zIIP, offload appliances require TCP/IP profits over the network. So with the zIIP, you eliminate that overhead as well.
Then there is the aspect of the offload appliance and there separate management, maintenance, capacity, administration, electrical consumption needs: the zIIP is far superior in my mind. I think that in the industry we will see the zIIP being used more and more as a virtual fungible appliance with coherent memory.
One of the things that my product, Shadow, does is it exploits the zIIP as a virtual fungible appliance. We offload basically 100% of the SOA workload to the zIIP. However, this product, with its unified platform, also supports SQL callers from JDBC and ODBC. So one millisecond the zIIP is theoretically an XML appliance, serving the SOA community; the next millisecond it’s non-relational relational SQL transform engine appliance.
Much of the data on the mainframe is non-relational. Relational theory didn’t actually come to the forefront until much after many applications such as IMF developed on mainframe systems. These applications contain really, really important data. In order to get this data in a facile manner, the best way to obtain access is through SQL; SQL from non-relational and back to relational, those transforms. The actual support Ampteam 92 SQL to non-relational data is extremely computationally expensive, and in my testing, and in many cases, much more so than XML marshaling and unmarshaling. So what we’re able to do, what a product should be able to do, is offload 100% of that process as well, to the zIIP, therefore allowing the data to stay on the mainframe where it should be: where it’s easily managed; where it’s easily backed up; where it’s easily controlled. And access it in a very cost effective fashion using the zIIP as a virtual fungible appliance that is offloading 100% of that non-relational to relational transform to the zIIP.
So the zIIP as a virtual fungible appliance with a coherent memory eliminates all the disadvantages of accessing mainframe data. Heretofore, many products which try to expose mainframe assets would require that the mainframe data be moved from a mainframe to an Intel type platform. Then the data could be massaged and accessed there in a fairly cost effective fashion. However, the minute the data is moved from the mainframe off to the host platform, it is no longer real-time. It’s no longer current data. Prior to the zIIP this was probably necessary due to the relatively expensive nature of providing facile access to non-relational data. But using the zIIP as an appliance, offloading all those SQL expense to the zIIP makes keeping the data on the mainframe and accessing it a reality.
In the past, accessing data on the mainframe, typically because of the expense – because of the cost processing SQL on the mainframe to go against non-relational data was fairly high – customers in the evenings would send large amounts of data to these offload host platforms so that the data could be used to do business intelligent type applications. To do fairly recourse intensive queries against this data to possibly mine for gold – data gold. But you lose currency. Because now the data is being updated during the day, and so on. Now with the zIIP, and the ability to offload all that non-relational relational transformation on the zIIP in a coherent memory – leaving the data where it belongs on the mainframe – it’s a very very very powerful thing.
I think it really bodes well for exposing mainframe legacy assets in a facile manner.
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.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.