Codemesh technologist Alex Krapf on Interop

By Jack Vaughan

Alex KrapfAlexander Krapf [left] is president and co-founder of Codemesh. He worked with Hitachi back in the early CORBA days, and since then he has been involved equally in .NET, C++, and Java. We were glad recently to sit down with Alex and discuss some of the ins and outs of interoperability today. We present these in parts, starting with a discussion of early milestones in .NET-Java. That means a look at early JNI.

At the turn of the century, a healthy number of C++ shops were adding servers built in Java. The question often, said Krapf, was how one could leverage established utilities. There were DLLs that were responsible for logging data access – basically a whole slew of things that one could not leverage from the Java side. Krapf saw benefits on use of CORBA in some instances …

“In CORBA you would create an interface description in IDL and then have whatever ORB you were using generate bindings for you in C++ or Java. But it was a layer of abstraction at the component level, not the API level,” he said.

Krapf uncovered a solution, but it was not fully optimal.

JNI rises

“I stumbled over JNI,” he said, pointing to the Java Native Interface. “It was totally unusable if you wanted to create a large scale integration solution. It was too easy to create bugs and too hard to debug them.”

“What was needed was something to make JNI very easy,” he said. He had an idea about code generation. Of course that meant deeply understanding JNI.

JNI is ‘the assembly language of the JVM.’ It is a C interface that lets you call out of Java to C functions. It is part of the Java spec. If you think about it, there has to be something like that. Otherwise, how does Java integrate with native files system services, for example. There has to be some integration layer, and that is essentially what JNI is.

Mosty people avoid it, and correctly so. It is good for them to avoid it. It’s very reliable because it has to be. It is the core of Java sitting on the operating system; it is the core of how you launch Java. How does a JVM start? When you kick of a java.exe, somehow you have to start a JVM. It’s done through a JNI. It’s a way to load a JVM into a native process. It’s done through JNI.

What we said was ‘there is wealth of Java functionality out there. People are starting to write more and more Java software, yet they are sitting on existing C++ software.’ We bet there were enough people that wanted to Java-enable their existing C++ software.”

For example, you have an existing MFC app on Windows and now you want to have it talk to a EJB server, or you want to have it talk to a Java message queue.

What kind of software architects choose this type of solution? We asked. Very often, it seems, it is not exactly a choice.

Said Krapf: “Very often people don’t choose to interoperate; they are forced to interoperate.”

Give me rewrite!

Any time an integration is under consideration, the specter of the rewrite arises. When you have a lot of C++, for example, why not rewrite it in Java. Surely someone will suggest it.

Krapf said it is not likely a favorable course. “When you think of the use of resources required for rewriting software in another language, there may be some reasons to do it, but, from a technology point of view, it is a huge waste of resources.”

“Now you shoulder the burden of the rewrite, and, in the case of C++, there are very likely things in the code that you cannot understand,” he said.

Even ‘broken’ elements may need to be recreated. “There may be bugs your software is counting on,” said Krapf. “Usually you can’t do a one-to-one translation.”

The problem is not unlike the Y2K problem, to again hearken back to the turn of the century, because one encounters legacy code dependencies.

“C++ apps are full of unintended side effects. Things like explicit conversions. They make C++ code so hard to read, unless you step through it in the debugger.”

And such projects seldom go far without individuals suggesting the code can be cleaned up. The specter of refactoring also arises.

Says Krapf: “People refactor, and what they thought was a three month project turns into one year, because they’ll end up completely rewriting the app, rather than porting it.”

> > >>

With Juggernaut as its flagship offering, Codemesh has progressed, adding various elements. Krapf and his crew have faced the continued challenge of updating its software to deal with changes on the various sides of the platform divide. The areas that change may surprise some. Krapf remarks that “C++ changes all the time. The language is fairly static, but the compilers change.”

As people switch compilers, new issues come up, bindings must be updated. Meanwhile, certainly, new versions of .NET have to be studied for elements that it would be useful – or necessary – to update. This was interesting to me – to see platform and framework change from the point of view of an Independent Software Vendor [ISV] who must ensure the fit and finish for customers. Of course, the backdrop is a software landscape now highly influenced by open-source and free software, where end users often must take on the role of Versioning Meister.

Updates in .NET, particularly, have led Krapf to consider how Generics can play in the new interoperability milieu. It is worthwhile to consider, he said, taking Java Generics and translating them into .NET. But, to do it for all APIs, he adds, “is not as trivial as it sounds.”

There are two major pieces to CodeMesh technology .. one is a code generator that has built-in heuristics concerning Java and C++ or .NET target languages. And the other piece is “a runtime library that has all the built in smarts about interacting between the two technologies.”

Said Krapf:

So, for example, the runtime library includes a runtime configuration so that people can specify what is the Java class path of their mixed language application, what are the JVM options that should be enforced, and it maps some very basic types to each other, for example, the string type, which is a built in type in both Java and .NET, so we have to do a translation between the two type. And things like that are part of the runtime library. It is essentially a utility API that we have created to talk from one language to another language.

And the other major piece is in the code generator, which knows how to map from Java Type A to the corresponding part in .NET. That’s what many people miss when they do proof of concept on things like this.

Type System Issues

When you think about it, among various designer pitfalls looming in interoperability or porting scenarios, the issue of the ‘working proof of concept’ is one of the deepest and darkest. It may work. It may prove the concept. But it may not come close to covering every instance, or even just the most typical instances.

While by no means suggesting this represents every scenario, Alex Krapf can readily describe the general case.

“You say ‘I have a Java type. I will create a matching type for it.’ You spend a week figuring out the pitfalls of JNI. It works. Then you say ‘let’s use it for the API.’ And then you encounter type system issues, such as interfaces and abstract types. You did it for a concrete class, now you want to map the inheritance hierarchy because you want to be able to, for example, use a string instance, in every place where an object can be passed as an argument to a method,” he said.

“Then,” he continued, “you find you have to worry about the type system – about the relationship between the types. And that’s were it becomes very non-trivial to create a whole ecosystem of cooperating types - types that work together.”

Advises Krapf, “What is simple for one type is totally non-trivial for some other types. It’s not the 700-types-times-the-effort-for-one-type. It becomes much more difficult.” - By Jack Vaughan

> > >>

TheServerSide Interop Blog has covered Web services extensively. But not to the inclusion of other methods of achieving interoperability. One premise we have pursued – one that is not a natural fit with the Silver Bullet mentality of most software marketing, is that Web services is not the be-all and end-all – not the answer to every question. Okay, so that’s out of the way. The matter came up as part of our recent discussion with Alex Krapf of Codemesh, maker of Juggernaut.

We asked Alex about Web services. He said: “I think of Web services as the CORBA of our day.” We asked why he said that.

Alex said: “In the old days, everybody was into CORBA – everybody but Microsoft. And it was the way to create language-portable distributed solutions. When Web services started, it started with SOAP. And essentially what people did was they said ‘we will create human readable messages.’ XML was the hot thing. So, they said, ‘let’s use XML to talk one to the other.’ A fine idea - why not?”

We interrupted, saying that XML was verbose. On top of that, it was tentatively suggested, Web services, and SOAP especially, gained initial traction because they were simple. But they immediately became more complicated, as essential ‘nice to haves’ like reliability and security came into play.

Yes, Alex agreed. Web service hit the problems associated with being verbose and ‘mission critical.’

Engineering problems

“They were following the same progression that CORBA followed,” he said. “CORBA started out as something relatively simple. That had a bunch of technical benefits for object-oriented programmers. In order to be successful you had to be a good client-server programmer. You needed to have a grasp of the languages you were using.”

“You needed to be a good engineer to be successful in CORBA,” Krapf said. “And we are getting to the point where you also have to be a good engineer to be successful in Web services.”

The benefits gained through Web services, you might say, are related to services being ‘out of the box.’ With CORBA, for example, “you had to pay extra for a naming service. Most people just didn’t have access to them,” Krapf said. Essentially, the objective was for distributed objects to discover the server, and that could be a problem. There were a lot of ways in which this discovery could occur.

Different ORBs [from Hitachi, form Iona, from IBM, etc.] could go about discovering servers, and the common naming service was intended to shield you from that by providing for the discovery of arbitrary objects, he said.

Krapf continued:

We now have a much richer programming environment available to us. We have all these built-in types in Java and .NET, hash tables and distributed types and queues, and all those wonderful things. . So when they came up with Webb services, it was like CORBA on steroids right from the beginning. You had all these services available to you just by the virtue of using .NET or Java. It was easy for you to build things on top of the standard. That helped and also fueled I think some of the successes of Web services.But because it was fairly simple you could get into places that you couldn’t get to very easily before.You could write your XML message to an endpoint; to a small device. And that device did not have to have all the full functionality stack. You did not have to have a full ORB running. All it needs to be able to do is figure out where the message body starts and where it ends. Of course this Web services movement is the most significant since CORBA. The free Web services stack that comes with an application server is there and ready to use, right?Of course this Web services movement is the most significant since CORBA. The free Web services stack that comes with an application server is there and ready to use, right?Krapf said he is asked this question a lot. There are caveats. “It is essential,” said Krapf to distinguish whether or not you are solving a distributed services problem that you might have had – now with different characteristics – some years ago - one where you used CORBA.”

Of course this Web services movement is the most significant since CORBA. The free Web services stack that comes with an application server is there and ready to use, right?Krapf said he is asked this question a lot. There are caveats. “It is essential,” said Krapf to distinguish whether or not you are solving a distributed services problem that you might have had – now with different characteristics – some years ago - one where you used CORBA.”"If it is like that, then you can use the Web Services,” he said.

But if it is a language integration problem, then Web services is probably not appropriate for you, Alex said.

> > >>

Language interoperability

In-process interoperability can look like a difficult path. Yet, alternatives such as standardizing on a single platform or creating Web services can be similarly daunting in the final analysis. As some SOAP users have concluded, some services solutions are deceptively simple. For his part, Alex Krapf of Codemesh asks if they are not sometimes a mis-use of resources. He cites an example.

“Take JMS, for example. You have a .NET application and you want to hook it up to a JMS topic feed. Stock quotes or something. You will probably create a Java application that will listen to JMS feeds and will publish a Web service that others consume.

“Now think about what is happening here. You have a message system written in Java that sends messages for consumption. You translate the Java message to XML and you are sending it out over the wire for consumption.

“This, for me, is an obscene waste of resources.

“The problem you are trying to solve is that your .NET application is consuming a stock feed that comes over the wire. You introduce failure modes. Think about the network load. Every message gets duplicated.

“It is a chunky solution. It is overkill.”

People do not think about this problem at the abstract level. Few think of it as language problem, said Krapf. But it is worth considering. Of course, Krapf feels strongly on this matter. His company is based on solving the language interoperability problem.

Client side interop

Much of the discussion around interop hinges on client applications accessing server apps. For a time, the Web browser has sufficed as a ubiquitous client. It’s shown that it has its limits, although these have been lately obscured by some startling achievements with AJAX-enhanced Web browsing.

Looking forward, interoperability issues may center here. Said Krapf: “I think the next big thing is going to be the client side again.” In the past, he has blasted AJAX for solving the real problem.

“My premise is that we need a rich client deployment infrastructure, and that is where all of this is headed,” said Krapf. “There is a need for rich client apps outside of the browser, which is not an application platform in my opinion.”

As AJAX progresses, and proponents look for ways to address shortcomings, they make dig deeper holes. Krapf does not mince words: “There are people compiling JavaScript to byte code- trying to make this horrible kluge more palatable!”

Krapf said that versioning remains a most troubling problem facing interoperability specialists.

“Versions need to become first class features. I need to be able to declare a type [across various versions] while maintaining version. But not as part of a source control system outside of the technology I am using.”

Very many of the problems people face are based on the fact that they are forced to update or unable to update, he indicated. Looking forward, the tools - the compilers – they use will have to become “smart” about versions. EOF