> cbbrowne@cbbrowne.com kirjutas N, 03.04.2003 kell 02:01:
> > mlw wrote:
> > > I think you are interpreting the spec a bit too restrictively. The
> > > syntax is fairly rigid, but the spec has a great degree of flexibility.
> > > I agree that, syntactically, it must work through a parser, but there is
> > > lots of room to be flexible.
> >
> > This is /exactly/ the standard problem with SOAP.
> >
> > There is enough "flexibility" that there are differing approaches
> > associated, generally speaking, with "IBM versus Microsoft" whereby it's
> > easy to generate SOAP requests that work fine with one that break with
> > the other.
>
> Do you know of some:
>
> a) standard conformance tests
>
> b) recommended best practices for being compatible with all mainstream
> implementations (I'd guess a good approach would be to generate very
> strictly conformant code but accept all that you can, even if against
> pedantic reading of the spec)
The problem with a) is that SOAP, unlike CORBA, doesn't have the notion of
standardized language bindings. That makes it tough to be sure that your
implementation is "standard" in any meaningful way in the first place.
The "best practices" have involved scripting up interoperability tests where
they construct sets of functions with varying data types and verify that "my
client implementation can talk to your server implementation," and vice-versa.
And when you run into problems, you chip off bits of code until the block of
stone starts looking like an elephant.
In order to have confidence of interoperability, you have to test your client
library against all the servers you care about, or vice-versa. That's
definitely not the same thing as being a "conformance" test.
Trying to be "really strict" doesn't seem to be a viable strategy, as far as I
can see...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/wp.html
"The cost of living has just gone up another dollar a quart."
-- W.C. Fields
