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

SOAP Design pattern (sort of)

Expand Messages
  • Michele
    I have done some work with SOAP services dealing with complex types and I think I have a pattern. When one has to move beyond the add two numbers example,
    Message 1 of 29 , Jul 19, 2001
    • 0 Attachment
      I have done some work with SOAP services dealing with complex types
      and I think I have a pattern.
      When one has to move beyond the add two numbers example, there is a
      need to balance between creating a bunch of unrelated RPC calls
      (easy) and taking a more OO approach (harder). Ideally, I would like
      to create proxy objects with full processing capabilities that would
      shield the application from the notion that it is working remotely.
      Every time I have to deal with classes, say a SubscriptionManager
      (that manages Users, Services and so on), I find myself with

      1) server classes that basically have only methods (i.e. stateless
      or a bunch of RPC calls), that use complex types from the common
      library as parameters
      2) common classes that basically have only properties (that end in
      the types section of WSDL) and methods that call the SOAP services
      from a client perspective passing objects of the common library
      (adding their own ID so that the server knows wich object it has to
      treat).
      3) client classes that use common objects

      Do you think this is rightfully a pattern, or is it just that I did
      not tackle the problem from the right perspective?
      If there really is such a pattern, it would be nice to explain it
      well in order to save a lot of time to other fellows.
      If you think I have been too short (to save you one more whiote
      paper) please tell me, I will try to elaborate the idea a little
      more.
      One side effect is that there is always a JAR or DLL to distribute:
      the common classes.
    • Mike Deem
      In the purest form of this pattern, you are not passing objects of the common library , but simply passing XML content. There is no common library and no
      Message 2 of 29 , Jul 19, 2001
      • 0 Attachment
        In the purest form of this pattern, you are not "passing objects of the
        common library", but simply passing XML content. There is no "common
        library" and no need to distribute a JAR or DLL.

        For some reason, the tendency is to hide the XML behind an object or
        some other abstraction when it gets to the client or service. Why do we
        do this? Programming against the XML directly allows you to leverage an
        extremely powerful and flexible data model, and use all the tools that
        come with it (XSL, XPath, etc.).

        == Mike ==

        -----Original Message-----
        From: Michele [mailto:michelecos@...]
        Sent: Thursday, July 19, 2001 12:24 PM
        To: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] SOAP Design pattern (sort of)

        I have done some work with SOAP services dealing with complex types
        and I think I have a pattern.
        When one has to move beyond the add two numbers example, there is a
        need to balance between creating a bunch of unrelated RPC calls
        (easy) and taking a more OO approach (harder). Ideally, I would like
        to create proxy objects with full processing capabilities that would
        shield the application from the notion that it is working remotely.
        Every time I have to deal with classes, say a SubscriptionManager
        (that manages Users, Services and so on), I find myself with

        1) server classes that basically have only methods (i.e. stateless
        or a bunch of RPC calls), that use complex types from the common
        library as parameters
        2) common classes that basically have only properties (that end in
        the types section of WSDL) and methods that call the SOAP services
        from a client perspective passing objects of the common library
        (adding their own ID so that the server knows wich object it has to
        treat).
        3) client classes that use common objects

        Do you think this is rightfully a pattern, or is it just that I did
        not tackle the problem from the right perspective?
        If there really is such a pattern, it would be nice to explain it
        well in order to save a lot of time to other fellows.
        If you think I have been too short (to save you one more whiote
        paper) please tell me, I will try to elaborate the idea a little
        more.
        One side effect is that there is always a JAR or DLL to distribute:
        the common classes.




        -----------------------------------------------------------------
        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
        ... This is the common mapping of interface based languages such as WSDL & IDL to programming languages. Most SOAP mappers to programming langueages would
        Message 3 of 29 , Jul 19, 2001
        • 0 Attachment
          --- Michele <michelecos@...> wrote:
          > I have done some work with SOAP services dealing
          > with complex types
          > and I think I have a pattern.
          > When one has to move beyond the add two numbers
          > example, there is a
          > need to balance between creating a bunch of
          > unrelated RPC calls
          > (easy) and taking a more OO approach (harder).
          > Ideally, I would like
          > to create proxy objects with full processing
          > capabilities that would
          > shield the application from the notion that it is
          > working remotely.
          > Every time I have to deal with classes, say a
          > SubscriptionManager
          > (that manages Users, Services and so on), I find
          > myself with
          >
          > 1) server classes that basically have only methods
          > (i.e. stateless
          > or a bunch of RPC calls), that use complex types
          > from the common
          > library as parameters
          > 2) common classes that basically have only
          > properties (that end in
          > the types section of WSDL) and methods that call the
          > SOAP services
          > from a client perspective passing objects of the
          > common library
          > (adding their own ID so that the server knows wich
          > object it has to
          > treat).
          > 3) client classes that use common objects
          >

          This is the common mapping of "interface based"
          languages such as WSDL & IDL to programming
          languages. Most SOAP mappers to programming
          langueages would generate such a code automatically.
          If you are writing this code by hand, you are
          wasting too much time. :-)

          This is usually called:

          + Client: proxy stubs ( (3) + (2) )
          + Data Holders ( (2) -- mapping from Custom types )
          + Server: impl skeletons ( (1) + (2) )


          Yes, on RPC oriented systems, SOAP RPC, XML_RPC,
          CORBA, RPC, DCOM, COM+, almost every system
          falls in this category, and code generators are
          usually provided with the stack that you use. Things
          get more interesting when Async notifications are
          required, but that is not as common as the pattern
          that you described.

          Rosimildo.




          __________________________________________________
          Do You Yahoo!?
          Get personalized email addresses from Yahoo! Mail
          http://personal.mail.yahoo.com/
        • Pete Hendry
          ... That is only if, as you suggest next, the client is accessing the XML directly. There are a lot of people out there that do not want to do this. XML,
          Message 4 of 29 , Jul 20, 2001
          • 0 Attachment
            >
            > In the purest form of this pattern, you are not "passing objects of the
            > common library", but simply passing XML content. There is no "common
            > library" and no need to distribute a JAR or DLL.
            >

            That is only if, as you suggest next, the client is accessing the XML directly. There are a lot of people out there that
            do not want to do this. XML, although simple in concept, has a lot of complexity and some people are only using it as a
            transport. They don't want to deal with it at an application level where they are used to a nice and simple object
            model.

            > For some reason, the tendency is to hide the XML behind an object or
            > some other abstraction when it gets to the client or service. Why do we
            > do this? Programming against the XML directly allows you to leverage an
            > extremely powerful and flexible data model, and use all the tools that
            > come with it (XSL, XPath, etc.).
            >

            As I said, in a lot of cases Xml is the transport. For example, many people already have applications running in a
            server totally unaware of XML. If you want to write a client to talk to them over SOAP you don't necessarily want to
            know the intracacies of SOAP to achieve this. You want someone to provide you with the necessary client classes to talk
            to some middleware that then talks to your server based application. No knowledge of XML or SOAP is required in the
            client or server.

            Programming to XML is indeed powerful. Access to the XML used can be useful as you say for XSL, XPath, etc. This is a
            different type of developer who wants access to the transport information to transform it.

            I would prefer to program to interfaces with objects than access XML directly unless I absolutely had to modify the XML
            being passed.

            One place where accessing XML directly falls short is when one generated stub supports multiple transports/encodings.
            This can all be taken care of for you with pluggable transports/encoders. Accessing XML directly means having to deal
            with writing the different encodings yourself.

            Both approaches have merits for different developers.

            Pete.
          • Michele
            ... I really wish that *most* SOAP mappers did the job. Truth is that most of the ones I tried fail, specially when dealing with WSDL encoded by Microsoft
            Message 5 of 29 , Jul 20, 2001
            • 0 Attachment
              > This is the common mapping of "interface based"
              > languages such as WSDL & IDL to programming
              > languages. Most SOAP mappers to programming
              > langueages would generate such a code automatically.

              I really wish that *most* SOAP mappers did the job. Truth is that
              most of the ones I tried fail, specially when dealing with WSDL
              encoded by Microsoft tools (try for example the AddrBook sample).
              The main reason why I specified SOAP for our project is
              interoperability between Java and Windows machines (in all
              combinations of clients and servers :-\ ). I have been accused of
              being too easy to embrace unstable technology (but I still stand
              behind my choice).
            • Rosimildo da Silva
              From: Michele To: soapbuilders@yahoogroups.com Sent: Friday, July 20, 2001 7:59 AM Subject: [soapbuilders] Re: SOAP Design pattern (sort of)This is the
              Message 6 of 29 , Jul 20, 2001
              • 0 Attachment
                From: Michele
                To: soapbuilders@yahoogroups.com
                Sent: Friday, July 20, 2001 7:59 AM
                Subject: [soapbuilders] Re: SOAP Design pattern (sort of)


                > This is the common mapping of "interface based"
                > languages such as WSDL & IDL to programming
                > languages. Most SOAP mappers to programming
                > langueages would generate such a code automatically.

                I really wish that *most* SOAP mappers did the job. Truth is that
                most of the ones I tried fail, specially when dealing with WSDL
                encoded by Microsoft tools (try for example the AddrBook sample).
                The main reason why I specified SOAP for our project is
                interoperability between Java and Windows machines (in all
                combinations of clients and servers :-\ ). I have been accused of
                being too easy to embrace unstable technology (but I still stand
                behind my choice).


                Sorry, if I offend you in anyway. It was not my intention...

                SOAP/WSDL is a new technology, and people are trying to put things
                together. Limited implementations, bugs, etc should be *expected*
                by early adopters of any technology. :-)

                The point that I've tried to make is that code generation from a
                WSDL document ( interface of the web service ), it is going to
                be the norm in a few years, maybe sooner.

                Rosimildo.


                Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


                _________________________________________________________
                Do You Yahoo!?
                Get your free @... address at http://mail.yahoo.com
              • Mike Deem
                Michele, I m not sure I understand you issue with the SOAP Toolkit s AddrBook sample. Is the problem simply that you have to write the mapping code yourself?
                Message 7 of 29 , Jul 20, 2001
                • 0 Attachment
                  Michele, I'm not sure I understand you issue with the SOAP Toolkit's
                  AddrBook sample. Is the problem simply that you have to write the
                  mapping code yourself? Granted that is inconvenient and we are working
                  on improvements in that area. Or is there a more serious
                  interoperability problem with the sample type mapper?

                  Thanks,

                  == Mike ==

                  -----Original Message-----
                  From: Michele [mailto:michelecos@...]
                  Sent: Friday, July 20, 2001 5:59 AM
                  To: soapbuilders@yahoogroups.com
                  Subject: [soapbuilders] Re: SOAP Design pattern (sort of)

                  > This is the common mapping of "interface based"
                  > languages such as WSDL & IDL to programming
                  > languages. Most SOAP mappers to programming
                  > langueages would generate such a code automatically.

                  I really wish that *most* SOAP mappers did the job. Truth is that
                  most of the ones I tried fail, specially when dealing with WSDL
                  encoded by Microsoft tools (try for example the AddrBook sample).
                  The main reason why I specified SOAP for our project is
                  interoperability between Java and Windows machines (in all
                  combinations of clients and servers :-\ ). I have been accused of
                  being too easy to embrace unstable technology (but I still stand
                  behind my choice).




                  -----------------------------------------------------------------
                  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/
                • Mike Deem
                  ... the ... where ... [Mike Deem] This is the central point to my question. WHY do people prefer a nice simple object model , and the RPC programming model to
                  Message 8 of 29 , Jul 20, 2001
                  • 0 Attachment
                    > From: Pete Hendry [mailto:peter.hendry@...]
                    >
                    > >
                    > > In the purest form of this pattern, you are not "passing objects of
                    the
                    > > common library", but simply passing XML content. There is no "common
                    > > library" and no need to distribute a JAR or DLL.
                    > >
                    >
                    > That is only if, as you suggest next, the client is accessing the XML
                    > directly. There are a lot of people out there that
                    > do not want to do this. XML, although simple in concept, has a lot of
                    > complexity and some people are only using it as a
                    > transport. They don't want to deal with it at an application level
                    where
                    > they are used to a nice and simple object
                    > model.
                    >

                    [Mike Deem]
                    This is the central point to my question. WHY do people prefer a "nice
                    simple object model", and the RPC programming model to go with it, AT
                    THE NETWORK LEVEL? Is hiding the fact that they are talking over the
                    network really doing the programmer a service?

                    When I say "hiding the fact that they are talking over the network", I
                    don't mean making them write code to the socket API. The details of HOW
                    their messages get sent and received SHOULD be hidden. However, should
                    the fact that they are sending messages over the network be abstracted
                    away? In the long run, does that offer any advantage?

                    > > For some reason, the tendency is to hide the XML behind an object or
                    > > some other abstraction when it gets to the client or service. Why do
                    we
                    > > do this? Programming against the XML directly allows you to leverage
                    an
                    > > extremely powerful and flexible data model, and use all the tools
                    that
                    > > come with it (XSL, XPath, etc.).
                    > >
                    >
                    > As I said, in a lot of cases Xml is the transport. For example, many
                    > people already have applications running in a
                    > server totally unaware of XML. If you want to write a client to talk
                    to
                    > them over SOAP you don't necessarily want to
                    > know the intracacies of SOAP to achieve this.

                    [Mike Deem]
                    Exposing some message content as XML does not necessarily mean that you
                    are exposing the intricacies of SOAP itself. Many SOAP frameworks allow
                    a given parameter to be passed as XML, where and how that parameter's
                    value appears in the message is hidden from the user. Even in a non-RPC
                    programming model, you can have abstract message objects that hide the
                    protocol level details.

                    > You want someone to provide
                    > you with the necessary client classes to talk
                    > to some middleware that then talks to your server based application.
                    No
                    > knowledge of XML or SOAP is required in the
                    > client or server.

                    [Mike Deem]
                    Again, I think it is important to make a clear distinction between
                    knowledge of SOAP and knowledge of XML. The knowledge necessary to write
                    XML processing code is quickly becoming very common.

                    > Programming to XML is indeed powerful. Access to the XML used can be
                    > useful as you say for XSL, XPath, etc. This is a
                    > different type of developer who wants access to the transport
                    information
                    > to transform it.

                    [Mike Deem]
                    True, it is a different type of developer. More likely it is the one
                    that really understands what it means to build a maintainable and
                    evolvable distributed system. At the network level, programming against
                    the XML directly offers many options for evolving and extending a
                    system's design in a decentralized, uncoordinated manner.

                    > I would prefer to program to interfaces with objects than access XML
                    > directly unless I absolutely had to modify the XML
                    > being passed.
                    >
                    > One place where accessing XML directly falls short is when one
                    generated
                    > stub supports multiple transports/encodings.
                    > This can all be taken care of for you with pluggable
                    transports/encoders.
                    > Accessing XML directly means having to deal
                    > with writing the different encodings yourself.

                    [Mike Deem]
                    I agree with this. Reading and writing section 5 XML directly is
                    difficult and should be avoided. SOAP encoding exists to allow complex
                    graph like data structures to be serialized as XML. However, for almost
                    all "real life" web services, such data structures simply do not need to
                    be exchanged. Why use section 5 encoding in such cases? It adds
                    unnecessary complexity and overhead.

                    > Both approaches have merits for different developers.
                    >
                    > Pete.

                    == Mike ==
                  • Jacek Kopecky
                    Hi Mike and all others. 8-) Sorry for replying with a week of a delay. Please see my response below. I stripped away most of the text in places where it
                    Message 9 of 29 , Jul 26, 2001
                    • 0 Attachment
                      Hi Mike and all others. 8-)
                      Sorry for replying with a week of a delay.
                      Please see my response below. I stripped away most of the text
                      in places where it doesn't (IMHO) hurt.

                      Jacek Kopecky

                      Idoox
                      http://www.idoox.com/




                      > > Programming to XML is indeed powerful. Access to the XML used can be
                      > > useful as you say for XSL, XPath, etc. This is a
                      > > different type of developer who wants access to the transport
                      > information
                      > > to transform it.
                      >
                      > [Mike Deem]
                      > True, it is a different type of developer. More likely it is the one
                      > that really understands what it means to build a maintainable and
                      > evolvable distributed system. At the network level, programming against
                      > the XML directly offers many options for evolving and extending a
                      > system's design in a decentralized, uncoordinated manner.

                      I think that the mapping of soap structures into language classes
                      is very useful from a higher perspective - what if you don't
                      necessarily want to use XML in the future? Your choices would be
                      to a) rewrite the code or b) apply a transformation on the
                      resulting XML.
                      On the other hand if you used an object system for the data, you
                      would just have to replace the (de)serialization code.

                      > > I would prefer to program to interfaces with objects than access XML
                      > > directly unless I absolutely had to modify the XML
                      > > being passed.
                      > >
                      > > One place where accessing XML directly falls short is when one
                      > generated
                      > > stub supports multiple transports/encodings.
                      > > This can all be taken care of for you with pluggable
                      > transports/encoders.
                      > > Accessing XML directly means having to deal
                      > > with writing the different encodings yourself.
                      >
                      > [Mike Deem]
                      > I agree with this. Reading and writing section 5 XML directly is
                      > difficult and should be avoided. SOAP encoding exists to allow complex
                      > graph like data structures to be serialized as XML. However, for almost
                      > all "real life" web services, such data structures simply do not need to
                      > be exchanged. Why use section 5 encoding in such cases? It adds
                      > unnecessary complexity and overhead.

                      I thought section 5 encoding was added to create a _common_ way
                      of representing data structures. This is very important for
                      example to RPC where you can say "whatever the parameter's type,
                      encode it using your encoding of choice (preferably a common one,
                      like SOAP section 5)."

                      I can easily encode "complex graph like data structures" into XML
                      without using SOAP section 5, and in most cases the encoding
                      would be even nicer.

                      Jacek
                    • Simon Fell
                      For me this is the crux of the issue, this is a big concern I have with the push that is being made to move to XSD literal style from section 5, AFAICS you
                      Message 10 of 29 , Jul 26, 2001
                      • 0 Attachment
                        For me this is the crux of the issue, this is a big concern I have with the
                        push that is being made to move to XSD literal style from section 5, AFAICS
                        you loose a lot of the XML <-> Native types benefits, I for one don't want
                        to write code to de-serialize what 50 other people think an array should
                        look like.

                        Cheers
                        Simon

                        -----Original Message-----
                        From: Jacek Kopecky [mailto:jacek@...]

                        I thought section 5 encoding was added to create a _common_ way
                        of representing data structures. This is very important for
                        example to RPC where you can say "whatever the parameter's type,
                        encode it using your encoding of choice (preferably a common one,
                        like SOAP section 5)."

                        I can easily encode "complex graph like data structures" into XML
                        without using SOAP section 5, and in most cases the encoding
                        would be even nicer.

                        Jacek
                      • Rosimildo daSIlva
                        ... And changing subject bit, this morning I passed a nil to the inputStruct in the echoStruct method ( Round 2 ) by accident, and the sky fall over my
                        Message 11 of 29 , Jul 26, 2001
                        • 0 Attachment
                          --- Simon Fell <sfell@...> wrote:
                          > For me this is the crux of the issue, this is a big
                          > concern I have with the
                          > push that is being made to move to XSD literal style
                          > from section 5, AFAICS
                          > you loose a lot of the XML <-> Native types
                          > benefits, I for one don't want
                          > to write code to de-serialize what 50 other people
                          > think an array should
                          > look like.
                          >

                          And changing subject bit,

                          this morning I passed a "nil" to the "inputStruct"
                          in the echoStruct method ( Round 2 ) by accident,
                          and the sky fall over my head. :-)

                          I think only one toolkit passed ( SQL Data ).

                          Rosimildo.










                          __________________________________________________
                          Do You Yahoo!?
                          Make international calls for as low as $.04/minute with Yahoo! Messenger
                          http://phonecard.yahoo.com/
                        • Mike Deem
                          All serialization can do is translate between XML and simple data types like structures and arrays. An application is, most likely, built of objects that have
                          Message 12 of 29 , Jul 26, 2001
                          • 0 Attachment
                            All serialization can do is translate between XML and simple data types
                            like structures and arrays. An application is, most likely, built of
                            objects that have behavior (like business rules). There is always hand
                            built code that sits between the data model of the message (XML or
                            RPC/struct/array) and the application's object model.

                            Why accept the overhead, bugs, interoperability issues, and complexity a
                            layer that *only* translates from the XML data model to/from the
                            RPC/struct/array data model? The XML data model is richer and easy
                            enough to program to.

                            == Mike ==


                            -----Original Message-----
                            From: Simon Fell [mailto:sfell@...]
                            Sent: Thursday, July 26, 2001 12:17 PM
                            To: 'soapbuilders@yahoogroups.com'
                            Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                            For me this is the crux of the issue, this is a big concern I have with
                            the
                            push that is being made to move to XSD literal style from section 5,
                            AFAICS
                            you loose a lot of the XML <-> Native types benefits, I for one don't
                            want
                            to write code to de-serialize what 50 other people think an array should
                            look like.

                            Cheers
                            Simon

                            -----Original Message-----
                            From: Jacek Kopecky [mailto:jacek@...]

                            I thought section 5 encoding was added to create a _common_ way
                            of representing data structures. This is very important for
                            example to RPC where you can say "whatever the parameter's type,
                            encode it using your encoding of choice (preferably a common one,
                            like SOAP section 5)."

                            I can easily encode "complex graph like data structures" into XML
                            without using SOAP section 5, and in most cases the encoding
                            would be even nicer.

                            Jacek


                            -----------------------------------------------------------------
                            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/
                          • Simon Fell
                            I don t see how those problems magically go away, just because you have a bunch of XSD schemas. Cheers Simon ... From: Mike Deem
                            Message 13 of 29 , Jul 26, 2001
                            • 0 Attachment
                              I don't see how those problems magically go away, just because you have a
                              bunch of XSD schemas.

                              Cheers
                              Simon

                              -----Original Message-----
                              From: Mike Deem [mailto:mikedeem@...]
                              Sent: Thursday, July 26, 2001 6:05 PM
                              To: soapbuilders@yahoogroups.com
                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                              All serialization can do is translate between XML and simple data types
                              like structures and arrays. An application is, most likely, built of
                              objects that have behavior (like business rules). There is always hand
                              built code that sits between the data model of the message (XML or
                              RPC/struct/array) and the application's object model.

                              Why accept the overhead, bugs, interoperability issues, and complexity a
                              layer that *only* translates from the XML data model to/from the
                              RPC/struct/array data model? The XML data model is richer and easy
                              enough to program to.

                              == Mike ==


                              -----Original Message-----
                              From: Simon Fell [mailto:sfell@...]
                              Sent: Thursday, July 26, 2001 12:17 PM
                              To: 'soapbuilders@yahoogroups.com'
                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                              For me this is the crux of the issue, this is a big concern I have with
                              the
                              push that is being made to move to XSD literal style from section 5,
                              AFAICS
                              you loose a lot of the XML <-> Native types benefits, I for one don't
                              want
                              to write code to de-serialize what 50 other people think an array should
                              look like.

                              Cheers
                              Simon

                              -----Original Message-----
                              From: Jacek Kopecky [mailto:jacek@...]

                              I thought section 5 encoding was added to create a _common_ way
                              of representing data structures. This is very important for
                              example to RPC where you can say "whatever the parameter's type,
                              encode it using your encoding of choice (preferably a common one,
                              like SOAP section 5)."

                              I can easily encode "complex graph like data structures" into XML
                              without using SOAP section 5, and in most cases the encoding
                              would be even nicer.

                              Jacek


                              -----------------------------------------------------------------
                              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 da Silva
                              From: Simon Fell To: soapbuilders@yahoogroups.com Sent: Thursday, July 26, 2001 8:17 PM Subject: RE: [soapbuilders] SOAP Design pattern (sort of)I don t
                              Message 14 of 29 , Jul 26, 2001
                              • 0 Attachment
                                From: Simon Fell
                                To: 'soapbuilders@yahoogroups.com'
                                Sent: Thursday, July 26, 2001 8:17 PM
                                Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                >I don't see how those problems magically go away, just because you have a
                                >bunch of XSD schemas.

                                If XML Schemas are good enough, why do we need SOAP/WSDL/UDDI ?

                                Why not use XML Schemas to change information, as it is ?

                                It is becuase XML is pretty *loose* from a programming standpoint.
                                It is a pretty decent way of structuring data, but, adding behavior in
                                an organized way of accessing this data, is necessary. And finally,
                                all systems as exists today are written using conventional languages,
                                C++, Java, Perl, SmallTalk, VB, etc. So, no matter what, interface
                                or mapping for these languages are extremely important to get these
                                applications using XML.

                                Unless someone thinks that everything canbe done using a XSLT processor. :-)

                                Rosimildo.






                                _________________________________________________________
                                Do You Yahoo!?
                                Get your free @... address at http://mail.yahoo.com
                              • Mike Deem
                                My premise is that generic serialization code can t directly translate between XML and the rich object model that exists inside of an application. The best it
                                Message 15 of 29 , Jul 26, 2001
                                • 0 Attachment
                                  My premise is that generic serialization code can't directly translate
                                  between XML and the rich object model that exists inside of an
                                  application. The best it can do is create "dumb" structs and arrays.

                                  Also, many services will be exposed though multiple ports to address the
                                  needs of different kinds of clients. The data exposed by any one port
                                  will represent different views of the data maintained internally by the
                                  application. In other words, the structures put on the wire will NOT be
                                  equivalent to the structures used internally by the application.

                                  So, no matter what, you have to write code that translates between what
                                  you get from the network and the application's internal objects. This
                                  code either pulls data out of structs/arrays and calls methods, or it
                                  pulls data out of XML and calls methods. Either way, I assert that
                                  roughly the same amount of effort goes into that code. In other words,
                                  using structs/arrays here offers no significant advantage.

                                  However, if you let a tool/framework translate the XML into
                                  structs/arrays, you introduce the overhead of that translation and the
                                  opportunity for tool/framework to screw up, and gain no advantage in
                                  return.

                                  Furthermore, I believe that there are advantages to using the XML data
                                  model in this network/application translation layer. You get to leverage
                                  things like XPath and XSLT, and it makes evolving a system easier (just
                                  add code to look for a new element instead of creating a new method or
                                  struct with an additional new parameter).

                                  == Mike ==

                                  -----Original Message-----
                                  From: Simon Fell [mailto:sfell@...]
                                  Sent: Thursday, July 26, 2001 6:17 PM
                                  To: 'soapbuilders@yahoogroups.com'
                                  Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                  I don't see how those problems magically go away, just because you have
                                  a
                                  bunch of XSD schemas.

                                  Cheers
                                  Simon

                                  -----Original Message-----
                                  From: Mike Deem [mailto:mikedeem@...]
                                  Sent: Thursday, July 26, 2001 6:05 PM
                                  To: soapbuilders@yahoogroups.com
                                  Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                  All serialization can do is translate between XML and simple data types
                                  like structures and arrays. An application is, most likely, built of
                                  objects that have behavior (like business rules). There is always hand
                                  built code that sits between the data model of the message (XML or
                                  RPC/struct/array) and the application's object model.

                                  Why accept the overhead, bugs, interoperability issues, and complexity a
                                  layer that *only* translates from the XML data model to/from the
                                  RPC/struct/array data model? The XML data model is richer and easy
                                  enough to program to.

                                  == Mike ==


                                  -----Original Message-----
                                  From: Simon Fell [mailto:sfell@...]
                                  Sent: Thursday, July 26, 2001 12:17 PM
                                  To: 'soapbuilders@yahoogroups.com'
                                  Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                  For me this is the crux of the issue, this is a big concern I have with
                                  the
                                  push that is being made to move to XSD literal style from section 5,
                                  AFAICS
                                  you loose a lot of the XML <-> Native types benefits, I for one don't
                                  want
                                  to write code to de-serialize what 50 other people think an array should
                                  look like.

                                  Cheers
                                  Simon

                                  -----Original Message-----
                                  From: Jacek Kopecky [mailto:jacek@...]

                                  I thought section 5 encoding was added to create a _common_ way
                                  of representing data structures. This is very important for
                                  example to RPC where you can say "whatever the parameter's type,
                                  encode it using your encoding of choice (preferably a common one,
                                  like SOAP section 5)."

                                  I can easily encode "complex graph like data structures" into XML
                                  without using SOAP section 5, and in most cases the encoding
                                  would be even nicer.

                                  Jacek


                                  -----------------------------------------------------------------
                                  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/



                                  -----------------------------------------------------------------
                                  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/
                                • Stefan Havenstein
                                  Hi, ... Type safety? I don t really get the point here - does Mike say that it s better to program against the, say, DOM, and manipulate strings, than to get
                                  Message 16 of 29 , Jul 26, 2001
                                  • 0 Attachment
                                    Hi,

                                    >
                                    > Why accept the overhead, bugs, interoperability issues, and complexity a
                                    > layer that *only* translates from the XML data model to/from the
                                    > RPC/struct/array data model? The XML data model is richer and easy
                                    > enough to program to.
                                    >
                                    Type safety?

                                    I don't really get the point here - does Mike say that it's better to
                                    program against the, say, DOM, and manipulate strings, than to get at
                                    least some dumb but type safe representations of the data? And why
                                    should the latter be error-prone? If it's a well-tested tool, it's
                                    much less error-prone than to play around on the DOM level.

                                    > I don't see how those problems magically go away, just because you have
                                    > a bunch of XSD schemas.
                                    I think that Schemas, together with an appropriate language binding,
                                    give you big productivity benefits, as the programming language constructs
                                    generated from that are 'first class' objects from the point of view of
                                    your application logic, i.e. you don't need further translation steps
                                    before being able to deal with their data. Also, you can utilize annotations
                                    to drive the generation process and generate parts of your application
                                    logic already.

                                    Cheers,


                                    Stefan

                                    Stefan Havenstein
                                    http://www.shinkatech.com



                                    > -----Ursprungliche Nachricht-----
                                    > Von:
                                    > sentto-2731744-4616-996200304-Stefan.Havenstein=shinkatech.com@returns.o
                                    > nelist.com
                                    > [mailto:sentto-2731744-4616-996200304-Stefan.Havenstein=shinkatech.com@r
                                    > eturns.onelist.com]Im Auftrag von Mike Deem
                                    > Gesendet: Freitag, 27. Juli 2001 04:18
                                    > An: soapbuilders@yahoogroups.com
                                    > Betreff: RE: [soapbuilders] SOAP Design pattern (sort of)
                                    >
                                    >
                                    > My premise is that generic serialization code can't directly translate
                                    > between XML and the rich object model that exists inside of an
                                    > application. The best it can do is create "dumb" structs and arrays.
                                    >
                                    > Also, many services will be exposed though multiple ports to address the
                                    > needs of different kinds of clients. The data exposed by any one port
                                    > will represent different views of the data maintained internally by the
                                    > application. In other words, the structures put on the wire will NOT be
                                    > equivalent to the structures used internally by the application.
                                    >
                                    > So, no matter what, you have to write code that translates between what
                                    > you get from the network and the application's internal objects. This
                                    > code either pulls data out of structs/arrays and calls methods, or it
                                    > pulls data out of XML and calls methods. Either way, I assert that
                                    > roughly the same amount of effort goes into that code. In other words,
                                    > using structs/arrays here offers no significant advantage.
                                    >
                                    > However, if you let a tool/framework translate the XML into
                                    > structs/arrays, you introduce the overhead of that translation and the
                                    > opportunity for tool/framework to screw up, and gain no advantage in
                                    > return.
                                    >
                                    > Furthermore, I believe that there are advantages to using the XML data
                                    > model in this network/application translation layer. You get to leverage
                                    > things like XPath and XSLT, and it makes evolving a system easier (just
                                    > add code to look for a new element instead of creating a new method or
                                    > struct with an additional new parameter).
                                    >
                                    > == Mike ==
                                    >
                                    > -----Original Message-----
                                    > From: Simon Fell [mailto:sfell@...]
                                    > Sent: Thursday, July 26, 2001 6:17 PM
                                    > To: 'soapbuilders@yahoogroups.com'
                                    > Subject: RE: [soapbuilders] SOAP Design pattern (sort of)
                                    >
                                    > I don't see how those problems magically go away, just because you have
                                    > a
                                    > bunch of XSD schemas.
                                    >
                                    > Cheers
                                    > Simon
                                    >
                                    > -----Original Message-----
                                    > From: Mike Deem [mailto:mikedeem@...]
                                    > Sent: Thursday, July 26, 2001 6:05 PM
                                    > To: soapbuilders@yahoogroups.com
                                    > Subject: RE: [soapbuilders] SOAP Design pattern (sort of)
                                    >
                                    >
                                    > All serialization can do is translate between XML and simple data types
                                    > like structures and arrays. An application is, most likely, built of
                                    > objects that have behavior (like business rules). There is always hand
                                    > built code that sits between the data model of the message (XML or
                                    > RPC/struct/array) and the application's object model.
                                    >
                                    > Why accept the overhead, bugs, interoperability issues, and complexity a
                                    > layer that *only* translates from the XML data model to/from the
                                    > RPC/struct/array data model? The XML data model is richer and easy
                                    > enough to program to.
                                    >
                                    > == Mike ==
                                    >
                                    >
                                    > -----Original Message-----
                                    > From: Simon Fell [mailto:sfell@...]
                                    > Sent: Thursday, July 26, 2001 12:17 PM
                                    > To: 'soapbuilders@yahoogroups.com'
                                    > Subject: RE: [soapbuilders] SOAP Design pattern (sort of)
                                    >
                                    > For me this is the crux of the issue, this is a big concern I have with
                                    > the
                                    > push that is being made to move to XSD literal style from section 5,
                                    > AFAICS
                                    > you loose a lot of the XML <-> Native types benefits, I for one don't
                                    > want
                                    > to write code to de-serialize what 50 other people think an array should
                                    > look like.
                                    >
                                    > Cheers
                                    > Simon
                                    >
                                    > -----Original Message-----
                                    > From: Jacek Kopecky [mailto:jacek@...]
                                    >
                                    > I thought section 5 encoding was added to create a _common_ way
                                    > of representing data structures. This is very important for
                                    > example to RPC where you can say "whatever the parameter's type,
                                    > encode it using your encoding of choice (preferably a common one,
                                    > like SOAP section 5)."
                                    >
                                    > I can easily encode "complex graph like data structures" into XML
                                    > without using SOAP section 5, and in most cases the encoding
                                    > would be even nicer.
                                    >
                                    > Jacek
                                    >
                                    >
                                    > -----------------------------------------------------------------
                                    > 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/
                                    >
                                    >
                                    >
                                    > -----------------------------------------------------------------
                                    > 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/
                                    >
                                    >
                                  • graham glass
                                    hi mike, i can only speak from my own perspective, but GLUE can already map bidirectionally between XML to java objects without being limited to dumb structs
                                    Message 17 of 29 , Jul 27, 2001
                                    • 0 Attachment
                                      hi mike,

                                      i can only speak from my own perspective, but GLUE can already
                                      map bidirectionally between XML to java objects without being limited
                                      to "dumb" structs and arrays. this is done by generic serialization
                                      logic and does not involve the creation of any custom mapping
                                      code. in addition, developers can control the mapping beyond the
                                      standard rules by editing an "annotated schema" which gives runtime
                                      hints to GLUE on how to perform the java/xml mapping. this makes life
                                      much easier for java developers, as they can write to their own natural
                                      APIs without being exposed directly to XML. of course, there is room
                                      for bugs in the GLUE mapping code, but they are generally easy to fix.

                                      there are of course cases where you want to send and receive
                                      XML directly, but in many cases this is not necessary.

                                      cheers,
                                      graham

                                      -----Original Message-----
                                      From: Mike Deem [mailto:mikedeem@...]
                                      Sent: Thursday, July 26, 2001 9:18 PM
                                      To: soapbuilders@yahoogroups.com
                                      Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                      My premise is that generic serialization code can't directly translate
                                      between XML and the rich object model that exists inside of an
                                      application. The best it can do is create "dumb" structs and arrays.

                                      Also, many services will be exposed though multiple ports to address the
                                      needs of different kinds of clients. The data exposed by any one port
                                      will represent different views of the data maintained internally by the
                                      application. In other words, the structures put on the wire will NOT be
                                      equivalent to the structures used internally by the application.

                                      So, no matter what, you have to write code that translates between what
                                      you get from the network and the application's internal objects. This
                                      code either pulls data out of structs/arrays and calls methods, or it
                                      pulls data out of XML and calls methods. Either way, I assert that
                                      roughly the same amount of effort goes into that code. In other words,
                                      using structs/arrays here offers no significant advantage.

                                      However, if you let a tool/framework translate the XML into
                                      structs/arrays, you introduce the overhead of that translation and the
                                      opportunity for tool/framework to screw up, and gain no advantage in
                                      return.

                                      Furthermore, I believe that there are advantages to using the XML data
                                      model in this network/application translation layer. You get to leverage
                                      things like XPath and XSLT, and it makes evolving a system easier (just
                                      add code to look for a new element instead of creating a new method or
                                      struct with an additional new parameter).

                                      == Mike ==

                                      -----Original Message-----
                                      From: Simon Fell [mailto:sfell@...]
                                      Sent: Thursday, July 26, 2001 6:17 PM
                                      To: 'soapbuilders@yahoogroups.com'
                                      Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                      I don't see how those problems magically go away, just because you have
                                      a
                                      bunch of XSD schemas.

                                      Cheers
                                      Simon

                                      -----Original Message-----
                                      From: Mike Deem [mailto:mikedeem@...]
                                      Sent: Thursday, July 26, 2001 6:05 PM
                                      To: soapbuilders@yahoogroups.com
                                      Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                      All serialization can do is translate between XML and simple data types
                                      like structures and arrays. An application is, most likely, built of
                                      objects that have behavior (like business rules). There is always hand
                                      built code that sits between the data model of the message (XML or
                                      RPC/struct/array) and the application's object model.

                                      Why accept the overhead, bugs, interoperability issues, and complexity a
                                      layer that *only* translates from the XML data model to/from the
                                      RPC/struct/array data model? The XML data model is richer and easy
                                      enough to program to.

                                      == Mike ==


                                      -----Original Message-----
                                      From: Simon Fell [mailto:sfell@...]
                                      Sent: Thursday, July 26, 2001 12:17 PM
                                      To: 'soapbuilders@yahoogroups.com'
                                      Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                      For me this is the crux of the issue, this is a big concern I have with
                                      the
                                      push that is being made to move to XSD literal style from section 5,
                                      AFAICS
                                      you loose a lot of the XML <-> Native types benefits, I for one don't
                                      want
                                      to write code to de-serialize what 50 other people think an array should
                                      look like.

                                      Cheers
                                      Simon

                                      -----Original Message-----
                                      From: Jacek Kopecky [mailto:jacek@...]

                                      I thought section 5 encoding was added to create a _common_ way
                                      of representing data structures. This is very important for
                                      example to RPC where you can say "whatever the parameter's type,
                                      encode it using your encoding of choice (preferably a common one,
                                      like SOAP section 5)."

                                      I can easily encode "complex graph like data structures" into XML
                                      without using SOAP section 5, and in most cases the encoding
                                      would be even nicer.

                                      Jacek


                                      -----------------------------------------------------------------
                                      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/



                                      -----------------------------------------------------------------
                                      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/
                                    • Stefan Haustein
                                      ... The XML data model describes trees. SOAP provides rules for encoding graphs. Since trees are specialized graphs, the Sec5 data model is richer than plain
                                      Message 18 of 29 , Jul 27, 2001
                                      • 0 Attachment
                                        Mike Deem wrote:
                                        >
                                        > Why accept the overhead, bugs, interoperability issues, and complexity a
                                        > layer that *only* translates from the XML data model to/from the
                                        > RPC/struct/array data model? The XML data model is richer and easy
                                        > enough to program to.

                                        The XML data model describes trees. SOAP provides
                                        rules for encoding graphs. Since trees are specialized
                                        graphs, the Sec5 data model is richer than plain XML.

                                        Sec5 just fits better to the arrows-and-boxes UML
                                        models programmers are used to. XML Schema cannot
                                        compete with UML.

                                        Best,
                                        Stefan

                                        --
                                        Stefan Haustein
                                        Univ. Dortmund, FB 4, LS 8 tel: +49 231 755 2499
                                        Baroper Str. 301 fax: +49 231 755 5105
                                        D-44221 Dortmund (Germany) www-ai.cs.uni-dortmund.de
                                      • Simon Horrell
                                        Section 5 is a default schema anyway. The problem is that XML schemas do not standardize what certain programming constructs will look like (arrays,
                                        Message 19 of 29 , Jul 27, 2001
                                        • 0 Attachment
                                          Section 5 is a default schema anyway. The problem is that XML schemas do not
                                          standardize what certain programming constructs will look like (arrays,
                                          references,...). AFAICS in the absence of this standardization an additional
                                          common encoding style is fair enough.

                                          Taking up you point about native types though. If you subscribe to the view
                                          that SOAP is an interoperability protocol then it seems like the best
                                          approach is to use XSD literal style wherever possible. Encoding types (and
                                          their meaning) that are native to a particular run-time in an 'informal'
                                          scheme breaks the purpose of SOAP as it starts to mandate features/meaning
                                          that must be supported in the run-time of both sides of a SOAP
                                          communication.

                                          Comments?

                                          Si.


                                          ----- Original Message -----
                                          From: "Simon Fell" <sfell@...>
                                          To: <soapbuilders@yahoogroups.com>
                                          Sent: Thursday, July 26, 2001 8:17 PM
                                          Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                          > For me this is the crux of the issue, this is a big concern I have with
                                          the
                                          > push that is being made to move to XSD literal style from section 5,
                                          AFAICS
                                          > you loose a lot of the XML <-> Native types benefits, I for one don't want
                                          > to write code to de-serialize what 50 other people think an array should
                                          > look like.
                                          >
                                          > Cheers
                                          > Simon
                                          >
                                          > -----Original Message-----
                                          > From: Jacek Kopecky [mailto:jacek@...]
                                          >
                                          > I thought section 5 encoding was added to create a _common_ way
                                          > of representing data structures. This is very important for
                                          > example to RPC where you can say "whatever the parameter's type,
                                          > encode it using your encoding of choice (preferably a common one,
                                          > like SOAP section 5)."
                                          >
                                          > I can easily encode "complex graph like data structures" into XML
                                          > without using SOAP section 5, and in most cases the encoding
                                          > would be even nicer.
                                          >
                                          > Jacek
                                          >
                                          >
                                          > -----------------------------------------------------------------
                                          > 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/
                                          >
                                          >
                                        • Mike Deem
                                          ... complexity a ... Most business applications do not require the use of such graphs (or object databases would have blown away relational databases a long
                                          Message 20 of 29 , Jul 27, 2001
                                          • 0 Attachment
                                            > From: Stefan Haustein [mailto:stefan.haustein@...]
                                            >
                                            > Mike Deem wrote:
                                            > >
                                            > > Why accept the overhead, bugs, interoperability issues, and
                                            complexity a
                                            > > layer that *only* translates from the XML data model to/from the
                                            > > RPC/struct/array data model? The XML data model is richer and easy
                                            > > enough to program to.
                                            >
                                            > The XML data model describes trees. SOAP provides
                                            > rules for encoding graphs. Since trees are specialized
                                            > graphs, the Sec5 data model is richer than plain XML.

                                            Most business applications do not require the use of such graphs (or
                                            object databases would have blown away relational databases a long time
                                            ago).

                                            >
                                            > Sec5 just fits better to the arrows-and-boxes UML
                                            > models programmers are used to. XML Schema cannot
                                            > compete with UML.
                                            >

                                            You have a point here. However, the same argument goes for the
                                            relational data model, yet it is still very popular.

                                            == Mike ==
                                          • Mike Deem
                                            ... complexity a ... What about XSD based validation? Or, more accurately, PSVI (Post Schema Validation Infoset, a strongly typed infoset data model)? ...
                                            Message 21 of 29 , Jul 27, 2001
                                            • 0 Attachment
                                              > From: Stefan Havenstein [mailto:Stefan.Havenstein@...]
                                              > >
                                              > > Why accept the overhead, bugs, interoperability issues, and
                                              complexity a
                                              > > layer that *only* translates from the XML data model to/from the
                                              > > RPC/struct/array data model? The XML data model is richer and easy
                                              > > enough to program to.
                                              > >
                                              > Type safety?

                                              What about XSD based validation? Or, more accurately, PSVI (Post Schema
                                              Validation Infoset, a strongly typed infoset data model)?

                                              >
                                              > I don't really get the point here - does Mike say that it's better to
                                              > program against the, say, DOM, and manipulate strings, than to get at
                                              > least some dumb but type safe representations of the data? And why
                                              > should the latter be error-prone? If it's a well-tested tool, it's
                                              > much less error-prone than to play around on the DOM level.
                                              >

                                              Programming against the DOM (or SAX or XmlReader/Writer) does not
                                              necessarily imply that you are dealing with strings. Given schema, those
                                              programming models can expose strongly typed information.

                                              > > I don't see how those problems magically go away, just because you
                                              have
                                              > > a bunch of XSD schemas.
                                              > I think that Schemas, together with an appropriate language binding,
                                              > give you big productivity benefits, as the programming language
                                              constructs
                                              > generated from that are 'first class' objects from the point of view
                                              of
                                              > your application logic, i.e. you don't need further translation steps
                                              > before being able to deal with their data.

                                              Imagine this scenario: a mid-sized company Springs-R-Us that makes
                                              springs. They sell those springs to BigCoA and BigCoB to be put in cars
                                              and washing machines. Springs-R-Us has good business systems: order
                                              management, purching, inventory, forcasting, etc.

                                              BigCoA says "you must implement web service X, described by X.wsdl, if
                                              you want to sell to us." X.wsdl lets BigCoA get bids for springs, order
                                              springs, and track order status. So, Springs-R-Us builds a web service
                                              that maps the data types described in X.wsdl to their existing systems.
                                              Those data types are NOT the objects already in the Springs-R-Us system,
                                              they are just a different way to represent some of the same data.
                                              Springs-R-Us

                                              Now, BigCoB does the same thing, but using Y.wsdl. Y.wsdl defines
                                              different data types containing slightly different data. Springs-R-Us
                                              can't say no or they will go out of business. So they put up another web
                                              service that maps the Y data types to their existing system.

                                              A sub-scenario: Springs-R-Us doesn't have nice business systems when
                                              BigCoA says implement X.wsdl. So they build business systems around
                                              X.wsdl. When Y.wsdl comes along, they have to add new functionality to
                                              the X based objects to support Y. That breaks their X web service. Using
                                              the data types exposed in a web service interface as the core data types
                                              of an application is dangerous design pattern.

                                              My point is: it doesn't matter if you can generate fancy objects from
                                              schemas. Those fancy objects are NOT going to be the ones you care
                                              about. You still have to write code that maps the data in those objects
                                              to the objects your system is really built with.

                                              == Mike ==
                                            • Mike Deem
                                              ... do ... (arrays, ... I can describe multi-dimensional arrays and references between elements in schema. There just isn t a standard way to recognize that I
                                              Message 22 of 29 , Jul 27, 2001
                                              • 0 Attachment
                                                > From: Simon Horrell [mailto:simonh@...]
                                                >
                                                > Section 5 is a default schema anyway. The problem is that XML schemas
                                                do
                                                > not
                                                > standardize what certain programming constructs will look like
                                                (arrays,
                                                > references,...). AFAICS in the absence of this standardization an
                                                > additional
                                                > common encoding style is fair enough.

                                                I can describe multi-dimensional arrays and references between elements
                                                in schema. There just isn't a standard way to recognize that I have done
                                                so. However, such a standard is only important if you want to do the XML
                                                <-> array/struct thing.

                                                >
                                                > Taking up you point about native types though. If you subscribe to the
                                                > view
                                                > that SOAP is an interoperability protocol then it seems like the best
                                                > approach is to use XSD literal style wherever possible. Encoding types
                                                > (and
                                                > their meaning) that are native to a particular run-time in an
                                                'informal'
                                                > scheme breaks the purpose of SOAP as it starts to mandate
                                                features/meaning
                                                > that must be supported in the run-time of both sides of a SOAP
                                                > communication.
                                                >
                                                > Comments?
                                                >

                                                Section 5 allows you to encode native types in an interoperable way.
                                                But, getting there in all practice has been, and continues to be a
                                                difficult and time consuming effort.

                                                Clearly there is demand for the RPC/struct/array programming model. It
                                                does offer some apparent simplifications that appeal to a lot of
                                                programmers. However, I believe the XSD/XML/message programming model
                                                offers some significant advantages and reduces over all system
                                                complexity.

                                                If section 5 did not exist, we would have achieved SOAP level interop a
                                                long time ago and could have moved on to more interesting things such as
                                                WSDL interop, and bubbles like attachments, security and routing.

                                                == Mike ==
                                              • Simon Horrell
                                                Comments [inline]. BTW, I was arguing *for* the XSD approach! Si. ... From: Mike Deem To: Sent:
                                                Message 23 of 29 , Jul 27, 2001
                                                • 0 Attachment
                                                  Comments [inline].

                                                  BTW, I was arguing *for* the XSD approach!

                                                  Si.

                                                  ----- Original Message -----
                                                  From: "Mike Deem" <mikedeem@...>
                                                  To: <soapbuilders@yahoogroups.com>
                                                  Sent: Friday, July 27, 2001 6:19 PM
                                                  Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                  >
                                                  >
                                                  > > From: Simon Horrell [mailto:simonh@...]
                                                  > >
                                                  > > Section 5 is a default schema anyway. The problem is that XML schemas
                                                  > do
                                                  > > not
                                                  > > standardize what certain programming constructs will look like
                                                  > (arrays,
                                                  > > references,...). AFAICS in the absence of this standardization an
                                                  > > additional
                                                  > > common encoding style is fair enough.
                                                  >
                                                  > I can describe multi-dimensional arrays and references between elements
                                                  > in schema. There just isn't a standard way to recognize that I have done
                                                  > so.

                                                  [Si] Agreed.

                                                  However, such a standard is only important if you want to do the XML
                                                  > <-> array/struct thing.

                                                  [Si] I assumed that this was what the conversation was predicated upon.

                                                  >
                                                  > >
                                                  > > Taking up you point about native types though. If you subscribe to the
                                                  > > view
                                                  > > that SOAP is an interoperability protocol then it seems like the best
                                                  > > approach is to use XSD literal style wherever possible. Encoding types
                                                  > > (and
                                                  > > their meaning) that are native to a particular run-time in an
                                                  > 'informal'
                                                  > > scheme breaks the purpose of SOAP as it starts to mandate
                                                  > features/meaning
                                                  > > that must be supported in the run-time of both sides of a SOAP
                                                  > > communication.
                                                  > >
                                                  > > Comments?
                                                  > >
                                                  >
                                                  > Section 5 allows you to encode native types in an interoperable way.
                                                  > But, getting there in all practice has been, and continues to be a
                                                  > difficult and time consuming effort.

                                                  [Si] I find section 5 to be too ad hoc and ambiguous for true interop. The
                                                  fact that you can represent native type seems to me to be dangerous for the
                                                  very reasons I gave.

                                                  >
                                                  > Clearly there is demand for the RPC/struct/array programming model. It
                                                  > does offer some apparent simplifications that appeal to a lot of
                                                  > programmers. However, I believe the XSD/XML/message programming model
                                                  > offers some significant advantages and reduces over all system
                                                  > complexity.

                                                  [Si] I agree. After pondering over this a lot I believe that stripping away
                                                  the RPC layer to reveal the underlying messaging is liberating for all kinds
                                                  of reasons.

                                                  >
                                                  > If section 5 did not exist, we would have achieved SOAP level interop a
                                                  > long time ago and could have moved on to more interesting things such as
                                                  > WSDL interop, and bubbles like attachments, security and routing.

                                                  [Si] If you are saying that we should have started from XSD then I agree
                                                  entirely.

                                                  >
                                                  > == Mike ==
                                                  >
                                                  >
                                                  >
                                                  > -----------------------------------------------------------------
                                                  > 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/
                                                  >
                                                  >
                                                • Mike Deem
                                                  ... Yes. I didn t mean to make it sound as if you were not. I m glad that there is at least one other person who shares the minority opinion. Actually, it may
                                                  Message 24 of 29 , Jul 27, 2001
                                                  • 0 Attachment
                                                    > From: Simon Horrell [mailto:simonh@...]
                                                    >
                                                    > BTW, I was arguing *for* the XSD approach!
                                                    >

                                                    Yes. I didn't mean to make it sound as if you were not. I'm glad that
                                                    there is at least one other person who shares the minority opinion.

                                                    Actually, it may only be on this forum where it is the minority opinion.
                                                    Much of the effort surrounding SOAP interop to date has gone into
                                                    section 5. If you ignore section 5, interop at the SOAP level is trivial
                                                    and there is no reason to hang out on soapbuilders. When interop moves
                                                    beyond section 5 to encompass WSDL and bubbles the messaging folks may
                                                    begin to appear :-).

                                                    == Mike ==
                                                  • Simon Horrell
                                                    ... From: Mike Deem To: Sent: Friday, July 27, 2001 7:33 PM Subject: RE: [soapbuilders] SOAP Design
                                                    Message 25 of 29 , Jul 27, 2001
                                                    • 0 Attachment
                                                      ----- Original Message -----
                                                      From: "Mike Deem" <mikedeem@...>
                                                      To: <soapbuilders@yahoogroups.com>
                                                      Sent: Friday, July 27, 2001 7:33 PM
                                                      Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                      >
                                                      >
                                                      > > From: Simon Horrell [mailto:simonh@...]
                                                      > >
                                                      > > BTW, I was arguing *for* the XSD approach!
                                                      > >
                                                      >
                                                      > Yes. I didn't mean to make it sound as if you were not. I'm glad that
                                                      > there is at least one other person who shares the minority opinion.
                                                      >
                                                      > Actually, it may only be on this forum where it is the minority opinion.
                                                      > Much of the effort surrounding SOAP interop to date has gone into
                                                      > section 5. If you ignore section 5, interop at the SOAP level is trivial
                                                      > and there is no reason to hang out on soapbuilders. When interop moves
                                                      > beyond section 5 to encompass WSDL and bubbles the messaging folks may
                                                      > begin to appear :-).

                                                      [Si] Actually I wonder if WSDL doesn't compound the problem at the moment by
                                                      making it possible to *not* use XSD or indeed not use XML to communicate
                                                      (HTTP GET and POST binding)! My definition of a web-service would be
                                                      something that used Internet-friendly protocols, XML on the wire and XSD to
                                                      describe type.

                                                      >
                                                      > == Mike ==
                                                      >
                                                      >
                                                      >
                                                      > -----------------------------------------------------------------
                                                      > 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/
                                                      >
                                                      >
                                                    • Mike Deem
                                                      ... moment ... communicate ... XSD ... Agreed. However, because you can use XSD in WSDL to describe XML messages flowing over HTTP, it can be a starting point.
                                                      Message 26 of 29 , Jul 27, 2001
                                                      • 0 Attachment
                                                        >
                                                        > [Si] Actually I wonder if WSDL doesn't compound the problem at the
                                                        moment
                                                        > by
                                                        > making it possible to *not* use XSD or indeed not use XML to
                                                        communicate
                                                        > (HTTP GET and POST binding)! My definition of a web-service would be
                                                        > something that used Internet-friendly protocols, XML on the wire and
                                                        XSD
                                                        > to
                                                        > describe type.
                                                        >

                                                        Agreed. However, because you can use XSD in WSDL to describe XML
                                                        messages flowing over HTTP, it can be a starting point.

                                                        == Mike ==
                                                      • Bob Cunnings
                                                        Hello, Hello, comments inline... ... [RC] I don t think that anyone disagrees that the XSD/XML/message design is very attractive and has a bright future. At
                                                        Message 27 of 29 , Jul 27, 2001
                                                        • 0 Attachment
                                                          Hello,
                                                          Hello,

                                                          comments inline...
                                                          >
                                                          >
                                                          > > From: Simon Horrell [mailto:simonh@...]
                                                          > >
                                                          > > BTW, I was arguing *for* the XSD approach!
                                                          > >
                                                          >
                                                          > Yes. I didn't mean to make it sound as if you were not. I'm glad that
                                                          > there is at least one other person who shares the minority opinion.
                                                          >
                                                          > Actually, it may only be on this forum where it is the minority opinion.

                                                          [RC] I don't think that anyone disagrees that the XSD/XML/message
                                                          design is very attractive and has a bright future. At the same time, it represents
                                                          somewhat of a departure from conventional practice, and will take some time to
                                                          gain momentum, not to mention good tools and stable specs. At the same time, it
                                                          might not be the best choice for those tasked with introducing SOAP as glue in
                                                          legacy apps using RPC interaction models, a common activity these days.

                                                          > Much of the effort surrounding SOAP interop to date has gone into
                                                          > section 5. If you ignore section 5, interop at the SOAP level is trivial
                                                          > and there is no reason to hang out on soapbuilders.

                                                          [RC] Right, its focus at the moment is Section 7 RPC using
                                                          Section 5 encoding, since that *is* nontrivial, and there is great
                                                          demand for it. As you say, if you ignore Sections 5 and 7, the
                                                          difficulty of SOAP interop fall to the level of, say, CGI interop.


                                                          When interop moves
                                                          > beyond section 5 to encompass WSDL and bubbles the messaging folks may
                                                          > begin to appear :-).

                                                          [RC] IMO WSDL interop is the next big effort, but that is tangential
                                                          to SOAP interop per se. It certainly is a popular topic, however,
                                                          and an important one to many SOAP implementors.

                                                          RC


                                                          >
                                                          > == Mike ==
                                                          >
                                                          >
                                                          >
                                                          > -----------------------------------------------------------------
                                                          > 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/
                                                          >
                                                        • Yasser Shohoud
                                                          Graham, ... without being limited to dumb structs and arrays. this is done by generic serialization logic and does not involve the creation of any custom
                                                          Message 28 of 29 , Aug 1, 2001
                                                          • 0 Attachment
                                                            Graham,

                                                            > but GLUE can already map bidirectionally between XML to java objects
                                                            without being limited to "dumb" structs and arrays. this is done by
                                                            generic serialization logic and does not involve the creation of any
                                                            custom mapping code.

                                                            I think the story is different when you use SOAP for interop across
                                                            platforms/languages. Here's how:

                                                            Assume you have a Java class called invoice that has a bunch of business
                                                            logic. You then write another Java class called invoiceManager that has
                                                            a method:

                                                            public invoice getInvoice(String invId) {...}

                                                            Now you use GLUE to expose getInvoice as an operation of the invoice Web
                                                            service. I then write a non-Java client (say VB.NET) to invoke that
                                                            operation. Assume no interop issues at all, everything is happily using
                                                            section 5 and working. What do I get back as the return value? My
                                                            understanding is that I would get back whatever the client's SOAP
                                                            implementation gives me back. Right?

                                                            Then if the client is using VB.NET, it would get back a VB.NET class
                                                            called invoice that has all the same public fields as your Java invoice
                                                            class. But what about the business logic? I wouldn't automatically get
                                                            that on the client would I?

                                                            Isn't this business logic what differentiates a data structure that acts
                                                            as a data holder from a class that actually adds value by providing
                                                            logic? And if we are going to use data holders, then we could (if we
                                                            wanted to) use XML documents with no loss in functionality. Right?

                                                            _______________________________________________
                                                            Yasser Shohoud
                                                            Web Services resources at http://www.vbws.com
                                                            Read the .NET Web Services newsletter at http://www.vbws.com/newsletter



                                                            -----Original Message-----
                                                            From: graham glass [mailto:graham-glass@...]
                                                            Sent: Friday, July 27, 2001 3:05 AM
                                                            To: soapbuilders@yahoogroups.com
                                                            Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                            hi mike,

                                                            i can only speak from my own perspective, but GLUE can already
                                                            map bidirectionally between XML to java objects without being limited
                                                            to "dumb" structs and arrays. this is done by generic serialization
                                                            logic and does not involve the creation of any custom mapping
                                                            code. in addition, developers can control the mapping beyond the
                                                            standard rules by editing an "annotated schema" which gives runtime
                                                            hints to GLUE on how to perform the java/xml mapping. this makes life
                                                            much easier for java developers, as they can write to their own natural
                                                            APIs without being exposed directly to XML. of course, there is room
                                                            for bugs in the GLUE mapping code, but they are generally easy to fix.

                                                            there are of course cases where you want to send and receive
                                                            XML directly, but in many cases this is not necessary.

                                                            cheers,
                                                            graham

                                                            -----Original Message-----
                                                            From: Mike Deem [mailto:mikedeem@...]
                                                            Sent: Thursday, July 26, 2001 9:18 PM
                                                            To: soapbuilders@yahoogroups.com
                                                            Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                            My premise is that generic serialization code can't directly translate
                                                            between XML and the rich object model that exists inside of an
                                                            application. The best it can do is create "dumb" structs and arrays.

                                                            Also, many services will be exposed though multiple ports to address the
                                                            needs of different kinds of clients. The data exposed by any one port
                                                            will represent different views of the data maintained internally by the
                                                            application. In other words, the structures put on the wire will NOT be
                                                            equivalent to the structures used internally by the application.

                                                            So, no matter what, you have to write code that translates between what
                                                            you get from the network and the application's internal objects. This
                                                            code either pulls data out of structs/arrays and calls methods, or it
                                                            pulls data out of XML and calls methods. Either way, I assert that
                                                            roughly the same amount of effort goes into that code. In other words,
                                                            using structs/arrays here offers no significant advantage.

                                                            However, if you let a tool/framework translate the XML into
                                                            structs/arrays, you introduce the overhead of that translation and the
                                                            opportunity for tool/framework to screw up, and gain no advantage in
                                                            return.

                                                            Furthermore, I believe that there are advantages to using the XML data
                                                            model in this network/application translation layer. You get to leverage
                                                            things like XPath and XSLT, and it makes evolving a system easier (just
                                                            add code to look for a new element instead of creating a new method or
                                                            struct with an additional new parameter).

                                                            == Mike ==

                                                            -----Original Message-----
                                                            From: Simon Fell [mailto:sfell@...]
                                                            Sent: Thursday, July 26, 2001 6:17 PM
                                                            To: 'soapbuilders@yahoogroups.com'
                                                            Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                                            I don't see how those problems magically go away, just because you have
                                                            a
                                                            bunch of XSD schemas.

                                                            Cheers
                                                            Simon

                                                            -----Original Message-----
                                                            From: Mike Deem [mailto:mikedeem@...]
                                                            Sent: Thursday, July 26, 2001 6:05 PM
                                                            To: soapbuilders@yahoogroups.com
                                                            Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                            All serialization can do is translate between XML and simple data types
                                                            like structures and arrays. An application is, most likely, built of
                                                            objects that have behavior (like business rules). There is always hand
                                                            built code that sits between the data model of the message (XML or
                                                            RPC/struct/array) and the application's object model.

                                                            Why accept the overhead, bugs, interoperability issues, and complexity a
                                                            layer that *only* translates from the XML data model to/from the
                                                            RPC/struct/array data model? The XML data model is richer and easy
                                                            enough to program to.

                                                            == Mike ==


                                                            -----Original Message-----
                                                            From: Simon Fell [mailto:sfell@...]
                                                            Sent: Thursday, July 26, 2001 12:17 PM
                                                            To: 'soapbuilders@yahoogroups.com'
                                                            Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                                            For me this is the crux of the issue, this is a big concern I have with
                                                            the
                                                            push that is being made to move to XSD literal style from section 5,
                                                            AFAICS
                                                            you loose a lot of the XML <-> Native types benefits, I for one don't
                                                            want
                                                            to write code to de-serialize what 50 other people think an array should
                                                            look like.

                                                            Cheers
                                                            Simon

                                                            -----Original Message-----
                                                            From: Jacek Kopecky [mailto:jacek@...]

                                                            I thought section 5 encoding was added to create a _common_ way
                                                            of representing data structures. This is very important for
                                                            example to RPC where you can say "whatever the parameter's type,
                                                            encode it using your encoding of choice (preferably a common one,
                                                            like SOAP section 5)."

                                                            I can easily encode "complex graph like data structures" into XML
                                                            without using SOAP section 5, and in most cases the encoding
                                                            would be even nicer.

                                                            Jacek


                                                            -----------------------------------------------------------------
                                                            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/



                                                            -----------------------------------------------------------------
                                                            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/




                                                            -----------------------------------------------------------------
                                                            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/
                                                          • graham glass
                                                            hi yasser, you can use XML documents instead of objects if you want, but this is not a natural way to program for most developers. if i m a java developer, i
                                                            Message 29 of 29 , Aug 2, 2001
                                                            • 0 Attachment
                                                              hi yasser,

                                                              you can use XML documents instead of objects if you want,
                                                              but this is not a natural way to program for most developers.

                                                              if i'm a java developer, i would generally prefer to create
                                                              a class that defines both the data elements and the business
                                                              logic, let the SOAP layer map the incoming XML to the
                                                              data elements automatically, and let my code perform the
                                                              business logic. the mapping is what GLUE will do for you
                                                              automatically.

                                                              cheers,
                                                              graham


                                                              -----Original Message-----
                                                              From: Yasser Shohoud [mailto:yasser.shohoud@...]
                                                              Sent: Wednesday, August 01, 2001 3:47 PM
                                                              To: soapbuilders@yahoogroups.com
                                                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                              Graham,

                                                              > but GLUE can already map bidirectionally between XML to java objects
                                                              without being limited to "dumb" structs and arrays. this is done by
                                                              generic serialization logic and does not involve the creation of any
                                                              custom mapping code.

                                                              I think the story is different when you use SOAP for interop across
                                                              platforms/languages. Here's how:

                                                              Assume you have a Java class called invoice that has a bunch of business
                                                              logic. You then write another Java class called invoiceManager that has
                                                              a method:

                                                              public invoice getInvoice(String invId) {...}

                                                              Now you use GLUE to expose getInvoice as an operation of the invoice Web
                                                              service. I then write a non-Java client (say VB.NET) to invoke that
                                                              operation. Assume no interop issues at all, everything is happily using
                                                              section 5 and working. What do I get back as the return value? My
                                                              understanding is that I would get back whatever the client's SOAP
                                                              implementation gives me back. Right?

                                                              Then if the client is using VB.NET, it would get back a VB.NET class
                                                              called invoice that has all the same public fields as your Java invoice
                                                              class. But what about the business logic? I wouldn't automatically get
                                                              that on the client would I?

                                                              Isn't this business logic what differentiates a data structure that acts
                                                              as a data holder from a class that actually adds value by providing
                                                              logic? And if we are going to use data holders, then we could (if we
                                                              wanted to) use XML documents with no loss in functionality. Right?

                                                              _______________________________________________
                                                              Yasser Shohoud
                                                              Web Services resources at http://www.vbws.com
                                                              Read the .NET Web Services newsletter at http://www.vbws.com/newsletter



                                                              -----Original Message-----
                                                              From: graham glass [mailto:graham-glass@...]
                                                              Sent: Friday, July 27, 2001 3:05 AM
                                                              To: soapbuilders@yahoogroups.com
                                                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                              hi mike,

                                                              i can only speak from my own perspective, but GLUE can already
                                                              map bidirectionally between XML to java objects without being limited
                                                              to "dumb" structs and arrays. this is done by generic serialization
                                                              logic and does not involve the creation of any custom mapping
                                                              code. in addition, developers can control the mapping beyond the
                                                              standard rules by editing an "annotated schema" which gives runtime
                                                              hints to GLUE on how to perform the java/xml mapping. this makes life
                                                              much easier for java developers, as they can write to their own natural
                                                              APIs without being exposed directly to XML. of course, there is room
                                                              for bugs in the GLUE mapping code, but they are generally easy to fix.

                                                              there are of course cases where you want to send and receive
                                                              XML directly, but in many cases this is not necessary.

                                                              cheers,
                                                              graham

                                                              -----Original Message-----
                                                              From: Mike Deem [mailto:mikedeem@...]
                                                              Sent: Thursday, July 26, 2001 9:18 PM
                                                              To: soapbuilders@yahoogroups.com
                                                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                              My premise is that generic serialization code can't directly translate
                                                              between XML and the rich object model that exists inside of an
                                                              application. The best it can do is create "dumb" structs and arrays.

                                                              Also, many services will be exposed though multiple ports to address the
                                                              needs of different kinds of clients. The data exposed by any one port
                                                              will represent different views of the data maintained internally by the
                                                              application. In other words, the structures put on the wire will NOT be
                                                              equivalent to the structures used internally by the application.

                                                              So, no matter what, you have to write code that translates between what
                                                              you get from the network and the application's internal objects. This
                                                              code either pulls data out of structs/arrays and calls methods, or it
                                                              pulls data out of XML and calls methods. Either way, I assert that
                                                              roughly the same amount of effort goes into that code. In other words,
                                                              using structs/arrays here offers no significant advantage.

                                                              However, if you let a tool/framework translate the XML into
                                                              structs/arrays, you introduce the overhead of that translation and the
                                                              opportunity for tool/framework to screw up, and gain no advantage in
                                                              return.

                                                              Furthermore, I believe that there are advantages to using the XML data
                                                              model in this network/application translation layer. You get to leverage
                                                              things like XPath and XSLT, and it makes evolving a system easier (just
                                                              add code to look for a new element instead of creating a new method or
                                                              struct with an additional new parameter).

                                                              == Mike ==

                                                              -----Original Message-----
                                                              From: Simon Fell [mailto:sfell@...]
                                                              Sent: Thursday, July 26, 2001 6:17 PM
                                                              To: 'soapbuilders@yahoogroups.com'
                                                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                                              I don't see how those problems magically go away, just because you have
                                                              a
                                                              bunch of XSD schemas.

                                                              Cheers
                                                              Simon

                                                              -----Original Message-----
                                                              From: Mike Deem [mailto:mikedeem@...]
                                                              Sent: Thursday, July 26, 2001 6:05 PM
                                                              To: soapbuilders@yahoogroups.com
                                                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)


                                                              All serialization can do is translate between XML and simple data types
                                                              like structures and arrays. An application is, most likely, built of
                                                              objects that have behavior (like business rules). There is always hand
                                                              built code that sits between the data model of the message (XML or
                                                              RPC/struct/array) and the application's object model.

                                                              Why accept the overhead, bugs, interoperability issues, and complexity a
                                                              layer that *only* translates from the XML data model to/from the
                                                              RPC/struct/array data model? The XML data model is richer and easy
                                                              enough to program to.

                                                              == Mike ==


                                                              -----Original Message-----
                                                              From: Simon Fell [mailto:sfell@...]
                                                              Sent: Thursday, July 26, 2001 12:17 PM
                                                              To: 'soapbuilders@yahoogroups.com'
                                                              Subject: RE: [soapbuilders] SOAP Design pattern (sort of)

                                                              For me this is the crux of the issue, this is a big concern I have with
                                                              the
                                                              push that is being made to move to XSD literal style from section 5,
                                                              AFAICS
                                                              you loose a lot of the XML <-> Native types benefits, I for one don't
                                                              want
                                                              to write code to de-serialize what 50 other people think an array should
                                                              look like.

                                                              Cheers
                                                              Simon

                                                              -----Original Message-----
                                                              From: Jacek Kopecky [mailto:jacek@...]

                                                              I thought section 5 encoding was added to create a _common_ way
                                                              of representing data structures. This is very important for
                                                              example to RPC where you can say "whatever the parameter's type,
                                                              encode it using your encoding of choice (preferably a common one,
                                                              like SOAP section 5)."

                                                              I can easily encode "complex graph like data structures" into XML
                                                              without using SOAP section 5, and in most cases the encoding
                                                              would be even nicer.

                                                              Jacek


                                                              -----------------------------------------------------------------
                                                              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/



                                                              -----------------------------------------------------------------
                                                              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/




                                                              -----------------------------------------------------------------
                                                              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/
                                                            Your message has been successfully submitted and would be delivered to recipients shortly.