News

Building Bridges: Deutsche Post AG's Move to SOA

• By John K. Waters
• May 27, 2008

Swordfish was something of a byproduct of a large-scale IT infrastructure modernization program launched by Deutsche Post several years ago. The company transformed its infrastructure, says Steven Engelhardt, an integration expert in Deutsche Post's Technical System Architecture (TeSA) division, with a coordinated set of projects that implemented and reused business services. The result was a SOA framework that brought together the different components needed for a SOA platform.

Deutsche Post used a Java-based Enterprise Application Integration (EAI) solution to unify the enterprise platforms of its various operating divisions and subsidiaries. But as Engelhardt points out, there's no such thing as a homogeneous IT environment: "The platform we were using to integrate our systems into our SOA was primarily based on Java," Engelhardt says. "By the end of 2005, we had only one .NET application: a critical, .NET-based CRM app that we needed to integrate into our SOA."

Engelhardt was asked to integrate the app into the company's Java-based infrastructure without re-implementing the ESB. This CRM system, a Teutonic monster from Glinz Covis, is critical to Deutsche Post's sales and marketing staff, he says. The app had to be able to obtain data from other Deutsche Post systems-things like the customer contact repository and the central customer database: "This CRM application needs to communicate with lots of other systems within our IT landscape," he adds.

Enter Codemesh Inc., a Carlisle, Mass.-based provider of in-process integration technology. Codemesh creates products designed to facilitate integration among apps in Java and .NET, and Java and C++, as well as JMS integration with C++ and .NET. Deutsche Post had worked with the company in the past; it used its JunC++ion solution to integrate a customer complaint management system written in C++ into the service backbone.

"This was a company we knew and we had a good experience with them in the past with the C++ integration," Engelhardt says. "So it made sense to us to use them again."

Making a Mesh of Things
For this .NET-to-Java integration, Deutsche Post used a new Codemesh product called JuggerNET.

"When .NET first appeared, we were skeptical about its staying power," says Codemesh President Alex Krapf. "But we quickly changed our minds and decided to create a .NET version of JunC++ion."

JuggerNET is a dev tool designed to do for .NET developers what JunC++ion did for C++ developers: generate .NET bindings for arbitrary Java classes. It can be used to publish .NET versions of Java APIs and COM bindings for Java APIs, and to integrate .NET clients into JMS or EJB apps.

JuggerNET comes with a code generator that takes the Java byte code as input and generates platform- and compiler-portable C# source files, batch build files and project files. The package also includes two types of runtime libraries: strongly named and not strongly named. Together they provide an abstraction layer around the generic aspects of Java and .NET integration. The JuggerNET runtime uses P/Invoke and JNI to execute the original Java in the CLR process. The runtime library ships as part of the finished integration solution.

The JuggerNET package also includes a shared JVM server to provide an alternate deployment option that doesn't require the presence of a Java Runtime Environment (JRE) on the host that's running the .NET code.

By generating .NET bridge components from Java code, the JuggerNET product cuts-and in some cases eliminates-the need to write integration code. It provides high-level, readable .NET proxies for Java classes, allowing coders to work with the integration code.

From Concept to Production
Engelhardt and his team started their integration project with a small proof-of-concept near the end of 2005.

"My job was to figure out how this worked and how long it would take to get it fully integrated," he says.

"I come from the Java world," he adds, "so I didn't actually have any .NET experience. But it only took me two or three weeks to get fully integrated. It was very surprising for me, but one reason we were so successful was because I had used C#, and the syntax is very similar to Java."

By early 2006 Deutsche Post's TeSA division began rolling the integration into production.

"We had implemented parts of our initial integration of one interface using JuggerNET," Engelhardt explains. "Then we simply plugged in more and more interfaces with more and more IT systems throughout the year."

The process of generating the property classes needed to integrate Java into the .NET dev environment was one of Engelhardt's favorite capabilities of JuggerNET.

"They provide you with a GUI tool. You plug in the Java classes you need core from the .NET world, and it generates everything to you," he says. "And then you just work in the .NET world and you don't need to bother with things in the Java world anymore. It was very intuitive and easy to use."

Click here to read more about "Sun's Java Solutions."