Interoperability with Delphi's SOAP implementation

By: John Kaster

Abstract: Borland is participating in the SOAPBuilders Interoperability Lab "Round 2". The article has been updated on Nov 5th.

Borland is participating in SOAP interoperability testing with vendors providing other SOAP protocol implementations like Apache SOAP, EasySoap++, GLUE, .NET, SOAP Lite, and others. We have put up a Delphi-based SOAP server machine that everyone is welcome to test.

SOAP Interoperability Test Suites

One of the promises of SOAP and Web Services is interoperability among various suppliers of Web Services. Interoperability is a key point to the future success of Web Services. There are a variety of data types you can use web services, so specifications that provide a standard checklist of operations are very valuable in determining interoperability levels. Some test suite specifications are provided on the WhiteMesa web site at http://www.whitemesa.com/interop.htm.

For information on Web Services and what they can do for you or your organization, see David I's introduction to Web Services in his Sip from the Firehose article.

Delphi SOAP interoperability server

Borland has a a machine with Delphi implementations of 'Round 2' Services of the SOAPBuilders Interoperability Tests. Initially, the server has only the 'Base' and 'GroupB' services. The Delphi-based services are listed on the WhiteMesa. You can also access them directly from http://soap-server.borland.com/WebServices/Default.htm

Delphi client in progress

A client page is being worked on that will show the results of Delphi Clients invoking the other SOAP implementations. Jean-Marie Bruneau Babet (he goes by Bruneau) will provide more information on that when it's available.

Results of other SOAP implementors invoking the Delphi Services have started to come in. Bruneau (and other R&D members) will work to resolve any issues where Delphi's implementation is the culprit of failed calls. Borland is updating the Delphi soap server more frequently than some of the other particpants run their tests, so test results you see from other participants may not reflect the current compatibility level of the Delphi-based SOAP server.

Where should reports go?

We would like your suggestions for the following questions:

  • What would be a good way to relay these issues to those of you who have deployed Delphi Services?
  • Would it be best to collate the issues on a 'Server Results' or send 'Interop Alerts' posts to the borland.public.delphi.webservices.soap newsgroup?
  • Please let use know if you have any preferences about reporting our results. or other ideas by either leaving a comment for this article at the link provided on the bottom of it, or by posting a message in the Delphi SOAP newsgroup. Thanks.

    Additional information

    Speaking of the SOAP newsgroup, here's additional information provided by Bruneau that provides more background on the interoperability work.


    Question: Would someone at Borland care to explain what the site is for?

    The 'SOAPBuilders Interoperability Tests' is a place (there are others) setup by SOAP implementors that aims at improving interoperability among various SOAP implementations. (From reading the early posts at the SOAPBuilders newgroups, I understand that) It evolved from tests Apache SOAP and SOAP::Lite had built to improve interoperability between their two implementations. (see http://groups.yahoo.com/group/soapbuilders/message/4) Delphi is very new to the Interop: I enabled the endpoint about 3 weeks ago and I'm still working on various issues/reports I've received since. Participants implement one or more of the Services the group has agreed to (Delphi currently implements 2 of the 3) and provide public enpoints for them. Other participants can then invoke each implementor's service and publish the results. I have the Delphi client implemented and have invoked the other services: I am now working on the HTML layout to display the results in a format that's more than a bunch of XML packets.

    Question: In what way can we in the Community can help with testing?

    The best way to help is to let us know of interop issues. I am quickly learning to use other SOAP implementations. Installed on my machine is Axis, GLUE, VS.NET, PocketSOAP. However, since I don't use these toolkits on a regular basis, I don't catch every interop issue.

    Another way is to let us know where we should focus our interop efforts. There are 18 endpoints (not including Delphi's) listed out there currently. It's unfortunate but we can't run thorough client and server side tests against all of these implementations each time we update the implementation (It's hard enough to run the matrix of in-house tests just between Delphi/Delphi and Delphi/Kylix - and things will soon get harder in-house with Java and C++ thrown in the mix).

    As you look at the current Delphi results from various vendors, bear in mind that several of the problems exposed have been fixed. I spent the first week after we went live in major bug fixing mode. The issues were far-ranging (from simple issues like '1'/'0' for boolean values, 'Nan', 'INF', '-INF' for floating point values to more involved onces involving encoding, node prefixes). I don't think we'll fix every issue because - unfortunately - changing something to interop with A may mean breaking interop with B.

    I hope the above answers your questions. Please do post (or email me @ bbabet@borland.com) any feedback, suggestions, or comments regarding the interop.

    Regards,

    Bruneau.

    PS: I'll post something here when I have the Client page illustrating the result of Delphi Client invoking the Service of other implementors.


    Bruneau has already continued this conversation on the Delphi SOAP newsgroup, so rather than trying to keep up with him in this article, I suggest you go there for the latest.


    Server Response from: ETNASC03