Service-oriented architecture (SOA) and web services have been with us for more than a decade, and of late, we are seeing microservices making a bold statement. However, all too often, our minds switch off when we hear SOA and web services referenced in webinars or presented on PowerPoint slides. For many within IT, it’s all talk of SOA and web services seems akin to magic, as if embracing this single solution can solve all of our modernization issues. Despite good intentions of SOA and web services evangelizers, what’s often overlooked is just how important the services-oriented paradigm has become – particularly for modernizing applications on the NonStop platform.
At its core, SOA and web services represent an opportunity to re-use legacy applications’ underlying business logic in new and, yes, very modern ways. SOA and web services not only make the presentation modern, they also create new ways to use existing and proven software, with no changes to applications’ underlying business logic. For the most part, modernization with SOA and web service entails configuration changes, along with support for enhanced communication. A contract becomes necessary when service level agreements (SLAs) are needed to ensure that the business logic will retain certain thresholds, such as functionality, availability, and quality of service.
From the outset, the emergence of three new protocols and services redefined the way we viewed our applications. Today, we know these protocols and services as extensible markup language (XML), simple object access protocol (SOAP), and web services description language (WSDL). Their origins are deeply rooted in the internet, and their current usage depends on the transmission control protocol and internet protocol (TCP/IP), along with a hypertext transfer protocol (HTTP) server. And yet, it was out of web services that the SOA paradigm emerged and, along with discrete client and server endpoints, has proven an ideal way to interact with current business logic running on traditional NonStop systems in the least-intrusive manner possible.
The SOA externalization of NonStop applications as one or more services gives these applications a modern appearance and – when it comes to business logic implemented with Pathway – an almost ideal new use case for all instances of Pathway server classes. Furthermore, client endpoints can be completely oblivious to which types of server are responding to their requests, and NonStop applications can behave as either the recipient or generator of the request.
Indeed, this oblivion has made it relatively easy for NonStop to participate in SOA and web services to the point where many solutions for NonStop are architected today using SOA. Payments solutions, including BASE24-eps and OmniPayments, are examples of SOA utilization that many NonStop users will be familiar with. According to ACI, “BASE24-eps is an open payments software solution that is built on the foundations of SOA principles.” Likewise for OmniPayments: “Based on a modern Service Oriented Architecture (SOA), OmniPayments consists of several service modules. The critical payment components are built on NonStop for the highest availability.”
NonStop systems remain the preferred runtime platform for these payments solutions, and the fact that both solutions are based on SOA speaks volumes about the inherent benefits that SOA provides. As a loosely coupled architecture, wherein client endpoints can solicit services from multiple servers, it’s ideal for integrating current business logic with processes and data that reside elsewhere on the network. Developing entirely new applications by pulling information from multiple processes already in production is one of the key business drivers that led to the success of SOA.
However, when it comes to the NonStop marketplace, even with solutions built on SOA, there remains a lot of critical business logic that is not part of any off-the-shelf solution or, indeed, reflects earlier iterations of the solution. Oftentimes these solutions are developed and maintained in-house and are unlikely to be replaced by something new based on SOA. There are a number of product offerings available from the NonStop vendor community specifically aimed at modernizing these solutions, with one such product offering being Client Server Link (CSL) from comForte.
Whether your development preferences are Java or .NET and whether your NonStop is acting as the server or the client endpoint, CSL provides a solution. According to comForte, CSL, “Enables hybrid, multi-tiered architectures capable of offloading presentation and data conversion services from the NonStop server to better-suited platforms,” even as it also, “Allows the transparent exposure of new or existing Pathway servers as Web services.” In a world where mobility reigns and where the consumer experience has become a major influence on the priorities of IT developers everywhere, this loosely coupled architecture of SOA as supported by CSL is very important.
But there are changes underway for SOA today that make further consideration of modernizing via SOA relevant to every NonStop user. The advent of cloud computing, wherein HPE is gradually introducing NonStop X systems with its messaging about transformation to a hybrid infrastructure, the potential benefits of SOA are being closely examined. Fortunately, when it comes to the role CSL can play in modernization and transformation, this examination only uncovers more value in what CSL provides today.
In the article, “NonStop X is opening the doors to even greater NonStop integration with modern architectures!”, to be published in the upcoming September / October 2016 issue of the NonStop community magazine, The Connection, I reference an article published in a June 16, 2016, article in The Edge Technical Trends, How Cloud Computing Has Reshaped SOA. “In traditional SOA, coupling of systems could be loose or tight,” it states. “There can be thousands of cloud services within an architecture. Tight coupling would mean that an application would be completely stopped if a particular service goes down or if the connection were to be lost. Loose coupling is essential to allow for flexibility and independence, but the concept of coupling systems is still very much alive in the cloud model.”
For more than a decade the NonStop community has had a choice in SOA and web services implementations, and the good news is that when it comes to front-ending NonStop solutions with clouds, that integration between NonStop and the cloud can leverage SOA as it always has. It’s just that the integration with mobile devices and, indeed, sensors where experience suggests that there is the need for a lighter-weight solution. This is a very important consideration as the decision to modernize any traditional application must take into consideration the likely implication that private clouds within the enterprise may have on modernization projects.
SOA and web services remain relevant today. When it comes to interfacing to private clouds, it’s as if just another server cluster was being accessed. Whether the server or client endpoint is based within a cloud makes little difference to the SOA and web services because of the inherent loosely coupled properties of any SOA- and web services-enabled client or server. Indeed, looking further afield, there is every likelihood that CSL implementations themselves will be running within a private cloud – all because the CSL implementation is platform agnostic. In looking at CSL for modernization of current and even future applications, perhaps the best news of all for the NonStop community can best be summed up using HPE NonStop Senior Director of Development Andy Bergholz’s favourite saying: “It just works!”
Want to learn more about CSL? We’ve got you covered here.