Talking the Talk: Windows, Linux, and B2B

Conversations about Windows and Linux integration aren’t all that uncommon these days, but typically they revolve around shared network resources and user accounts. However, that’s only a small part of integration: What’s also critical is that enterprise applications across platforms must be able to seamlessly, reliably, and securely communicate. This is an important aspect of integration because enterprises run mission-critical applications and services on Windows, Linux, UNIX, and mainframes. It’s simply not possible for an enterprise IT department to do things “one way”.

Vendors that support enterprise environments have long realized this, and software powerhouses such as Microsoft have made great strides to help with across-the-board integration (at least at the server level). For example, Microsoft has products such as Services for UNIX Applications (SUA) and LDAP-accessible Active Directory (AD) for systems managers, and they continue to strengthen their middleware solutions.

SUA and AD are important elements of integration, but this article focuses on middleware and its critical nature in heterogeneous environments.

Before going further however, let’s define middleware. Wikipedia.com defines middleware as “ software that connects software components or applications”. Essentially, middleware acts a mediator between various software components and applications. There is in fact a very large and robust industry around middleware, with players including Microsoft, IBM, BEA, Oracle, and Red Hat/JBoss.

Let’s Agree to Disagree
Middleware is really all about agreeing to disagree. The reality is that there is no one standard for how applications within a platform communicate, much less across platforms. For example, at the process or component level, there are many different ways to enable inter-process communication (IPC). In Windows, we have frameworks such as the Component Object Model (COM), COM+, and .NET. On a Linux server, applications typically use UNIX domain sockets for IPC on a server and various other protocol interfaces (many of which are custom designed for the particular UNIX applications) over TCP/IP for network IPC.

There are projects out there that are trying to port Windows-based frameworks to Linux and UNIX (e.g., .NET with the Mono project), but these only address very specific elements of integration between platforms.

Another contentious issue is document-level data, and how to actually access it between platforms. When working with legacy mainframe and UNIX applications, a common approach has always been to use File Transfer Protocol (FTP), especially in batch-based systems. Transferring document-level data in Windows networks is yet another grab-bag of technologies, including FTP and Windows Networking. (Windows Networking is an especially poor choice across extranets.)

There have been various solutions proposed to these problems, some good and some not so good. An example of a potentially good solution is Simple Object Access Protocol (SOAP). SOAP is touted as critical solution for interoperable application communication--and that very well may be true. SOAP relies on industry standard XML and is communicated over the ubiquitous HTTP protocol, preferably over SSL. (SOAP isn’t the first to attempt this; CORBA is an example of another technology.) If SOAP becomes pervasive enough, it may even assist with document-level exchange via SOAP with Attachments (SwA).

Alas, SOAP, or any one solution, is not a cure-all for what ails us: We don’t control other people’s networks, platforms, and applications. So regardless of how good SOAP or any other single technology is you can’t force everyone to use it. To make matters worse, even if you could immediately dictate a single method of communicating, it would be vastly expensive for you and your partners to rewrite applications to support that standard.

Obviously, this is quite a minefield.

Fortunately, Business-to-Business (B2B) middleware makes life much easier. B2B allows you to support communication with just about any platform and application. Essentially, B2B serves as a mediator between all of the software and platforms that need to speak to you. For example, B2B may speak protocols such as FTP or SOAP, or it may understand how to speak with applications such as PeopleSoft. B2B then provides all of the necessary storage, routing, and transformation work needed.

This is a huge win for everyone. Instead of having to use budgets on retooling existing (and revenue-generating) applications, budgets can instead be spent on new projects to bring in more revenue and further cut costs. And for IT managers working with complex mixed-networks, B2B makes life even easier.

Let’s Save Money
A realistic example will show how B2B can have a very real impact on your budget. Take as an example the company Example Insurance. Example Insurance performs their high-volume claims processing on an IBM zSeries, and uses Windows-based applications for initial claims routing and other front-end tasks. Both systems are equally critical, but both are very different in how they operate.

The Big Project: Example Insurance has decided to add more value for their partners. To that end, they are planning on providing various statistics, such as near real-time claim status, directly to their partners applications.

Example Insurance knows that their partners run several platforms, including Windows, Linux, and UNIX, and that they cannot require their partners to change applications, platforms, or to perform any other significant changes. Thus, a few issues become apparent:

    1. There are several platforms involved, including z/OS, Windows, Linux, and UNIX;
    2. Other than the actual claims data, there is no standard for how to communicate this data with partners;
    3. Some partners support protocols such as SOAP, while others prefer CSV or XML over FTP;
    4. As partners are added, more interfaces may be required.

Initially, this seems both expensive and potentially unmanageable. With B2B, that’s not the case.

By leveraging a product such as Microsoft’s BizTalk, Example Insurance can support a reliable and extensible communication infrastructure with their partners. B2B can be configured to use FTP for partners in legacy environments (preferably FTP over a VPN, or SFTP), SOAP with more advanced partners, and a mix of other connectors as needed. Problem solved.

Conclusion
In this article we explored how applications running on platforms such as Windows and Linux don’t always speak the same language. By using middleware, IT can spread out the cost of supporting these systems much more effectively, and for every platform and application that is integrated into the middleware there is an instant increase in ROI.

For more information on interoperability, go to http://www.microsoft.com/interop.