Application platforms are often like chunks of private real estate. If you have some sort of relationship, you are invited in. If you want to go next door, you will probably have to go back onto the street before ringing the neighbor’s doorbell because, unless you are very familiar with the people you are visiting, they will probably not let you cut directly through the back yard to the neighbors place. Chances are there will be some sort of fence, natural barrier, or No Trespassing sign in the way.
It’s the same with application platforms. If you are a Java developer and are working with a Java-based web application, you might be treated as part of the family. Of course it depends on whether you are writing against a compatible back end that uses the same transaction and persistence models. If that’s the case, you could figuratively cut through the backyard and not have to go back out to the street. If not, you might as well be writing against .NET or other platform, meaning you could not write to it directly.
If you are writing a complex, highly distributed, transactional web application, you will probably have to treat each Java or .NET instance as independent transaction systems that will each require their own housekeeping when it comes to running an application. That is, if System A works fine but System B crashes, you will have to treat each as self-contained systems; you would not be able to roll System A back if B crashed.
In highly complex transactional environments, there are good reasons to different zones autonomous to avoid single points of failure. But depending on the application, there are equally if not more compelling reasons to treat them as a virtual single entity. Until now, the most effective way of doing so was through dropping to neutral, loosely coupled architectures such as SOA, which are theoretically supposed to enable the dynamic chaining of independent entities through elf contained services transactions that manage themselves. Or you could have taken your chance writing your own transactional logic, but that’s a pretty klugey approach that gets awfully brittle each time some piece of code or underlying platform changes.
JNBridge has just introduced a more traditionally tightly coupled option, which lets you write a Java application against a .NET source so that if one goes down, it roll back the other so the systems are not out of sync. An evolutionary development in the progression of Java-.NET interoperability, JNBridge’s feature will be useful for exceptional situations where you have heterogeneous systems that must be tightly coupled.
In the end, the decision to use SOA or a directly bridge using the JNBridge approach boils down to the architectural argument of whether it makes more sense to write tightly or loosely coupled systems. JNBridge CTO Wayne Citrin makes an interesting argument over the topic. Tightly coupled have their benefits, especially if the logic is relatively static, and performance requirements are strict. Otherwise a loosely coupled approach becomes the better option if either of the moving parts are likely to evolve independently and/or have the potential for reuse. At least JNBridge now gives you the choice in a scenario where No Trespassing signs were traditionally the rule.