Port 25: The Open Source Community at Microsoft : .NET Development, Java

New Bridge Broadens Java and .NET Interoperability

Peter Galli — Tue, 29 Sep 2009 15:31:00 GMT

Microsoft continues to deliver on its ongoing promise to build bridges between different technologies, and this week jointly announced with Noelios Technologies a new interoperability bridge between Java and .NET through REST.

The Microsoft Interoperability Technical Strategy team has been working with Noelios to build an extension to the Restlet Framework. As such, Noelios has released a new bridge for Java and .NET. It is shipping a new version of the Restlet open source project, a lightweight REST framework for Java.

This includes the Restlet Extension for ADO.NET Data Services, which makes it easier for Java developers to take advantage of ADO.NET Data Services, a set of recently added .NET Framework features that provides a simple way to expose a wide range of data sources, such as relational databases, XML files, and so on, through a RESTful service interface.

This announcement is yet another example of Microsoft's continued commitment to openness and interoperability, and demonstrates the ever increasing use of web standards in our technologies.

Formerly known as Project Astoria, the ADO.NET Data Services defines a flexible addressing and query interface using a URL convention, and supports the usual resource manipulation methods for data sources, including the full range of Create, Read, Update, and Delete operations.

Microsoft Visual Studio 2008 SP1 and the upcoming Visual Studio 2010 fully support ADO.NET Data Services, including the capability to create and consume data services directly from the development environment.

You can find all the technical details of this announcement on the Interoperability team blog here, as well as on the Noelis blog. You can also find a tutorial on this here.

Better Windows Development Environments - One project at a Time

Mark Stone — Fri, 10 Apr 2009 14:45:00 GMT

Discussions of the PC market usually break down into "desktop" vs. "server", as if these are the only platform categories. However, the developer's dev box -- call it a "workstation" to distinguish it from desktop -- is really a separate platform. Remember, when Linus Torvalds created Linux it wasn't because he needed a better
desktop operating system, or a better server operating system. What he wanted was something that could run the gcc compiler. He wanted a developer workstation he could use at home.

Of course the developer workstation market influences other markets. Developers who develop on a platform are more likely to develop for a platform. So winning developer mind share is often about giving them what they want in the way of development environment. And in this regard, open source developers are something of a
different breed.

Microsoft has a great set of developer tools; I've certainly known developers who swear by Visual Studio. But there's something of a disconnect between graphical tools favored by Windows developers and then command line tools favored by traditional open source developers; I've also known developers whose first order of business
with a new Windows workstation is to GNU-ify it.

Ironically, the Internet has a convergence effect, drawing these two camps together. Put developers online, and they can collaborate. Put developers online, and they can not only develop, but they can build, deploy, and test. The workstation has become not so much a computer as an environment. The developer's toolkit includes version control, build management, automated testing, and the need to do all these things as a team rather than an individual. Developer environments have evolved rapidly to adapt to these changes.

The Apache Software Foundation (ASF) seems to understand this evolution as well as anyone, and a number of ASF projects focus specifically on tools for the developer environment (Ant, Buildr, Continuum, Gump, and Maven come to mind as a few examples).

What's interesting is to see the .NET developers following suit, and wanting these same sorts of tools for their development environment. What's surprising is that this .NET effort is very grass roots driven.

"Panday" is a Filipino word meaning "blacksmith", and can also be a reference to the graphic novel super hero of the same name (the graphic novel is also originates from the Philippines). This provides an appropriate metaphor for the name of the NPanday project on Codeplex.

The NPanday project is one of several affiliated with Microsoft's Open Source Lab in the Philippines, and is part of the effort to bring to .NET some of the capabilities found in other open source development environments. The aim of NPanday is integrate Apache Maven into the .NET development environment.This would enable .NET
developers to take advantage of Maven-compatible development infrastructure.

Projects like NPanday are important because they offer developers more choice of tools in a Windows development environment. The more familiar those tools are to open source developers, the more open source development will be done on and for Windows. NPanday is also an important project for interoperability, making it easier to integrate .NET development with other development done using Maven.

Win a copy of the .NET/J2EE Interoperability Toolkit

jcannon — Wed, 31 Oct 2007 17:22:00 GMT

It's been awhile since we've featured any books or authors on Port 25 - you may remember Jeremy Moskowitz on Windows/Linux Integration, and then Linux in a Windows World with Rod Smith. That doesn't mean our library shelves have gone empty though ~ so today we're going to run a small giveaway of some extra copies of .NET and J2EE Interoperability Toolkit we came across. It's a great book on how to open .NET to work with Java and comes with some useful tools on CD - including the The Mind Electric GLUE web services. GLUE provides developers that want to build Java Web services with an easy-to-use, compact implementation of all of the core Web services standards, including XML, SOAP, WSDL and UDDI. It allows any Java object to be instantly published as a Web service and third-party Web services to be consumed as if they are local Java objects.

To Win: All we ask is that you submit the best example of open source interoperability on Windows. It can be a project running on Windows (like Apache), a language (like PHP or Java), or a commerical application - like MySQL. Send them directly to port25@microsoft.com and we'll pick the best 6 stories. We'll close the competition next Friday, November 9th at 12 noon EST. Good luck!

About the book:
Discover how to build applications that run on both the Microsoft .NET Framework and Java 2 Enterprise Edition (J2EE)—and extend your customer reach and system shelf life. Whether your background is in .NET or J2EE, you’ll learn to implement many of the interoperability technologies available today, including Microsoft, Sun, and third-party compatibility tools. Interoperability expert Simon Guest takes a balanced look at the pros and cons of each cross-platform technology presented, including best practices, workarounds, and examples of interoperability solutions in action. You also get interoperability software on CD—plus a wealth of code you can use in your own solutions.

Discover how to:

Use .NET Remoting to enable interplatform connectivity
Write interoperable Web service solutions that show interoperability in a production environment, handle exceptions, and use UDDI
Employ Microsoft SQL Server 2000 to create a shared database between .NET and J2EE
Enable cross-platform asynchronous calling with Microsoft Message Queuing (MSMQ) and WebSphere MQ from IBM
Implement a bridge between .NET and J2EE queues using Microsoft Host Information Server and Microsoft BizTalk Server
Deliver a consistent user interface across platforms through shared session state and shared authentication
Build complex interoperability solutions using Web services specifications for security, binary data exchange, and routing

Java and .NET Interoperability: JNBridge

MichaelF — Tue, 19 Sep 2006 20:57:00 GMT

Update: We thought we would try our videos on YouTube...would love to hear feedback on this implementation.
Sam interviews Wayne Citrin to discuss work his company, JNBridge, has done to provide interoperability between .NET and Java.

Wayne Citrin is the CTO at JNBridge. He is the architect of JNBridgePro, and has been engrossed in Java and .NET interop issues since .NET's beta days. Previously, Wayne was a leading researcher in programming languages and compilers, and was on the Computer Engineering faculty at the University of Colorado, Boulder. He was a researcher at IBM's research lab in Zürich, Switzerland, and has a PhD from the University of California, Berkeley, in Computer Science.

The JNBridge blog can be found here.

Alternate Video Formats
- Windows Media
-Download MP4 Video

Java with half-and-half

admin — Tue, 18 Apr 2006 19:03:00 GMT

I got the chance to spend an hour this week with Dr. Wayne Citrin, CTO of JNBridge. He’s been refining a Java/.NET interoperability product for the last five years – starting out with a risky bet on .NET when it was only in Beta. Back then I was at BEA Systems, we tried to use jCOM as a bridge to Microsoft applications that customers needed to integrate with J2EE systems. There were reliability and configuration challenges with this approach, and we found that as .NET grew in our customer base, we could only advise them to use Web Services for interoperability.

WS for interoperability is a good choice when you can build well-defined contracts between systems and coarse-grained, loosely coupled integration is acceptable (despite the performance and reliability impacts). There are situations where tightly-coupled integration is necessary (specific security requirements; chatty communications), which is where I’d apply a product like JNBridge.

JNBridge handles the conversion of Java objects into .NET objects and vice versa – including management of references on both sides to ensure that object extent is handled correctly, and converting “by reference” and “by value” situations to their correct native implementation. I’m simplifying for brevity, but for more detail you can take a look here.

They have 3 modes of operation – XML/HTTP, Binary/TCP, and Shared Memory (for running on the same server). As we proceeded through the discussion, I was interested in how they dealt with the “complex object” issue, where a Java object contains other objects by reference.

When converting complex objects to Web Services, the antipattern is to marshal the entire object graph into a SOAP message, add getters and setters to the remote proxy that handle write-backs. This causes problems both in communication overhead and performance (that’s a lot of data to marshal to XML; plus this marshalling will happen every time the remote client needs to update a field in the complex object). There are other problems that I won’t get into here.

For these situations, it can work better to have a tightly-coupled integration layer – with JNBridge, you could use their Binary/TCP mode to have a conversion from Java to .NET objects happening on the J2EE server, and communicating with the .NET tier through native .NET remoting.

Another common interop request I hear from software architects is to have BizTalk or .NET interop with JMS (Java Message Service). This is an area that I haven’t seen great solutions to in the past. The best approach from performance and reliability standpoint should result from a tightly-coupled integration at the JMS Client layer; here I would consider deploying JNBridge in Shared Memory mode, with .NET application logic on the same machine as JNBridge and a JMS Client, which would remotely access a JMS Cluster via RMI or your Java protocol of choice.

Now if only Java were associated with Guinness we could call this approach a “Black-and-Tan”… as it is I’ll have to leave it “Half-and-half”.