Last week, we revisited frameworks and in particular, aKuna (underpinning uLinga products); in this post we look at how the flexibility within aKuna helped the uLinga products better address real user issues and do so, in a timely manner!
To continue with the theme from last week’s post, the Corvette is now home, happily ensconced in my garage. The work is all complete and hopefully, in a couple of days’ time, it will once again be able to really spin its wheels – the ride back from Colorado Springs certainly left me with no misgivings about the car pulling strongly once again.
Wrapped in completely standard bodywork that differs little from any other coupe motoring down a highway there’s little indication whatsoever that there’s considerable muscle that can be flexed in an instant. If the math is right, beneath the hood there’s 700 horsepower – more than sufficient to satisfy my needs as a daily drive.
Probably of more interest to readers however, is the progress that the Infrasoft development team has made with building the uLinga product suite of networking products (competitive alternatives to ACI’s ICE and HPs SNAX products) in a relatively short time. Should you be standing in the check-out lane of a well-known grocery chain, watching your purchases being scanned, then rest-assured; there’s no escaping contact with uLinga as the transaction is processed. For the past couple of weeks, more and more stores have been cut-over to the production uLinga implementation and all has gone well with uLinga exhibiting stability and reliability not typically associated with a product just entering the marketplace.
Much of what is being delivered by uLinga and the ease with which it is meeting its objectives, as was revealed last week has to do with the underlying chassis, or framework, that is aKuna – it’s now simply flexing its muscles. And while it was observed in that earlier post how frameworks are rarely the subject of much attention (every good product has one, surely?) with all the emphasis being given to modernization of late, it’s becoming very important for users to be aware of the technology underpinning their favorite solution.
Scratch too deep beneath the shiny surface and you may find nothing but rusty metal dating back many decades! aKuna is a fresh approach and was a decision taken early in the development cycle. “Another abstraction layer that was considered at the time was Apache Portable Runtime (APR),” said David Finnie, head of Infrasoft R&D in a recent exchange. “At Infrasoft, while we looked at APR, it proved inappropriate as it assumed that target Operating Systems (OS’s) were all POSIX-like under the covers. Perhaps just as important for the middleware we were developing, and the expectations our users would have when it came to performance, APR didn’t fit well with the underlying Guardian non-blocking / no-wait I/O model and this is important as it’s the Guardian personality we leverage with such a critical subsystem as uLinga.”
Readers may recall how last week I described frameworks as though they were Rubik’s cubes where the surfaces of the cube could be manipulated to meet various platform and solution needs. When it came to aKuna the top surface was being effectively manipulated by the Infrasoft developers in support of varying application-to-application connectivity needs.
Providing SNA applications access to each other, in this case, SNA client devices to an SNA application, over a modern TCP/IP network without requiring any changes was simply a case of one face of the Rubik’s cube being shown to the user. Rotate the smaller surfaces that make up the cube to reflect a different property, and the Infrasoft developers provided support for SNA application access to other SNA applications, including CICS and IMS, over a modern TCP/IP network, again, without requiring any change except small ones in some instances, depending on release levels of the IBM subsystems involved.
Fashioned in this manner, and yet remaining just another “manipulation” or extension in the way aKuna can be called upon to support what was once perceived as an architectural specialty of SNA. Widely known as Advanced Program-to-Program Communication (APPC) and with a very rich API, its proponents now have a way out from any further reliance on this legacy communication service. uLinga becomes the bridge between SNA applications with a reliance on APPC to leverage modern TCP/IP networks as the face of aKuna is manipulated once again.
Long seen as one of the most challenging obstacles delaying the further modernization of a server, once-revered APPC can now be bridged effectively with uLinga. With DLSw, uLinga was able to provide support for tunneling and now, with APPC support uLinga adds bridging and a way to push the intricacies of SNA further into the background. These techniques aren’t new and yet, available in a single subsystem as it is in uLinga, makes the task of modernizing networks so much easier. What may look like ordinary wrapping belies what capabilities uLinga can so easily be called upon to provide almost at a moment’s notice!
Manipulating the surfaces of aKuna to support both tunneling and bridging isn’t the only value aKuna brings into play. Just as with the myriad collection of surfaces of a Rubik’s cube, the underside of the cube can be just as easily manipulated. The all red surface that supports NonStop can be easily rotated in support of Linux, Unix and even Windows – there’s many colors available with a twist.
Today, with aKuna, combinations of some uLinga features have been brought up and tested on Unix – testing with Linux and Windows is now only a case of “on user request.” Unix, very much like NonStop, was a popular choice for distributed processing in an SNA network, with many in finance and insurance deploying these computers in regional and branch office applications. Conversely, new applications coming to Unix that need to pick up earlier generation financial terminals supported solely by SNA, now have an option.
To return to the illustration of last week that featured the Corvette, I recently experienced a failure of the power steering as a result of the power steering fluid overheating. One mechanic I was working with suggested that of all the fluids in the car, the power steering fluid was definitely the forgotten fluid! As the demands placed on the steering increase, then the need for something more tolerant (of higher temperatures) is mandatory.
And with aKuna, as the demands placed on uLinga continue to increase, Infrasoft have a framework well implemented to meet the demands that continue to arise. “The way forward” is certainly a great way to sum up its capabilities and truly reflects the ambitions of many users today as they pursue modernization strategies.