JavaOne Blog Talk Radio

JNBridge: Java and .NET interoperability

Wayne Citrin, CTO of JNBridge, discusses how to access anything Java from .NET and access anything from Java.

or click here to go to JavaOne on Blog Talk Radio.

Interviewer: We are here in San Francisco for the JavaOne conference, and we are joined right now for our very first interview here in San Francisco by Dr. Wayne Citrin. He's the CTO of JNBridge. Welcome.

Wayne Citrin: Well, thank you, Shaun.

Interviewer: Welcome to San Francisco. This your first time here?

Wayne: No, I went to school in Berkeley, so I know it pretty well.

Interviewer: It's like coming home for you.

Wayne: That's right.

Interviewer: Adjusting the sound a little bit... So tell us about JNBridge.

Wayne: Well, JNBridge has been around since 2001, and we do Java and .NET interoperability. So we have tools for developers to allow them to call Java code from .NET and vice versa. And it's a very high performance tool and very fine grained tool. So the idea is that they can access things - they can actually make a lot of very frequent calls and get very high performance from doing it.

Interviewer: Terrific. What's the history of the company? How long has it been around and -

Wayne: Okay. Well, we've been around, like I said, since the summer of 2001. We're located in Boulder, Colorado, and we started with the idea that when Microsoft introduced .NET, that there would be a real demand for interop. And we thought about how that could be done, and we also looked at the chatter on newsgroups and things like that and there was - overwhelmingly people were saying "this .NET stuff, will it work with my Java, won't it work with my Java?" And there were a couple of offerings out there, but they were more migration. It was more... Microsoft thought all of these people with their Java, they'll just throw it away and they'll start using Microsoft C#.

And some people did, but, you know, it wasn't gonna happen. People aren't going to throw away stuff that works perfectly well, but at the same time, they're going to like - they liked a lot of what they saw with .NET and so they wanted to create new stuff and have it work with their old stuff. And so we saw an opportunity there, and that's what we started working on.

Interviewer: Good for you. Now, you're the CTO, Chief Technical Officer. What does that all entail?

Wayne: Well, what that entails is really the idea of deciding what kind of products we're going to put out, what kind of technical approaches we're going to take, what sorts of technologies and tools we use to develop the products. So really just the whole technical roadmap, where we're going and how we get there.

Interviewer: And why does Java and .NET interop matter?

Wayne: Okay. Well, it matters because you have -you're a company? Most of our customers are companies, rather than inspaniduals, and you're a company and you've invested in a fair amount of infrastructure, usually Java infrastructure. That was the incumbent stuff, the legacy stuff, and now you decide that either you want to do some new development and it's in .NET. Because maybe you like the tooling, maybe you like certain things you can do with .NET, but you don't want to throw away that old stuff. So the whole idea is you need - you want to save your investment. You don't want throw away and start all over again. That's one reason.

Another reason is you may be looking for a library or a component with a certain specific functionality, and it may only be available in .NET. So you have to, even if you really want to do your work in Java, you have to use that product, you need interop. Another possibility is mergers and acquisitions. Companies merge. One company is a Java shop, one company is a .NET shop and you've got to make this stuff work together. So it really does matter and makes a big difference. And actually, there's a fair amount of money involved in making sure that systems work together.

Interviewer: Very good. When many people think of Java and .NET interop, they think of Web Services. How does your solution differ from Web Services?

Wayne: That's a good question. Web Services were really the way that people originally proposed doing interoperability. And the whole idea is that Web Services are standards based, and so if everybody implements the standards, things should just be hunky dory. Well, one problem is that not everybody implements the standards the same way. There are gaps in the standards and ambiguities, and so things don't always work together.

The other problem is that Web Services are really pretty limited in a number of ways. I mean, think of Web Services being kind of like a pipe, where you see at the end a single button that you can press. And maybe there are a whole bunch of other buttons out there, but at the end of this pipe is just one. There's only - you'll only see a service. And you can only access a particular narrow service.

So there's that limit. The other limit is that Web Services are based on XML and HTTP, and XML is inherently verbose. It's just really long strings. HTTP is a relatively slow protocol. So there are performance and throughput issues.

And finally with Web Services, not every legacy application is Web Services enabled. And even where it is, it may be disproportionate to say, "I've just got this little library." It may not make sense to make it a Web Service.

So what we do - is our stuff, instead of having this narrow service, we let you access anything Java from .NET and anything .NET from Java. It's bi-directional, it supports things like callbacks, which are not easy to do with Web Services. You get the entire object oriented API, rather than just a really narrow service.

And it's very fast. We've had one customer - a big international bank decided to do an analysis of our product and do benchmarks, and they found our stuff was several orders of magnitude faster than Web Services. When they were satisfied, they made our product an approved core technology. So now any developer around the world in their company that wants to use JNBridgePro, our core product, can do it without getting special approval from the central corporate architecture group. So those are the main differences between our approach and Web Services and why - I mean, a lot of people use Web Services, and if they do, that's great. But the customers who come to us have tried Web Services and have decided that it really wasn't for them.

Interviewer: Amazing. I mean, it sounds terrific. Congratulations. How does your JNBridgeProduct - Pro product work?

Wayne: Okay. That's a great question. What we have is - a developer wants to, let's say, call some Java from .NET. And so we have a tool that they use at development time, you point this product at the Java code, and by Java code, I mean, the binaries, not the source code. You don't need the source code at all.

You point it at that product, you identify - or at your Java code, you identify which classes you're interested in. You could be accessing hundreds or thousands of classes. If you would say, "I want all the classes," what it does is it analyzes that and it generates what we call proxies.

I mean, there are .NET classes that will look just like the corresponding Java class. They're the same name, the same methods, but they're .NET classes. You take that .NET - the .NET binary, the assembly it's called, and you link it in with your .NET code. Or you do it the other way around. If you're writing Java and you want to call .NET, you point it at your .NET code, it creates the proxies as a Java JAR file that you then link in with your Java code.

So now what happens is at run time, the Java is running - still running on the JVM. The .NET is still running in a .NET common language run time, CLR, and we're communicating - we're bridging between the two. You call the proxies just like they were the underlying Java code. If you want to instantiate a Java class, you instantiate the proxy, you want to call a method, you call the method on the proxy. And what we do is we handle that bridging, we translate the data, bring it over, send the results back. If there's an exception thrown, we send the exception back and you catch the proxy of that exception.

Now, what's really cool is that the Java and the .NET can be anywhere. The JVM and the CLR can actually be running in the same process. They can be running different processes on the same machine, or they can be running on opposite sides of the world across a network. And you don't need to change your code. All you need to do is change the configuration and it should just work.

Interviewer: Amazing, amazing. People hearing can't see how excited you are. Your hands are going. You love what you're doing.

Wayne: Yeah, yeah. I'm very passionate about this. You know, we've been doing this for eight years now, and I still think it's a really cool technology.

Interviewer: That's great, cause sometimes you come to these conferences - like I say, I'm from Las Vegas, you sit people down, they're, like, okay. But you really like what you're doing, which is -

Wayne: Yeah.

Interviewer: Terrific. Good for you. What kinds of customers use your interop products?

Wayne: Okay. That's interesting. Our interop products are used by a wide variety of customers. Right now we have over 350 customers in over 40 countries, and there are special concentrations in financial services, and that includes both banks, insurance companies, manufacturing, there's a big concentration in, media, software companies use it.

One of our - I think that one of the reasons that banks use it - well, there have been a lot of mergers in banks lately and insurance companies, and, you do have lots of situations where one of the companies was based on .NET and another was based on Java. The other interesting thing about those companies is that a lot of the time their back end, their corporate back end, their infrastructure is J2EE based, but they want things like .NET based applications on their traders' desktops. We have one company - it's actually Société Générale in France. What they do is their back end is Java, is J2EE, but their desktop is Microsoft Excel, and they use our stuff to bridge that.

Another interesting example of companies doing this stuff is our customer, KLA-Tencor, that's migrating some of their Java code to .NET. And as they migrate it, they use our stuff as a bridge and then keep moving that bridge.

One of the cool ones is Adobe, who's here on the floor. Their ColdFusion product is a Java based product, and in ColdFusion 8, the most recent version, they added the ability to call .NET code from ColdFusion. Well, that's the JNBridge technology under the hood that they've licensed and are bundling and distributing with their product.

Interviewer: Amazing. You're everywhere.

Wayne: Well, we want to be.

Interviewer: That's terrific. Give us some scenarios in which your interop solutions are used. I mean, anything - any kind of - or all the scenarios.

Wayne: Oh, yeah. No, there are really four different big scenarios. I mean, one of them is, you have a library in one technology that you have to use with another technology. So you have - I mean, an example, we have a customer called 4th Story that does real time -software for real time trading. And they were working with a bank and the bank had a Java API, and 4th Story's product was .NET, and they had to make it work together, just make it work. And Web Services wouldn't work because it was like a fire hose of data. This is, like, real time, many times a second, information coming over. And they said, with JNBridgePro, it had paid for itself by noon of the first day, in terms of development.

Interviewer: Wow.

Wayne: So, yeah, we were really happy to hear that. I mean, another example is, you have legacy stuff and you want new technology. I mean, another bank was creating this Check 21 application. Are you familiar with Check 21?

Interviewer: I heard of it.

Wayne: Yeah, it's a law that allows you to use digital images of checks instead of the real paper thing.

Interviewer: Oh.

Wayne: So they needed to create a website that would show these images, both internally and for customers. And so they had an underlying, I think a WebSphere-based back end, and they wanted to use ASP.NET because it's real easy to build ASP.NET websites. And they used our stuff in between and they saved a lot of money.

I mentioned the migration scenario. The other one that's really cool - and, yeah, there's the Adobe scenario, which is where you have a product in one platform and you want to increase your market share by offering API's and the ability to work with another platform.

Interviewer: Amazing, amazing. I see that JNBridgePro allows users to embed .NET widgets in Java. Tell us about that.

Wayne: Oh, yeah. This is one of the coolest things. This is almost like magic. Let's say you have a graphical widget in Swing or AWT or SWT, and you want to put it in a Microsoft Windows Forms application with a Windows Forms interface. You can just, with our technologies, just drop that into the application and it will just work. And it will work the other way around. Windows Forms or Windows Presentation Foundation, you can drop it into SWT.

And in fact, we use the technology ourselves. We have plug-ins as a part of our development tool. So we have a plug in for Visual Studio and we have a plug in for Eclipse. They both use the same component, that's a Windows Forms component, which works just fine in our stand alone tool and in Visual Studio, and it also works just fine in Eclipse. Eclipse is an SWT application, Java based, but most people who use our product don't realize they're actually using JNBridgePro to make our Windows Forms application work in that.

Interviewer: So your company is really like the foundation of many of these other products. You're under the hood of many of these products.

Wayne: That's right, and we're very proud of that. And we think that's actually one of the best uses of our tool is for, really leveraging the technology for software vendors, to actually take it and use it. Here's an example. There's a - we have a customer called Chemaxon, and they have a widget. It's a 3D graphical viewer to show molecules. They sell it to pharmaceutical companies. And it's Java based, and so up until they found us, they could only sell it to companies that developed in Java. And once they found us, they could take their component, wrap it up in our stuff and make it look like a .NET widget and sell it, just essentially double their potential number of customers.

Interviewer: That's amazing, isn't it? I mean, the technology is - I don't know. I guess it's exciting for you, but Joe Q. Public, I don't know if I should be excited or a little scared. I don't know, cause everybody's got a widget now. I mean, widgets are really the thing now, right?

Wayne: Yeah. Oh, yeah. And if you have one it would make sense. You can run it on a Java system, you run it on a .NET system. It should just - I mean, you can conquer the world, I suppose.

Interviewer: Amazing. Now, if JNBridgePro allows you to access anything Java from .NET, why create targeted adapters for JMS and .NET interop?

Wayne: Well, yeah, here's the thing. We have a couple of different products. We have that core product which is the general Java .NET interop, but we also have a couple of targeted products. And the whole idea there is that customers asked us can our stuff do a particular thing, and the most common thing they asked us was will it work with JMS, Java Message Service, and it will. You can use our core product to work .NET and JMS, but you have to know something about JMS. And for .NET developers, that may be outside the comfort zone. So what we did was we essentially built that all in, encapsulated it in a single product so you can just connect to a JMS server and get a very nice .NET-like interface that .NET developers are comfortable with.

Interviewer: Now, your JMS adapters will work with any vendor's JMS implementation? There you go.

Wayne: Yeah.

Interviewer: $10.00 word for a $5.00 host. But anyway, how does that work?

Wayne: Well, that's pretty cool. Usually when you make a native .NET client for JMS, you code it up so it really speaks the particular language that the JMS server speaks, the protocol. And those protocols are vendor specific. It's not a standardized protocol, so you're kind of locked into a particular vendor. What we do is we essentially leverage the vendor's clients so that - what we do is we use our own technology to bridge between the .NET part of the adapter, the JMS client part, and then let the vendor's JMS client code speak the native interface, which is kind of nice because it means our stuff works with any vendor, and it means that if you get tired of a particular vendor's implementation and you want to switch it out, you can do that without losing our adapter.

Interviewer: What kinds of applications do customers build with their JMS adapters?

Wayne: Okay. That's interesting. We have some insurance companies that essentially have acquired a whole bunch of different companies, and some of them have used BizTalk servers, a big Microsoft product, and others use just standard JMS, and you've just got to hook that stuff together. Again, trading applications, where a lot of trade information comes in as JMS, and you want to process it in a .NET application. We have things like that.

So it's really - and we have big manufacturing companies where they have to load their whole catalog into, through JMS. Just before the application really starts, there are millions of messages that have to be sent out. So a very wide range of applications.

Interviewer: What sort of customers would find that sort of transaction of interop useful?

Wayne: Okay. Well, our new stuff supports transactions. It's really, a transaction is a very robust kind of computation, where it either has to work or nothing happens. There are no halfway measures. And these are important in financial companies, where you've got money coming out of one system and going to another, and if the network goes down or one of the pieces go down, you don't want it to be in this halfway state, because then money may disappear, or data may disappear. And so our new version of the product supports transactions so that data is not lost. You're guaranteed that it either gets to point B or it's as if it had never left point A.

Interviewer: That's important, cause a lot of people - you hear it on the news once in awhile. Oh, the data is lost, we have no - you know, different defense departments, if something happens and they lose all this data, it's good - you're providing the infrastructure to make sure - ensure that doesn't happen.

Wayne: Yeah, essentially that's true. I mean, in specific, very specialized cases, but they're important ones. The ones especially where data is being sent across networks as messages. If I send it to you and you're supposed to do something with it, either you've done it or it's as if it had never left me. We just make sure that that happens. So if it never left me, then later on when you fix the problem, we can start all over again.

Interviewer: Very good. So what's next for JNBridge?

Wayne: Okay. Well, there are a whole bunch of things that we're looking at. We're looking at interoperability using Mono instead of .NET. We're looking at interoperability with .NET Compact Framework and J2ME, Java Micro Edition. We're looking at things like Silverlight and JavaFX, to try to round out the whole graphical user interface thing. And we're spending a lot of time making this whole transaction thing even more applicable to our offerings. So, there's a lot of new stuff out there that still needs to be covered under interoperability, and that's what we're concentrating on.

Interviewer: Very good. Website address?

Wayne: www.jnbridge.com

Interviewer: And Twitter?

Wayne: That's a good question. twitter.com/jnbridge.

Interviewer: There you go. Mr. Citrin, thank you very much.

Wayne: Well, thank you, Shaun.

Interviewer: And we'll be back with more in just a little while. Thank you.