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

RE: [soapbuilders] Re: Microsoft SOAP

Expand Messages
  • Andrew Layman
    Thanks for the question. Microsoft believes that interoperability is improved by having fewer, rather than more, protocols for achieving a function. This, of
    Message 1 of 6 , May 5 1:38 PM
    • 0 Attachment
      Thanks for the question.

      Microsoft believes that interoperability is improved by having fewer,
      rather than more, protocols for achieving a function. This, of course,
      requires that the protocols be general-purpose and widely-applicable,
      which is a design challenge, but when it can be achieved less is more.

      We could support multiple protocols for every function, but our
      experience, and I think also the experience of this forum with regard to
      SOAP encoding, is that fewer is better.

      Fewer protocols, broadly implemented, increase the likelihood that any
      two services will interoperate. A reduction in the number of protocols
      reduces the engineering expense, reduces the chances of errors and
      security problems and reduces the interactions and combinations that
      need to be tested.

      For that reason, we should settle either on SwA or on DIME. There are
      some significant technical advantages to DIME, particularly in the
      efficiency of buffer allocation by readers and in the context of
      transports other than HTTP. (These have been discussed in other
      threads.) Based on these technical advantages, DIME is preferable to
      SwA. And less is more.



      -----Original Message-----
      From: njudah [mailto:njudah@...]
      Sent: Friday, May 03, 2002 9:51 AM
      To: soapbuilders@yahoogroups.com
      Subject: [soapbuilders] Re: Microsoft SOAP

      Its a bit mystifying, isn't it? I don't understand what
      strategic
      benefit they'd gain from not supporting MIME, and clearly its a
      feature customers want. So why not support it? And why would they
      even join WS-I if they aren't interested in basic SwA interop?

      --- In soapbuilders@y..., Rich Salz <r.salz@v...> wrote:
      > > Last i heard there were no plans for the MSFT toolkits to
      include SwA
      > > support.
      >
      > Highly unfortunate. I hope MS toolkit customers pressure them to
      > continue on the interop trend, and not force us all to get on the
      DIME.
      > /r$



      -----------------------------------------------------------------
      This group is a forum for builders of SOAP implementations to discuss
      implementation and interoperability issues. Please stay on-topic.

      To unsubscribe from this group, send an email to:
      soapbuilders-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
    • Dick Brooks
      Andrew, ... Having lived through the interoperability woes of the SNA, DECnet, IPX, TCP/IP, Netbeui era, I believe the world is a better place today since
      Message 2 of 6 , May 5 3:58 PM
      • 0 Attachment
        Andrew,

        >Microsoft believes that interoperability is improved by having
        >fewer, rather than more, protocols for achieving a function.

        Having lived through the interoperability woes of the SNA, DECnet, IPX,
        TCP/IP, Netbeui era, I believe the world is a better place today since
        TCP/IP seems to have "risen above" the proprietary protocols. IMO, we are at
        the threshold or another era, the B2B protocol era and history seems to be
        repeating itself.

        The number of incompatible choices (SOAP, ebXML, BEEP, HTTPR, RFC2388, etc.)
        is already "excessive", IMO. Now we have another incompatible option added
        to the list, DIME.
        If Microsoft were serious about reducing the number of protocols they would
        choose to support one of the existing options, rather than introducing a
        new, proprietary option.

        >For that reason, we should settle either on SwA or on DIME. There
        >are some significant technical advantages to DIME, particularly in
        >the efficiency of buffer allocation by readers and in the context
        >of transports other than HTTP. (These have been discussed in
        >other threads.) Based on these technical advantages, DIME is
        >preferable to SwA. And less is more.

        How does the introduction of DIME improve interoperability if it "adds"
        rather than reduces the number of protocols. There are already "several"
        protocol options available, one of which was designed on top of SwA (ebXML's
        Message Service), with Microsoft's assistance. Does Microsoft believe that
        none of these other offerings meet the criteria for "general-purpose and
        widely-applicable"?

        Dick Brooks
        Systrends, Inc
        7855 South River Parkway, Suite 111
        Tempe, Arizona 85284
        Web: www.systrends.com <http://www.systrends.com>
        Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714



        -----Original Message-----
        From: njudah [mailto:njudah@...]
        Sent: Friday, May 03, 2002 9:51 AM
        To: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] Re: Microsoft SOAP

        Its a bit mystifying, isn't it? I don't understand what
        strategic
        benefit they'd gain from not supporting MIME, and clearly its a
        feature customers want. So why not support it? And why would they
        even join WS-I if they aren't interested in basic SwA interop?

        --- In soapbuilders@y..., Rich Salz <r.salz@v...> wrote:
        > > Last i heard there were no plans for the MSFT toolkits to
        include SwA
        > > support.
        >
        > Highly unfortunate. I hope MS toolkit customers pressure them to
        > continue on the interop trend, and not force us all to get on the
        DIME.
        > /r$



        -----------------------------------------------------------------
        This group is a forum for builders of SOAP implementations to discuss
        implementation and interoperability issues. Please stay on-topic.

        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/




        -----------------------------------------------------------------
        This group is a forum for builders of SOAP implementations to discuss
        implementation and interoperability issues. Please stay on-topic.

        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Rosimildo daSIlva
        ... And to make things worse, WSDL has 4 combinations for serialization: + rpc/encoded + rpc/literal + doc/literal + doc/encoded Rosimildo.
        Message 3 of 6 , May 5 4:56 PM
        • 0 Attachment
          --- Dick Brooks <dick@...> wrote:
          > Andrew,
          >
          > The number of incompatible choices (SOAP, ebXML,
          > BEEP, HTTPR, RFC2388, etc.)
          > is already "excessive", IMO. Now we have another
          > incompatible option added
          > to the list, DIME.


          And to make things worse, WSDL has 4 combinations
          for serialization:

          + rpc/encoded
          + rpc/literal
          + doc/literal
          + doc/encoded

          Rosimildo.



          __________________________________________________
          Do You Yahoo!?
          Yahoo! Health - your guide to health and wellness
          http://health.yahoo.com
        • Rich Salz
          DIME is kinda clever, but given the SwA at one end of the spectrum, and SOAP over BEEP at the other, it is a partial solution with not enough practical benefit
          Message 4 of 6 , May 6 9:05 AM
          • 0 Attachment
            DIME is kinda clever, but given the SwA at one end of the spectrum, and
            SOAP over BEEP at the other, it is a partial solution with not enough
            practical benefit to justify everyone else implementing it.

            Unless, of course, it is a test to see if everyone else can be forced to
            do so. :)

            If DIME fills a customer need, great. But to get interopability, please
            implement SwA.
            /r$
          Your message has been successfully submitted and would be delivered to recipients shortly.