Interop Vendor Adds Transaction Bridging
Java/.NET interoperability solutions provider JNBridge is adding features to the next release of its core interop tool that will integrate distributed transactions between enterprise Java and .NET platforms, the company announced this week. JNBridge 5.0 will support what the company calls "generalized cross-platform transaction bridging," essentially making transactions between Java- and .NET-based components and applications work whether those transactions are Java-to-.NET or .NET-to-Java.
A transaction in this context is an individual unit of information, an "all or nothing" sequence of operations that must succeed or fail in its entirety, explained Dr. Wayne Citrin, JNBridge's chief technology officer. "Think of an electronic banking transaction," he said. "If all the operations of the transaction are successful, then the transaction can be committed. If any one operation fails, the whole transaction must be aborted, or rolled back."
The industry-standard protocol used by transaction monitors to guarantee that a particular sequence has succeeded as a unit is known as "two-phase commit," because it consists of a commit-request phase and a commit-or-abort phase. JNBridgePro 5.0 is designed to manage the two-phase commit protocol for transactions between distributed Java and .NET platforms, while keeping it mostly transparent to the use, Citrin said. An "abort," also called a rollback, on either side will cause actions on both sides to be rolled back; a commit on both sides will cause both sides to be committed. This capability works with all vendors' JEE implementations, he said.
"The idea is that if there are two active transactions, they are going to be unified," he said. "The Java side doesn't know about the .NET side, and the .NET side doesn't know about the Java side."
Citrin, who called transactions "the glue that makes e-commerce work," argued that there have been few successful remedies for the incompatibilities between enterprise Java and .NET transactions and transaction managers. He pointed to TIP (Transaction Internet Protocol), now obsolete, and WS-AT (Web Services Atomic Transaction), which requires cross-platform transactions to be exposed Web services.
Ovum analyst Tony Baer agrees that incompatibilities between Java- and .NET-based transactions has been an issue for companies involved with e-commerce, and that JNBridge is one of the few vendors attending to this interop niche.
"It's often the case nowadays, with applications that are more distributed -- and especially when you start getting into a lot of service-oriented stuff -- that at some point you're going to need to write some direct transactional applications," Baer said. "For example, you might have a dedicated application with some logic written in VB or C# that's going against a Java back-end, or vice versa."
"This [JNBridge] capability means that you can write transactional applications without having to write transactional logic. They've automated the type of thing you take for granted when you code natively. It's going to bridge the impedance mismatch when it comes to transactionality -- things like rollback, two-phase commit, and all that sort of wonderful stuff. It also means that, as you change your code, you don't have to change your transactional logic, your application will be less brittle."
"Frankly, I don't see anything else handling this whole transactionality issue right now," Baer added. "They've added a useful piece to the interoperability puzzle."
The Boulder, Colo.-based company also unveiled new versions of its two Java Messaging Service (JMS) adapters that will support cross-platform transactions: the JMS Adapter for .NET 2.0 and the JMS Adapter for BizTalk Server 2.0. The .NET adapter is designed to integrate JMS implementations directly with the .NET Framework; the Biztalk adapter does the same with the Microsoft's Biztalk Server.
The JMS is an API for enterprise messaging systems, which, Citrin said, supports "a very specific, narrow kind of transaction."
"It groups messages together into what is called a local transaction," he said. "We were able to integrate that with .NET transactions from the program that was consuming those messages."
The new BizTalk Server Adapter 2.0 comes with built-in support for request/response and solicit/response messaging patterns, which match outgoing and ingoing messages. Both adapters also provide a more flexible architecture that allows .NET and Java portions of the JMS client to run in separate processes, or on different machines.
The company announced the new products Monday, but plans to release them next week at Microsoft's Professional Developers Conference (PDC) in Los Angeles next week. More information is available on the company Web site here.