RE: Issue with soap-rpc:result

> Maybe I've misunderstood.  I should confess to not having actually 
> programmed with any of the systems such as .Net that provide 
> automatic 
> document style mappings.  I strongly suspect that they deal best with 
> stylized uses of XML, in which case they are in some sense 
> encoded.  I 
> could be wrong about that.  If so, please let me know what 
> I'm missing.

ASP.NET WebMethods support an RPC programming model on top of
"document/literal" messages by default (you can enable SOAP encoding if
you want to). There are two major limitations:

1) No support for derivation by restriction
2) No support for graphs

The first problem is simply an implementation issue that can be fixed
later, it just takes time. The second problem exists by design: they
want all messages to be literal instances of a generated schema. The
practical side effect is that graphs will be converted to trees. For
instance, if you make a call like this:

Point p = new Point(10, 20);
float f = proxy.Distance(p, p);

the resulting SOAP message will look like this:

<soap:Body>
  <ns:Distance>
    <p1><x>10</x><y>20</y></p1>
    <p2><x>10</x><y>20</y></p2>
  </ns:Distance>
</soap:Body>

In this case, the ASP.NET plumbing assumes the first child of body
identifies an operation and each of its children is mapped to a
parameter. The implementation of the remote endpoint will deserialize
two Point objects with the same x and y values. As a result, the
implementation of Distance cannot compare pointer values, as in:

float Distance(Point p1, Point p2)
{
  if (p1 == p2) return 0.0; // won't work
  if (p1.x == p2.x && p1.y == p2.y) return 0.0; // will work
  ... // TBD by Pythagoras
}

We can debate whether or not this is sufficient for an RPC
infrastructure.

The .NET implementation is actually a little bit more complicated than
this because it also supports mapping the callstack above to a SOAP
message that looks like this:

<soap:Body>
  <ns:p1><x>10</x><y>20</y></ns:p1>
  <ns:p2><x>10</x><y>20</y></ns:p2>
</soap:Body>

In this case, there is not identifier for the operation and each child
of the body is treated as a parameter. In this case, the operation is
selected either by the SOAPAction or by the contents of the body (as
long as every operation has a single, uniquely named parameter). I
believe this is primarily in response to WSDL, they (and other SOAP
toolkit vendors) have created mappings for all of the different ways you
can describe operations in WSDL, whether they make a great deal of sense
or not.

Anyway, I still maintain my original position. I want a world where I
can define message formats using XSD. I want that because I've got a
whole bunch of XSD-aware tools, with more coming. If there is a going to
be a SOAP data model, an encoding and an RPC model, I would like it to
be simple enough that I can write an XSD for the encoded message format.
We've talked already about the desire to write contracts at the
graph-level without specifying an encoding, but I think this is a
mistake. I believe there are ultimately going to be a lot more systems
that care about tight integration with XSD than with the ability to send
a graph via n different encodings.

Tim-

Received on Thursday, 14 February 2002 15:19:11 UTC