In this podcast, Gregg explains the difference between what DataDirect Technologies is doing, and what others are doing regarding zIIP exploitation. The podcast runs for 4:36.
To listen to the podcast, please click on the following link: http://blogs.datadirect.com/media/GreggWillhoit_Patent-PendingApproachzIIPExploitation_6.mp3
Gregg Willhoit:
When the zIIP came out, I had a decision to make. That was, how much of Shadow should I try to offload? And the more I thought about it, and I thought about the benefits of offloading to the zIIP, I decided that a genetic alteration to the DNA of Shadow was required. And what I concluded was that I wanted all of shadow to be offloaded to the zIIP, but to do that is very, very difficult. One can take a piecemeal approach, and I’ve seen this in other products, where they may offload some portion of the workload. For example, XML parsing.
Now, just to be clear. Just the parsing of the XML is a minute portion of the workload itself when you talk about SOA – minute. You’ve got the data coming in over TCP/IP, that’s probably not offloaded to the zIIP in those cases, then you do some XML parsing, and you’re offloaded to the zIIP. But the end result of the XML parsing is not a web service. All it is a tokenized version of the inbound XML. So that the tokenized data then has to be converted to a binary format acceptable to the backend data, in this case called a CICS business logic. Well that should be offloaded to the zIIP as well. But if you use a piecemeal solution, it’s not.
Again, on the way back a binary COMMAREA coming from CICS is presented back to the application. Now at that point the COMMAREA needs to be marshaled in through XML or sub serialized on the way out, the XML needs to be generated. That needs to be offloaded to the zIIP, but that’s not provided by most products.
So what we did in Shadow was to take the ball and run with it with regard to our architecture. We decided under no certain circumstances would we bow to the technical difficulties of running in Enclave SRB mode for the entire application. So we eliminated all those barriers. Some of those barriers are that you can’t execute supervisor calls, which there are many. You have to write your own timer services. You have to write your own program serialization, or you have to modify your own program serialization technique. There are a myriad of things that someone has to do. But in the end, the benefit is significant to the user.
In our case if the user wants to execute in SQL to non-relational, or if they want to go SOA to business logic or screen logic, they get the same offload. They get close to 100%. And there’s not another product like that out there. There are products that have taken a piecemeal approach with regard to middleware, but Shadow took a holistic approach. And everything that’s built on the Shadow foundation, and that’s just not SQL Access, and that’s just not SOA, but including our change data capture benefits from this.
I like to say, we took the theory with regards to zIIP offloads that a rising tide floats all boats. And that’s the theory that we’ll continue to take. And all new applications or products under the Shadow architecture will benefit from zIIP offload, I guarantee it.
Taking the holistic approach to offloading the zIIP was not an easy decision to make. I realized that it would require a significant amount of rearchitecting and redesign. And in a product like Shadow – which has a very large customer base, is installed in the largest database and transactional environments, and is used under extremely high volume a circumstance – making such an iatrical change to the product was a difficult decision to make. But the end result has clearly been justified.
And what I mean by that is in Shadow, regardless of the workload you’re accessing, regardless of the type of client, you’re going to zIIP offload, I guarantee it. And you’re going to get a lot. Some other products provide XML or SOA access to legacy data, those products do provide some offloads for use of XML legacy services. But those products also attempt to provide SQL access to nonrealtional data, but none of that is offloaded to the zIIP. None of it. And the reason why is that they did not take a holistic approach to zIIP offload. Because it was easier, it was quicker, it was more expedient to take a shortcut and just offload certain portions of the workloads. But the key thing here is that the user is the one that doesn’t benefit.
While it’s okay to advertise zIIP offloads, where the metal meets the road is when I run my application – regardless of whether or not they are SQL or SOA – do I achieve or do I get the same TCO benefits, regardless of the types of workloads? In Shadow, the decision that we took – which was a holistic sort of rearchitecting the product – I can say uncategorically, yes. And that’s yes for change data capture or event processing, and that’s yes for SQL, and that’s yes for SOA.