Loraine Lawson spoke with Alex Krapf, president of CodeMesh, which offers interoperability and integration middleware.
Lawson: To start, would you please explain your company's products?
Krapf: Basically, myself and the other co-founder, Neil, were both working in situations where the integration between software written in Java and C++ was a huge problem. So, we basically started CodeMesh with the focus of creating an integration tool that would allow engineers to make that integration very easy. That was JunC++ion, our first product, and we came out with that in 2000.
That's been a very successful product. That tool has been used to take, for example, a Java enterprise API, it could be EJBs (Enterprise JavaBeans) - it could be the Java message service, anything that you want to use in your enterprise to provide some business services - and publish it, to C++. For example, because you have a legacy C++ application, you've invested decades in the creation of that application, and now all of a sudden, you need to Java-enable it. It needs to be able to talk to your new infrastructure that you're using in other parts of the enterprise. That's one of the goals, and that's what JunC++ion allows you to do.
When Microsoft came out with .NET, we immediately said alright, that's a winning technology, let's put Java into that because we know for sure that Microsoft is not going to put Java into that mix. And that was our second core product, JuggerNET, which does something very similar to JunC++ion, only instead of doing it for Java and C++, we do it for Java and C#, and that gets us into the entire .NET world, because once we support one of those languages, we really support all of .NET.
So those are the two core products, and then we built a few solutions on top of those two core products. Basically, we looked at what our customers were calling us for, they said, we have this integration problem, and pretty soon we realized the pattern. Many of our customers really wanted to use the Java message service from C++ or from .NET.
So we said, alright, we can save them at least one more step here, which is using our tools to generate the solution. So, we created our JMS Courier product, which basically takes the Java message service, and we use our own tools in-house and create a packaged solution that allows customers to use the Java message service from C++ and from .NET.
Lawson: Do people buy you as a standalone product, or are you usually integrated with a bigger partner, a middleware partner?
Krapf: We have end users. For example, right now we're going into the fourth iteration with a food services company in Germany. They became one of our first customers of JMS Courier in 2001, and they are now becoming a JunC++ion customer because they want to extend the set of types that they have access to, and they are using it in their end operation.
That's actually also a fairly interesting use case, because we hadn't heard of them in many years. They never paid up on support. After the second year, we thought they had stopped using the product, and then all of a sudden, they came back and wanted support, and I said, "Well, you're not a supported customer anymore, I didn't even know that you were still using the product." And they said, "Oh no, we're happily using the product, we just haven't needed support. We have it running in our back office servers and nothing has been happening, so now we're just interested in doing it in a new platform" - they're switching to 64-Bit Linux and were interested in doing it with more Java types.
We have a very nice partnership with a firm called Sisco, it's not the big switch maker. They create software that is used by electrical utility companies. And I don't even know exactly what it is that their software does, but I think it has to do with monitoring and distribution, and accounting for energy that's being created and transported and things like that. And clearly that's a case where there is a great demand for integrating into other systems, and lots of people have built Java-based infrastructure.
Sisco is a C++ shop, so they used our product to take the Java APIs that they needed to talk to, expose them to C++ and then integrate them into their application. So, in their case, it was completely driven by their customers' integration needs.
And then we have, at the opposite end of the spectrum, our middleware customers who are creating solutions for their customers. One of the biggest ones, a name I can't mention, but it's probably the biggest information services company in the world, they integrate our co-generator into one of their products as an invisible component. So, when you use one of their data integration solutions, and you check the box that says I'm interested in calling this from C++, under the hood our co-generator is being invoked to generate the C++ bindings.
Lawson: How are your three products classified? Are they adapters?
Krapf: Technically, I would call them adapters, yes. I mean, if you're looking for a pattern, you could call it a bridge, you could call it an adapter.
They have some characteristics that make them very different from other adapters that you might find in middleware designs. Normally, when you talk middleware, you talk some pretty heavy technologies. Usually there is a server involved, with Web services for example, you have to have a Web server somewhere. You have to have this process running, and then you need to provide security that people can only call into it if they are authorized. So, you're talking some pretty heavy-duty infrastructure in most designs.
Ours is very different. It uses what we call in-process integration. When you have your .NET application, and you want to use Java, our architecture loads Java into your .NET process, so it's really only one application that is running on your system that combines both pieces. That means you have absolutely no security overhead, because it's like calling a function, only the function is written in the other language.
You also have very, very little call overhead. Rather than packaging everything up in an XML message, and sending it across the network to the server, the server un-packaging it and translating it into the other language, nothing of that happens - it's just a straight function call. That is a little bit more expensive than if you stayed within your environment, but only a little.
It's a very high-performing integration solution; it's almost the opposite of the course that many modern integration solutions have gone. You've heard loose coupling in large systems is typically a design goal? Our integration solution is a very tightly coupled integration solution. And that has the nice side effect that it's very high performing, it's very secure, and it is type-safe, because we expose the APIs at such a high quality, when something changes and you regenerate your bindings, and there is a problem with the code you have written with these adapters or bindings, you typically get a complier error right at development time, rather than a runtime error, which are much more expensive kinds of errors to debug. Very often, they happen on the customer side, rather than in your development lab, so some very nice characteristics there.
Lawson: Correct me if I'm wrong, but is it a little like an ESB, in that it's translating between programs?
Krapf: Think of it as an ESB-enabling component. If you look at most of the modern ESBs, with the exception of Microsoft, they tend to be written in Java. The reason for that is that Java is platform portable, and that's usually a requirement with enterprise service buses, because almost nobody has just one platform in their system.
So, there is the technical reason for Java in the underlying architecture of your ESB, but then you have the problem of getting outside of Java, because many of the applications that you will want to be pieces of your ESB are written in C++ or .NET. So, there's a strong case for Java as the implementing language of your ESB, a strong case for the other languages because those are the client applications that you want to tie together.
And that's where our software fit in, as the bridge that creates a very, very highly efficient and easy-to-use layer between those two.
Lawson: Now, I've heard it said that loose coupling is not recommended in cases where you have a need for high processing speed, and I believe it was high processing in large batches. So then would your product be recommended for those situations?
Krapf: Absolutely. The high performance is one of the key selectors of our product, I would say. When we have customers, or evaluators who come in, you know, one of the first questions typically is, "Why should I use you and not Web services?" Or, "Why should I use you and not this product, or free stuff that we can download from the Web?"
And I say, "Well, try it out. You have an integration problem, and any integration problem can be solved in a million different ways. The question is, what are your technical criteria? There are also business criteria, of course, but if high performance is a requirement, or just high up on your list, give us a try and decide."
Very often, the performance of the integrated solution is a reason evaluators become our customers.
Lawson: Now, you talked about being loosely coupled, and SOA is such a huge thing right now, does your product have a role to play in SOA?
Krapf: Oh yes, as I said, ESB is just, in my mind, one example of a SOA approach, and several of our middleware customers have products that play in the SOA space.
The problem is they play in the SOA space in Java. So, what can they do to play in .NET? They could try to duplicate their Java program, or Java solution in Pure.net, and they would end up having to hire a similar number of .NET engineers as they have in Java. They would be fixing bugs in two languages rather than one, and they would constantly have one language that's behind the other.
That was the experience that made me go after this market, because I used to work at Hitachi, and Hitachi wanted to play in the electronic commerce space. And one of the nice characteristics of the product that we were using was it was available both in Java and C++, and we had components written in both Java and C++. Well, it turns out that the C++ part of that product was constantly one year behind feature-wise, when compared to the Java part. They got things working in Java, and then they ported them to C++, and that's typically what will happen in any organization that tries to play in more than one programming language - there is a favored language.
Now the favored language could be different in different groups, but every group will do things in their language first, and the other language is the ugly stepchild. Typically, firms give up after three or four years of trying to make this happen, because the frustration becomes too big. Customers keep pounding on them, saying, you promised this would be in sync, and now it's not, and you left us stranded. And so the way of solving this dilemma is typically not solving the dilemma. You know, you just say, alright, this is not playing in the C++ space, or playing in the .NET space is not our core strength and we'll just abandon that, and it won't hurt us because the other players in our space had the same problem.
Our tool changes that slightly. You get the ability to focus on your core strength, which is developing some cool Java middleware that does SOA in a nice way, and then as part of the nightly build, you run our code generator over your files and you end up with usable and easily understood .NET and C++ bindings for your Java product.
Lawson: Do you have a margin of error in translating?
Krapf: What typically happens is when you use it for the first time with the default settings, you end up with some code that doesn't compile because of naming issues. That's particularly a problem in C++. I don't know how familiar you are with C++, but there's a pre-processor. Basically, you can say something like, if I used the word "fu," I really mean "bar." And anybody can have different definitions in their code.
We can't know what definitions they have in their code, and that can cause naming problems when one of the Java APIs that are being exposed to C++ clash with one of the things that they have redefined. Then our tool offers the ability to override the names, so you can say, if the name is "this," and normally it would be called "that" afterwards in C++, I want you to call it "this" instead. So, you typically resolve these kinds of issues in the first four hours of your integration, and then you have something that compiles.
Of course, over months and months of development, the developers could introduce new pre-processors definitions on the C++ side and cause the build to break, in which case you would then have to go back into the settings and adjust the naming there. But by and large, it just works once you've set it up.