Making the Cloud, Microservices, and Enterprise IT work!

Web service security is a tricky business.  EVERY service exposed by any service provider, be it .Net, Java, the Mainframe, or any other provider needs to be secured.  Certainly if it’s exposing sensitive data (say customer data), allowing activation of a business process, and most especially if it’s involving a financial transaction. But how do you do it?  While every vendor and (almost) every technology announces compatibility with every web service security buzzword (WS-Security, SAML, X.509, etc.), they don’t describe how to actually make use of all this security data attached to the web service request. I’ve had recent discussions with IBM, Oracle, and Software AG (as leading SOA middleware tool providers) on this exact topic and the results are disappointing. The architecture model for this says that to provide SOA security I should use the tools as a SOA security layer, allowing my services to go about their business and the security tools to grab and pr...

I sat with my client on a major service orientation project as IBM presented their updates to CICS.  My client is a few versions behind (could actually find no compelling reason to bother to upgrade) on their mainframe and wanted to review if IBM’s added capabilities would offer any abilities the project could utilize. IBM’s CICS support for web services is well known by now.  Their CICS updates keep the web service support up to the latest WSDL – SOAP – and WS-* standards.  If you need or want to expose COBOL programs as a web service (and this can be valuable to allow older applications to be partially utilized as transaction engines in their area of expertise) IBM’s keeping the capabilities in line. IBM has also continued to expand a large variety of internal CICS capabilities.  This was a major time warp for me as CICS command line functions, com areas and linkage sections, and various transaction batch and script coding abilities are so dated.  As an...

Bridging tools allow a communications protocol or methodology change. Generally bridging tools are unique one-off solutions and need to be avoided in a SOA integration environment. There will be some instances where only a bridging tool will do, those are when basically the only way to connect or bridge is via that tool. The general rule is reduce bridging tools to the minimum set needed, and use the more generic SOA bus tools to replace them with a single tool or a suite. Why? Bridging tools usually require their own environment (their own server or region) and have specialized configuration parameters and settings. Supporting them is supporting another complete application and technology. But because they are narrow use, the knowledge to support them is usually concentrated within a small group (often just 1 or 2 people). Often a variety of bridging tools are being used in an enterprise as they were brought in over time to make connections that only they could make...at that time...

What is Mainframe SOA? For the purposes of this article, I'm referring to exposing web services from COBOL applications in a mainframe environment. (The specific mainframe environment I'll discuss in this article is CICS.) Today there's a variety of tools and native functions that allow expose of CICS transactions or COBOL subroutines (or full applications) as Web Services from the mainframe. In brief, here's what these tools and functions come to solve: - Formerly COBOL did not handle XML natively. - While CICS began to expose web server type functionality some years ago, it did not have any way to link a web request to a COBOL routine. About 3 years ago both of these problems were solved natively, in somewhat of a limited fashion: - Enterprise COBOL integrated XML processing functions into the base language capabilities. However, COBOL is still limited to creating internal data structures using the standard COBOL data blocks. This means it's poor at handling ...