Janice J. Heiss's Blog

Let's Make a Deal: Java and .Net Hold Hands Over Web Services

At JavaOne earlier this week, I took in TS-5540, “Making Java/.Net Technology Based Web Services Interoperability Real” with Sun’s Arun Gupta and Microsoft’s Kirill Gavrylyuk. Sun and Microsoft developers have been meeting at “Plugfests” in Microsoft’s test facilities in Redmond, Washington, where they identify bugs and work to assure interoperability in their web services code. Both have strong customer-driven motivations for removing interoperability barriers between their web services stacks. The collegial environment is reported to have been refreshing and productive. Arun Gupta’s blog has interesting comments:

http://weblogs.java.net/blog/arungupta/archive/2005/11/sun_sleepless_i_1.html

So here were two developers from corporations that once viewed each other as enemies offering a joint presentation. Economic necessity makes strange bedfellows.

Gupta enunciated their basic message: “In this talk, we intend to show you that enterprise web services are real,” said Gupta. “We also intend to show you how web services enable enterprise integration scenarios within and across business boundaries.”

Web services are well adopted on both Java and .Net platforms. Recent developments in Microsoft’s Windows Communication Foundation, which is Microsoft’s web services platform, and the open source Glassfish communities’ compatible app server have made interoperability a reality. They are not just talking about a promising future.

Gavrylyuk and Gupta presented a scenario with a Sun-managed retail quote service which gets quotes from a service running in a homogeneous environment. It gets quotes from a variety of client services, some of which run in a .NET Microsoft environment. It also gets information from a GlassFish client. In both cases they use secure and reliable communication.

They began with consumer integration. Suppose consumers rely on the Sun-managed quote service that uses WCF and Glassfish clients. How to achieve data interoperability? The two managed environments establish what is called a brokered trust relationship through obtaining tokens from STS, Secure Token Service, to authenticate their interactions.

Their presentation next focused on the challenges of integrating both businesses and consumers and the road map for the future. The key issue is establishing a contract through data structures. When it comes to XML schema interoperability, they summed up their advice to developers in the memorable acronym, KISS: Keep Interoperable Schemas Simple. They recommend a simple set of de-facto profiles: xs:sequence, xs:element, wrapped arrays, etc.
There are functional and established complex schemas available and perhaps necessary in scenarios, but Gupta recommended caution in using them.

Schemas should be used as data type descriptions, not as validation mechanisms. Avoid complexity unless it’s required, and avoid schema constructs that do not map well onto programming languages.

They turned to the issue of binary attachments which Gupta acknowledged has had a “bumpy road over the last few years”. xs:base64Binary is interoperable, but comes with a high processing cost and 30% extra message size.

The industry has fallen into two camps: one has gone with SOAP attachments, while the other adopted DIME (Direct Internet Message Encapsulation). Both push the binary data outside of the SOAP envelope. SwA, which is SOAP with attachments, has low interoperability, with attachments outside the SOAP body, and suffers from lack of composition with other web services protocols. DIME has the same problems as SwA.

So what to do? MTOM (Message Transmission Optimization Mechanism) comes to the rescue. MTOM works in a simple manner. It is conceptually like a SOAP envelope, but just before the SOAP envelope hits the wire the binary part of the body is serialized as a separate MIME part.

Integrating Businesses

The key to business integration, not surprisingly, is reliable, secure messaging. With information moving over the web between services, there is a danger of information getting lost and a need for reliable security. Quote service reliability requirements include reliable transfer of messages end-to-end, assurances that orders are not duplicated and secure composition.

They then presented a demo of reliable messaging in which a .NET wholesale service was interacting with a Sun managed Java retail quote service in a reliable and secure manner.
Trust

They turned to the issue of WS-Trust and Security Token Services, which “arbitrate” trust through providing universal token/claim conversion, and support for arbitrary trust patterns in a decentralized manner -- anyone can be STS. They discussed Security Policy and Metadata Exchange whereby
services specify what claims types are required and consumers dynamically obtain tokens through the trust chain.

WCF

Finally, Gavrylyuk discussed Windows Vista Web Services, and the Windows Communication Foundation (WCF -- a.k.a. Indigo) which offers a runtime for building distributed applications. “InfoCards” visualizes a user’s digital identity, Active Directory Federation Services provide an infrastructure for identity and access. Windows Remote Management enables interoperable system management, and something called Web Services For Devices helps with Web Services-based devices interaction.

That's all for now, folks. Bare bones of a technical session but hopefully of some value.

For more meatier or vegy (if you're a vegetarian) details:

Windows Communication Foundation (a.k.a. Indigo)
http://msdn.microsoft.com/webservices/indigo/

GlassFish Community
https://glassfish.dev.java.net/

Web Services Interoperability Portals
http://msdn.microsoft.com/webservices/building/interop
http://mssoapinterop.org/ws/

Web Services Interoperability Blogs
http://pluralsight.com/blogs/kirillg/
http://blogs.msdn.com/dotnetinterop/
http://www.simonguest.com
http://weblogs.java.net/blog/arungupta/
http://weblogs.java.net/blog/haroldcarr/

Comments

• "Schemas should be used as data type descriptions, not as validation mechanisms. Avoid complexity unless it’s required, and avoid schema constructs that do not map well onto programming languages."

  This is a really bad idea! If you put the data validation into the program you open your service for a denial of service attack. The problem ist easy to describe. If you require to load the whole message before you are able to validate the incomming data you require to store all incomming data into memory. Assume sombody sends you a string of about a gigabyte of size, you have to store it before you can say it is to long. Beside wasting bandwith and processor power, the caller can easily detect the amount of free memory and reserve all memory available on this machine. This is a security issue all Java webservice implementations share that I know.

  Webservices are a step back in many ways. Sending XML over HTTP is easier to understand and describe, safer to implement and more interoperable.

  Webservices add a memory bloat of about factor 100. This means for every byte you want to send you need about 100 bytes of memory to receive it. Factor 10 is given by the XML bloat and the other factor 10 by the DOM tree used to read the message.
  And if you have to be fast you will fail with both, XML and HTTP.

  Webservices took about 5 years from the specification to the state of being barely usable (now). Looking at the XML specifications, the J2EE 1.4 specifications look like beginners literature.

  As always, make sure the technology fits to your needs and resist the hype.
  

  Posted by: pinus on May 21, 2006 at 12:25 PM

• Hi pinus. I appreciate all of your thoughtful comments and observations. I'm going to convey your thoughts to Arun to make sure that he sees these. Thank you very much. Jan

  Posted by: hiheiss on May 24, 2006 at 03:56 PM

• I posted my comments to pinus at my blog

  Posted by: kohsuke on May 30, 2006 at 11:43 AM

This work is licensed under a Creative Commons License.