Loading ...
Sorry, an error occurred while loading the content.

RE: [soapbuilders] MAY considered harmful

Expand Messages
  • noah_mendelsohn@us.ibm.com
    ... Well, if you were talking to someone who was involved many years ago when SOAP was (rumored to have been) a Microsoft proprietary COM-to-COM only system,
    Message 1 of 10 , May 29, 2002
    • 0 Attachment
      "Jorgen Thelin" writes:

      >> And let's not forget exactly why this is - rpc/encoded
      >> was "designed" for the scenario where both ends were
      >> the same type technology / toolkit - e.g. .NET to .NET,
      >> and was never intended for "interop" per se. This
      >> "intent" in the specifications was confirmed to me by
      >> someone who was involved in the SOAP / WSDL
      >> specification activities from a very early
      >> stage.

      Well, if you were talking to someone who was involved many years ago when
      SOAP was (rumored to have been) a Microsoft proprietary COM-to-COM only
      system, that might have been true. Essentially all of the publicly
      available and interesting SOAP versions starting with 0.9 (and probably
      earlier), have such cross-environment interop as a primary goal. Certainly
      when I was involved with development of Version 1.1, that kind of interop
      was the whole point.

      Now, what's subtle is this: SOAP is a wire format. The RPC & Encoding
      are designed to make it easy to make RPC calls and to service requests
      from commonly deployed programming languages. Primarily in that sense,
      interop is indeed a goal. What is not a goal at the level of the SOAP
      spec itself is to provide the actual mappings across multiple languages.
      If you have a programming language in which it makes more sense to list
      what I would call the "last" argument first, that's your business. If the
      Java community comes up with two different bindings to SOAP, that may be
      unfortunate, but SOAP doesn't prohibit it. They will interop insofar as
      each binding can clearly articulate which of its own method calls
      represent this or that SOAP message on the wire.

      So: the SOAP specification provides some hints on how you might map
      arguments in your programming language into SOAP, but the only thing that
      you can really see from outside is what's on the wire. To know how .Net
      will talk to Java, you have to choose a .Net binding, choose a Java
      binding, and where they map to the same SOAP messages: voila, interop.

      SOAP provides an important building block, but it does not attempt to
      define the details of the language bindings. As I've often said, nothing
      in SOAP RPC requires that you call a method at all: if you want to handle
      all your incoming SOAP RPCs by routing them through a big switch statement
      that has inline logic to generate the responses, nobody calling your
      service can see that. An unusual binding, perhaps, but perfectly legal.

      ------------------------------------------------------------------
      Noah Mendelsohn Voice: 1-617-693-4036
      IBM Corporation Fax: 1-617-693-8676
      One Rogers Street
      Cambridge, MA 02142
      ------------------------------------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.