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

RE: [soapbuilders] SOAP Design pattern (sort of)

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