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

Re: Microsoft SOAP

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.