Saturday, September 4, 2010

There’s SOA and then, there’s Services!

Since posting to the blog last week and developing discussions within a number of LinkedIn groups, I have talked to several comForte folks about their take on Service Oriented Architecture (SOA). The perspectives and points of view that they shared while talking about their Client Server Link (CSL) products made it clear why this has become such a popular topic and why so many companies are depending upon the NonStop platform and view it as crucial component in their modernization efforts.

Today, the hardware supporting the NonStop platform is as modern as any currently available. Users new to the BladeSystem, and to running NonStop applications on Blades, are early participants in a new wave of computing where the basic building blocks are commodity items, and where the packaging can be shared with many different operating systems. Eventually, the expectation across the industry is that manufacturers, like HP, will soon be able to offer just a small number of generic blade packages capable of being installed in standard chassis and pulling power and cooling from a shared chassis infrastructure, and where the prices will be significantly lower than what we see today.

However, the story is less than glowing when it comes to software and the take-up of what is generally considered representative of today’s modern software product offerings. For instance, so many solutions running on NonStop continue to feature COBOL and TAL modules and data is still pulled from Enscribe files. While Pathway continues to evolve and reinvent itself, underpinning the containers and run-time environments mandated by Java, J2EE, and .Net programming models, SQL should be the preferred end goal for all architects providing oversight for new projects featuring the NonStop server.

Whenever I post to his blog, I return to LinkedIn and start discussions on as many groups as I can to promote the storyline associated with each post. One group I always update is the LinkedIn group, Tandemworld.Net. Stephan Amsbary was very quick to comment this week on how “SOA is the ‘current best’ model (when applied to) loosely-coupled / reusable architectures. Yes, it’s a natural for Tandem, (oops, I mean NonStop) ... We were doing this already with Pathway's Requestor/Server model.” In other words, SOA offers an almost immediate big bang for the buck when it comes to externalizing existing Pathway servers as Web services for adoption within an SOA deployment.

However, while I have referenced Stephen’s quote in an upcoming article in Tandemworld.Net it was an earlier comment Stephan made that really did get my attention. In Stephen’s comment he wrote of how SOA and Web services are not one and the same, explaining how many of us continue “making a common mistake - they are not synonymous … SOA is just that, a Service Oriented (based) Architecture, (and) it can use any exchange vehicle it likes. Web Services (and XML-messaging) is just one way to execute it. SOA continues to get a bad rap because of this confusion. I am running into this misconception …”

After reading Stephan’s comments my thoughts turned to cars, and the choice of cars we have given different situations. We would no more drive a high performance Dodge Viper to be safe on a highway, as we would an ever reliable Bentley to the convenience store for a head of lettuce. And we would not drive an American full size SUV on the race track. On the other hand, the SUV feels safe on the highway, the Bentley provides a solid platform that can go the distance on trips across the country, while the Viper revels at the race track! Security? Reliability? Performance? Each requirement or necessity steers us towards a different vehicle.

When it comes to planning for SOA, in the most recent discussion I had with the folks at comForte, after last week’s post to the blog, our exchanges followed a similar path. The choice of technology you deploy, as you externalize business logic as services, can often be associated with other equally important considerations. As I observed in the previous post, there are alternatives to full Web services deployment and where the performance gains quickly outweigh any advantages that global standardization on SOAP may provide. I had remarked on how this becomes more obvious in exchanges between applications residing within the data center or where the applications only need to be externalized for in-house usage.

When it comes to implementations of SOA, the choice of partner becomes extremely relevant. Having the products that can provide an easy way to rejuvenate green-screens through screen-scraping technology, for instance, as comForte offers today with JPath,will be welcomed by companies capable of only making a minimal investment, but in terms of application modernization, its value is lessening with time. This has as much to do with training, as it still requires developers to be aware of the NonStop server, and today one of the main advantages of implementing SOA is that it reduces the need to be aware of where the applications resides.

Returning to Stephan’s comments, there’s clearly the choice to use SOAP / XML for the underpinnings of a SOA implementation, but there are choices. The architecture is proving extremely accommodating and shouldn’t be thought of as restricting the actions that can be taken. When comForte aquired the CSL product suite, it broadened the scope of possible implementations offerings that they could market. Coming from green screen deployments isn’t the only path leading to SOA, and there’s even more users with a variety of client–server implementations.

CSL offers substantially more return on investment as it offers three distinct approaches and companies can start out small and grow at their own pace as they develop the expertise. CSL provides an API that client developers can use directly to interface with Pathway servers. CSL also provides a stub that’s generated out of the CSL Studio product which greatly reduces the amount of client development involved. In both cases, it is the native Pathway message that is sent from the client so some awareness of Pathway on NonStop will be apparent. However, in terms of performance both, usage of the low-level API as well as the code (in the form of a code stub generated by CSL), will require a lot less CPU resources than other SOA options.

However, should the decision be to go with SOAP and the CPU resources are available, CSL SOAP provides a product for externalizing existing Pathway applications as services, as well as any new Java, J2EE, or even .Net applications that may be present on the NonStop server. In all cases it will be SOAP messages sent over HTTP connections to the NonStop server where no knowledge of Pathway on NonStop will be expected of client developers. With CSL, the NonStop as a server (and even as a client) will honor the contract for services that the exchange of Web Services Definition Language (WSDL) files represents.

As a model for exchanging data and leveraging business logic, the services model offers considerable value, and as company’s IT looks ahead to possible greater deployment of private cloud computing, even more relevance will be placed on the need to externalize applications as services. For those companies just concerned over the need for modernization of their software, and would like to ensure that they retain options when it comes to trade-offs between performance, reliability and safety, the choice of products does exist. For the NonStop community, the presence of comForte’s CSL products caters to such companies and shares their concerns.

1 comment:

  1. I agree on all points Richard, I also like you analogy to cars (and SUVs too).