SOAPBuilder's Interoperability F2F Meeting - Round 5

by David A. Chappell

I recently attended a face-to-face meeting for the SOAPBuilders Interoperability group. The f2f was a 2 day event that was hosted at the Burlington Sun complex. I was there representing Sonic Software and Apache Axis...and also gathering some good fodder for the 2nd editition of the Java Web Services books (JAWS II). Here are my notes from the meeting.

About SOAPBuilders

<From SUN Web Site">

SOAP Builders is a loosely organized forum of SOAP vendors working towards a testbed for interoperability testing between SOAP implementations. Interoperability is demonstrated by implementing a canonical set of tests that are collectively defined by the participants in the forum.

Vendors prepare test specifications for testing interoperability between their implementations. Each vendor then publishes their service endpoints publicly so that other vendors can test their clients against them and vice versa. Any issues are then resolved through email on the discussion list. SOAP Builders is driven by quarterly face-to-face meetings, during which these tests are defined. During the face-to-face meeting, clients and service end points can be implemented, and interoperability can be tested in a "interop-athon" setting. After the face-to-face meeting, additional test development can occur, and vendors can publish their service endpoints and test results with other implementations.

The test specifications are defined by the participating vendors and classified in "rounds." Each "round" consists of multiple "groups." Each "group" is a collection of test specifications arranged logically. Each test specification is defined as a combination of WSDL and a textual description of the tests within that WSDL.
</From SUN Web Site>

One place to get details of the tests themselves can be found at This latest round was focused on the "Group G" (SwA, DIME), "Group H" (SOAP Faults), and "Group I" (WSDL/XSD) set of tests described at The current set of tests were defined at the "Round 4" meeting.

The primary goal of the tests is to ensure that each web service vendor can serialize XML data across the wire in a form that other vendors can digest and process in their native platform. The tests are by and large based on the concept of an interoperable "echo" test. A Web service client from vendor 'a' generates a remote call to a service implementation that is running under vendor 'b's platform. This can be in the form of an RPC-style invocation or a message based doc/literal style request/response. The SOAP request is received by the service, the data is marshaled into the native form for that particular platform, then resent back to the sender. The sender waits for this response and then compares the data from the request with the data from the response. The tests range from simple "EchoString" and "EchoFloat" to arrays, complex data structures, and multipart attachments using MIME and DIME.


  • BEA - Dave Orchard

  • Computer Associates - Davanum Srinivas (Apache Axis, "dims")

  • IBM - Sam Ruby (Apache Axis)

  • Lectrosonics - Bob Cunnings (WhiteMesa)

  • Macromedia - Glen Daniels (Apache Axis), Tom Jordhal (Apache Axis)

  • Microsoft - Yasser Shohoud

  • Mindreef - Dave Seidel, Mark Ericson

  • OpenLink - Dierdre Gerhardt, Alan Wexelblat

  • Oracle - Eric Rajkovic

  • Sonic Software - Dave Chappell (Apache Axis)

  • Sun Microsystems - Mark Hadley, Vinay Pai, Doug Kohlert, Sankar Vyakaranam

  • Systinet - Stanislav Opichal, Jiri Teskl, Zdenek Svoboda

  • WebMethods - Fred Hartman, Ted Liu

  • The Meeting

    The meeting room was set up with a local network hub such that all participants could do live testing against other participant's implementations. However, the majority of the time was not spent on running the actual tests themselves, but discussing important interoperability issues that were already known.

    Who Owns the Intellectual Property Rights, Anyhow?

    There are a number of solvable interoperability issues that can be addressed by the group, but there is a bigger roadblock currently in the way. The group has no formal legal agreement with regard to intellectual property rights for anything that is "created" by the group as a solution. In recent history there have been companies that have "donated" their time to spec efforts and then chimed in later claiming ownership of the IPR for the results of the committees. I think its perfectly reasonable for a company to be cautious about its IPR. From what I hear, that's a big reason why a number of standards initiatives are moving towards OASIS instead of the W3C (but that's another posting in itself).

    The same issue applies here. Even though the SOAPBuilder's group is not in the business of creating specs per se, the mere act of crafting a solution to an interoperability problem could create an IPR issue. The majority of the participants thought that it would be reasonable to attempt to get the respective corporate lawyers together to resolve this, but some important few were pessimistic about the ability of their own company to agree on such a thing. Its still an outstanding issue with no owner.

    The Issues

    Here are examples of the technical issues on the table, and some action items going forward:

    - Sessions w/ SOAP Headers. Should it be the job of the group to define "session" based conversations and correlation using some sort of conversation ID using SOAP headers? Axis has a nice feature that lets you just set a bit somewhere that says "enable sessions". Dave Orchard from BEA jumped in and explained their SOAP-conversation spec and said we should be using that. There was some disagreement among the group about the approach because on the surface it seemed a bit different than the "session" concept in Axis. Nothing too profound that can't ironed out.

    - Hashtable or Map collection. Java and .NET both have the concept of a hashtable or a MAP collection (an unordered name/value pair collection consisting of multiple data types). There's nothing in the SOAP encoding section of either the 1.1 or 1.2 spec to address this, or the xml-schema spec. Should a schema be required always, or can it be addressed by embedding the xsi:type for each value in the XML data. Currently both approaches are supported by Axis but .NET does not embed the xsi:type. You can't create a HashTable in .NET and serialize it as doc/literal. There should be a serialization spec for this that everyone agrees upon. Apache Soap created one except the namespace was "" so it didn't get adopted widely. Let's create one with a "" namespace. Axis has already implemented a serialization for "Map" data type (key/value pair). MS agreed to use that as a starting point and see how .NET barfs. Are we going to start creating specs for how this should work? Perhaps Apache Axis should be the baseline for everything? Dave Orchard has an action item to send a plea to XML-Schema 1.1 and WS-arch groups to address this. In the meantime what do we do now? Majority agrees to define it here. Glen has an action item to frame the issue and start an open discussion on the SOAPBuilder's list in order define an on-the-wire representation of what a name/value looks like. Dave O's plea to XML-Schema 1.1 and Ws-arch to be predicated on Glen's discussion.

    - DataSet / Rowset. Similar to Collection/Map. Rowset is a single result set, which could be treated in the same fashion as a hashtable/map. A Dataset is more complicated in that it can describe multiple tables and relationships between them. A complex (xml) schema definition is required to describe this for proper XML serialization over the wire. Currently Microsoft is the only platform that supports this well. Its unclear (at least to me) what the other platforms support. Even so, there are issues like should the test be sufficient if the clients consume the static WSDL ahead of time or should the schema be embedded in the message itself and interpreted at runtime? Microsoft supports both models. Axis would prefer inline xsi:types but that doesn't address the complex table relation issues.

    - SOAP Intermediaries. Should we have an intermediary test? Yes. Should it support WS-Routing for dynamic routing? Consensus is the vendors aren't ready to support WS-Routing just yet. Bob Cunnings to define a simple 3 party 1-hop test.

    - Async processing test.

    Should we have one? Yes. Dave Chappell to work with Bob Cunnings on the intermediary test definition to get asynch processing in there too.

    - Polymorphism Test - Sun to write that up. No,Glen to write that up.

    - Interoperability decisions. Even if the group isn't defining solutions, there are decisions and recommendations being made about interpretations of the existing specs that are being discussed and agreed upon. There is a great deal of "tribal knowledge" that occurs that is never documented anywhere. (Someone) to create a FAQ page about interoperability decisions that are made in the f2f meetings. Sam Ruby to take charge of editing.

    - EchoDate Time zone issues. If a time zone is not specified in the date/time element of the request, what time zone should the server defaulted to? UTC? Localtime? What should the server echo back? What if a non-UTC time zone is specified, does the response echo back a UTC? The consensus is that everything should be normalized to UTC. There is also the case for a time value that should be left alone regardless. Think of a "startTime" element that one would want to use for benchmarking of a round-trip across multiple intermediaries across multiple time zones. You don't want the intermediaries mucking with that at all. It can be localtime from the sender's perspective because its only going to be looked at by the sender when the time value returns from its round-trip. The outcome of the discussion is that we need another timezone setting to indicate that a time value should not be mucked with….But that might have IPR issues associated with it. ;-)

    - Currently there is not one definitive matrix of all the SOAPBuilder's participants, with all their advertised endpoints, and all the cumulative test results. Each participating vendors maintains their own list with as much of the cumulative matrix as it can keep up with. Glen owns the domain. This will be used as the central definitive place for this. Glen will point the domain it at one of Sam's Apache machines for the hosting of the actual data.

    - Fault test. SOAP 1.2 is much clearer on how to specify SOAP Faults. Can't jump to that yet, since 1.2 constitutes a change in Fault codes that aren't necessarily backward compatible with 1.1.

    - The next face-to-face will be ~Feb 2003, hosted by Microsoft in Redmond.

    Next week Sonic Software is hosting the XMLP F2F at our corporate headquarters. Keep your eyes open for a writeup.

    I appreciate your feedback on this posting.