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

Re: Microsoft SOAP

Expand Messages
  • Rich Salz
    ... 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$
    Message 1 of 6 , May 3, 2002
      > 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$
    • njudah
      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
      Message 2 of 6 , May 3, 2002
        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$
      • 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 3 of 6 , May 5, 2002
          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 4 of 6 , May 5, 2002
            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 5 of 6 , May 5, 2002
              --- 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 6 of 6 , May 6, 2002
                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.