Reply

Microsoft and Sun Interop Plugfest

URL: Metro Web Services / .NET 3.5 Plugfest Results

At 5:19 PM on Nov 15, 2007, Geertjan wrote:

Harold Carr's blog reports that the latest interoperability plugfest between the Sun web service stack and the web service stack provided by Microsoft ended very successfully. His blog entry provides a lot of statistics. Let's find out from Harold how he interprets them and what can be learnt in the process.

Harold, who are you?

I am the lead architect for Project Tango , which provides the .NET 3.x interoperability features in Project Metro , Sun's Java web services stack.

Interoperability with Microsoft? Why would one want that?

People who use Sun's Metro stack generally need to have their web service clients and services work with all their partners regardless of the platform used to build those clients and services. Also, Sun's large customers have data centers that use a mix of Sun hardware/software and other vendor's hardware/software, particularly Microsoft software that is ubiquitous on the client side. Even customers with homogeneous data centers usually end up with a mix through acquisitions.

Bottom line: we live in a heterogeneous world. To serve our customers well we need to ensure our products work well in conjuction with Microsoft products.

By the way, Sun's Microsoft interoperability efforts extend far beyond our Metro stack. See our interoperability page for an overview of what we are doing in virtualization, identity, Windows on Sun hardware, etc.

Are there others that WSIT aims at interoperating with and how is that going?

At the present time all our resources are focused on .NET 3.x interop. In theory, Metro should interoperate with any web services stack that implements the same set of specifications (e.g., WS-I BP 1.1 and BSP 1.0, Oasic and W3C WS-*, etc.). I say "in theory" since we only test .NET 3.x interop. However, we have customers that are using Metro successfully with other stacks.

Now, what's a PlugFest, exactly?

Since 2005, Sun has participated in 5 plugfests hosted by Microsoft at their Redmond, Washington campus. Microsoft sets up a lab with clients and services against which we run our Metro stack using a set of test scenarios that cover areas such as security, trust, reliable messaging, MTOM, addressing, etc. As we run the tests against our respective development codebases and find problems, Sun development engineers work face-to-face with Microsoft development and test engineers to determine the cause of the problem. Once we jointly identify the problem we fix the problem in one or both of the platforms and then start that particular test again.

In the earlier plugfest we also convened mini-"seminars" between Sun and Microsoft engineers to discuss interpretations of the specifications and ways to implement them. Now that we are both shipping products based on those specifications that doesn't happen much anymore since we are in a "spec-update" phase.

What are the results of the latest PlugFest with Microsoft?

In the most recent plugfest (Nov 6-8, 2007) we did not test everything. We tested what we had most ready and high priority items (such as Kerberos token support). I gave the complete details of the results in a recent blog entry so I won't repeat them here. We were very satisfied with our Trust, SecureConversation and Reliable Messaging results. And, once we got past the very difficult Kerberos setup phase, our Kerberos token support passed all tests!

Were you surprised by anything?

Yes. Our Trust and SecureConversation testing of the latest specifications mostly just worked right off the bat! That code had only recently been written by engineers in widely separated geographies and had not been tested.

What are the plans from here on?

We will continue to work on .NET 3.5 interoperability for a Metro release sometime in 2008. We do this by using Microsoft's externally hosted services of clients for the test scenarios, by using our own internally hosted versions of the same scenarios, and by adding many additional tests to ensure a robust product.

Anything else you'd like to share?

Three things. Firstly, we are continuing interop plugfests with Microsoft as we both work toward future versions of our products. But we both ship interoperating versions at this time - .NET 3.0 in the case of Microsoft, and Metro 1.0 (built into GlassFish V2 FCS (b58g) - and it works in other containers such as Tomcat) for us. The shipping products are based on specifications that had been submitted to Oasis and W3C but had not yet been standardized. Those specifications have since been finalized so we are both updating our interoperability to be based on the standards. We, or course, will continue to support our currently shipping product even after we ship the new version.

The second thing I'd like to mention relates to WS-* FUD and the SOAP versus REST debate. First of all, I'm a big fan of REST. (Sun has a REST framework. See Jersey - based on JSR 311.) But SOAP (and WS-*) has its place. If one finds that they need the capabilities provided by SOAP/WS-* (end-to-end reliability and security, service descriptions, etc.) there is NO need to learn or even know of the existence of the WS-* standards. Those standards are used by Sun (and Microsoft, BEA, etc) engineers to build the infrastructure to support those capabilities.

Web service developers don't need to know the WS-* specs. Instead, when one sits down to NetBeans IDE to work with Metro, one sees a menu of functional features. You just click on what you want to use. What goes on beneath the covers (e.g., WS-Policy assertions added to WSDLs) is completely invisible. Of course, if you do want to work at the lower level, Metro does not prevent that.

And finally, if you use Metro we'd like to hear from you: What works well? What needs improvement? What needs to be added? What are your use-cases?