No, don't worry, it's not a a floor-wax/dessert-topping/toothpaste article this month; it's simply a look at how multilanguage application environments might be used together in highly distributed systems. Interested? Well, don't worry, somebody has to beS Swallow your pride and read on, MacDuff!

Looking at the IT systems of most large organizations is often closely akin to going on a fossil hunt. You dig through the J2EE surface to find a strata of C++ code in the supporting layers. Dig a little deeper and you start finding relics of a bygone age when C and Unix ruled the world. A little more scraping and an outcrop of COBOL is likely to be revealed, or maybe a little PL/1 and then, brushing aside the minicomputers that everyone forgot about, you might be lucky enough to unearth some real assembler. The archaeological metaphor starts to decay here, however. In archaeology, all the creatures in the various strata are dead. In many (most?) IT shops, the creatures from each period in history are actually cohabiting. They are working together to run the business! It's pretty scary stuff.

In short, heterogeneity is the norm. No surprises here; that's the main issue that Web services technology and service-oriented architecture are trying to address in their joint attempt to provide some kind of "Esperanto" and rules of engagement that all these systems can use to communicate (a less costly and more flexible proposition than the custom bits of string that have spent the last few years multiplying out of control). Of course, along with the strata of technology tend to exist strata of technologists, indispensable due to their business knowledge, not to mention their business application knowledge, but hardly next year's news. "That bearded guy in the corduroy trousers and Arran jumperS what does he do?!" (And we haven't even talked about client-side or small-scale systems and their associated entourage).

"So, that's a fascinating statement of the obvious", I hear you yawn. "What's it got to do with WebLogic and transactions?" I'm getting to that...

Well, Hold Up and Stop Getting Shirty
It will not have escaped the notice of the more attentive readers that BEA has application-server technology that addresses two of these strata; J2EE and COBOL/C/C++ on Unix. WebLogic Server (as you all know) is arguably the industry's preeminent Java application server. Tuxedo, meanwhile (as many of you may know), is indisputably the industry's leading C/COBOL/C++ on nonmainframe application server. So why is that interesting? For a large organization it's highly probable that there are pockets of expertise that fall into both Java and non-Java open-systems camps (to take but two strata). Clearly, the best way to get value for money from your developers is to set them to work doing what they do best - a C/Unix guy can't be expected to be a J2EE guru overnight, however good the training course. For the maximum short-term bang for the buck, get him writing the C that he knows and loves; over time, let him migrate to the modern Java world. Wherever he is at any point in time, BEA can provide him with an application server to underpin his endeavors, bringing to bear the required scalability and reliability whilst he concentrates on the business rules - where his focus is adding value to the business. Here, we have a technology migration scenario.

Just Opening a Port and Listening for HTTP Won't Cut the Mustard
Alternatively, maybe the organization is looking to expose a service-based interface to some of its Unix legacy code in order to include it more cost effectively into the new interconnected world. Web services are the key to the language it should speak, but what about the runtime characteristics? If the new service-oriented interface will generate a significant volume of requests to the old logic, just opening up a port and listening for HTTP SOAP requests isn't going to cut the mustard. A runtime infrastructure will be needed to throttle and balance load, not to mention making the resultant online system manageable in production. A good solution would be to move the old C/COBOL/C++ Unix code into an application server environment and we've already agreed (well, I already asserted, and I have the references) that Tuxedo is by far the preeminent UnIX non-Java application server environment. So here we have introduced Tuxedo to provide new levels of scalability and visibility to existing business logic - a technology renewal scenario.

The common thread between the two scenarios is that both envisage a Java application server (and a person of your exquisite taste is bound to have chosen WebLogic!) and Tuxedo coexisting in an operational environment.

The good news is that BEA understands this. WebLogic Server contains a piece of technology called the WebLogic Tuxedo Connector (WTC). WTC's sole purpose is to allow you (from a runtime perspective) to view Tuxedo and WebLogic as a single logical platform - messages can flow back and forth as needed, with the connectivity all defined by administrative configuration. In the technology migration scenario, this allows for the maximum return on developed assets - C or C++ developed in Tuxedo today does not need to be replaced tomorrow with Java, since it can be used from the Java code. Mixed skill development teams can put together applications composed of new (and existing) code in Java and non-Java languages with no integration pain. For the technology renewal scenario, the connectivity was an explicit requirement; it was the driver for the whole effort.

Now I hear a murmur going up: "Hang on, I thought SOAP was the way to do technology strata integration. And how can you be pushing WTC with a clear conscience? It's WLS specific, and I know there are competing Java 2 Connector Architecture-based products available from third parties!" So before you go into a frenzy, let me come back on those points.

WTC is architected after J2EECA, but it would be impossible (at this point) for it to be a J2EECA implementation; for a start, I already mentioned that it's bidirectional (unlike the standard) and as for SOAP and Web services, wellS the standards as they are today lack some features that are needed for enterprise-grade solutions. One of the lacking areas (and finally, I get to the point that ties all this to the theme of my column!) is transactions!

Finally, I Get to the Point
The WebLogic Tuxedo connector can propagate two-phase commit transactions between the BEA WebLogic and Tuxedo environments. In my mind, that is implicit in making them a logically united platform (but that's just the kind of mind I have, I guess). None of the alternative products on the market that I know of (however standards based they claim to be) can do that. They all claim to support transactions, but what they mean is that they can start a Tuxedo transaction from the Java side - not that they can flow a transaction from it (or to it, come to that). In the migration scenario, it could be common for atomic updates to be needed where the data to be persisted has been computed on both sides of the technology fence; remember the scenario involved a mixed-skill development team. Full two-phase commit is needed and it is needed in such a way that it spans the two technologies. WTC provides that. Even for the renewal scenario, it would be lovely for all the systems to be interconnected in such a way that they were loosely coupled enough that they never needed to coexist in the same transaction. Life isn't always like that, and until implementations of WS-Transaction hit the market, WTC is the only game in town.

Oh, and don't forget those client-side, small-scale guys. Wouldn't it be great if they could apply their PowerBuilder/Delphi/Visual Basic- style skills to this unified applications environment! Oh, sorry, I must have forgotten to mention... they can! With BEA WebLogic Workshop, not only can they access the Tuxedo-based resources via an out-of-the-box control, but since the fruits of their labors run atop WebLogic, their transactions can flow as freely as anyone else's between the old and the new technology worlds.

So, in conclusion, the WebLogic Tuxedo Connector is a kick-ass piece of technology (if you'll excuse the hyperbole). By its ability to stitch together the WebLogic and Tuxedo worlds with transactions (and security, come to mention it), it gives you maximum ability to leverage assets in the Java and non-Java worlds with the minimum of developer effort. And did I mention it's free?! Now that's what I call return on investment!

• Don't Fumble the Hand-off