LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget

EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

DevConnections
4/12/2010 to 4/14/2010
Las Vegas
Penton Media

MySQL Conf. and Expo
4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

Does Windows cost Microsoft opportunities?
Microsoft's decision to focus .NET on Windows is stifling innovation due to the specter of...

Going 'all in' on .NET as default runtime
Programmers for Windows Phone 7 will need to use Silverlight and XNA for development

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Guest View: We need a broader view of interoperability


By Wayne Citrin
October 1, 2009 — 
Like many in the developer community, I listened with interest to Microsoft’s JavaOne keynote, in which they presented their vision for .NET/Java interoperability. I came away disappointed, but unfortunately not surprised. Their proposed solution, as it has been ever since Microsoft and Sun started talking about interoperability, was Web services. But Web services are not interoperability. They are intercommunication.

Consider a world where Web services didn’t exist. Microsoft and Sun could have accomplished the same thing by having their .NET and Java components communicate through sockets, or through databases, or through text files in shared folders. Nobody would consider these solutions to be interoperability. These are mechanisms for sharing data or sending messages between self-contained components: intercommunication. That’s fine if all you want to do is share data or send messages. But interoperability can be so much more.

True interoperability between Java and .NET is the ability to access any Java-based entity (e.g., an object, class or method) from .NET code, or vice versa. It’s the ability to substitute something written in Java anywhere one would ordinarily use something written using .NET technology.

For example, what if you wanted to create a .NET-based component that would send and receive messages from a Java Message Service server? Or what if you wanted to use a .NET-based library in an application that was otherwise written in Java? Or what if you wanted to embed a Windows Forms control inside an SWT-based application?

Using a Web service wouldn’t be an appropriate solution for any of these problems, and it’s not possible to use Web services to intermix user interface technologies. Only a true interoperability solution can solve these kinds of problems.

There are a number of technologies that can be used to implement true interoperability between Java and .NET, but I won’t go into them here. A Web search will yield plenty of information. It’s important to point out, though, that a broader notion of interoperability can lead to many advantages over Web services:

•    True interoperability is faster. Web services are tied to verbose XML and to HTTP. Interoperability solutions don’t have to be tied to these technologies and can be used to exchange message that are much more compact, over transport mechanisms that are much more efficient.

•    True interoperability is more flexible. To have a Web service, you need to implement a server. If you’re accessing a simple library, implementing a server is overkill. Interoperability solutions can be used to allow Java and .NET to talk to each other without implementing a special server. The Java and .NET can even run inside the same process. Many different architectures can be supported; with Web services, you just have the Web services client and server.

•    True interoperability has a broader reach. You can only interoperate using Web services if you implement a Web service, or if the communicating components are Web service-enabled. In many cases, the components are not Web service-enabled, and it is technically unfeasible or organizationally impractical to modify the components to implement a Web service. Technologies implementing true interoperability do not have these restrictions and can be used with unmodified legacy code. Source code may not even be required.

•    True interoperability provides more functionality. If you need to expose an entire object-oriented API between platforms, a Web service isn’t the answer. At best, you can expose a few services. The goal of true interoperability is to make anything available across the platform boundary. Web services don’t let you do that.

•    True interoperability increases choice and lowers cost. As a developer, you can choose the platform that best solves the problem you’re working on; if Java is better at solving one part of the problem, and .NET is better at solving another part, you can use both and have them interoperate. As a development manager or software purchaser, you can choose between more software products since you can now consider both .NET- and Java-based products. More products and vendors mean more competition, and that means lower costs.

•    True interoperability expands your market. As a software vendor, your .NET- or Java-based product could only be purchased by customers who were themselves creating software using .NET only or Java only. With true interoperability, you can sell to both .NET- and Java-based customers, and your potential customer base doubles.
Proponents of the Web-services approach may claim that true interoperability requires knowledge of both the .NET and Java platforms, while using Web services requires only that one know how to invoke a Web service on the consuming platform. This is actually a misleading argument, since you generally don’t need to know how to code on the other platform in order to employ interoperability, you only need to know how to access classes in the target API. Instantiating objects, calling methods and accessing fields is the same in Java as it is in a .NET language like C# or VB.NET. The only necessary new knowledge is the knowledge of how to use the API, which is useful knowledge in any case and no different from knowledge of how to use a service exposed as a Web service.

True interoperability, then, is more powerful than the intercommunication provided by Web services, offers a number of business benefits, and is no harder to use than the equivalent Web service. With those advantages, it makes sense for true interoperability to be part of any cross-platform programming strategy.

We really shouldn’t blame Microsoft and Sun too much for focusing on intercommunication and, in particular, on Web services. Microsoft and Sun are each heavily invested in their respective platforms and, to achieve something they call interoperability, have chosen to meet each other halfway through a neutral, technology-independent standard that can be implemented on both platforms.

Since both .NET and Java implement Web services, it’s straightforward to adhere to standards and implement an intercommunications mechanism. For many applications, that’s useful and those technologies should be used. But let’s not pretend that that’s all there is to interoperability, or that accessing a Java-based Web service from .NET—or a .NET-based Web service from Java—is all we can do.

If we do so, we not only do the entire developer community a disservice, we also limit the potential solutions we can create, and the ways in which we can combine components and technologies to solve problems. If we keep in mind that interoperability can be much more than simple intercommunication, and if we use true interoperability technologies, then the .NET and Java platforms can become even more useful and powerful.

Wayne Citrin is CTO of JNBridge, which sells solutions for bridging Java and .NET applications.


Related Search Term(s): interoperability, Java, .NET


Share this link: http://www.sdtimes.com/link/33798
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading