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

Re: Comments on LC issues

Expand Messages
  • Robert van Engelen
    Hi, I see two opposing forces pulling SOAP RPC either way: make it as simple as possible within reasonable constraints, which is good for interoperablility and
    Message 1 of 2 , Jul 24, 2002
      Hi,

      I see two opposing forces pulling SOAP RPC either way: make it as
      simple as possible within reasonable constraints, which is good for
      interoperablility and 'light weightedness'. On the other hand, a limited
      model will derail potential use of SOAP RPC in more complex cases
      that can be handled without adding too much complexity to the SOAP RPC
      encoding style. IMO, SOAP RPC might be extinct before we see any
      real use of it, because users may hitch on to DOC/LIT's expressiveness.
      Let me play the devil's advocate here and add that SOAP is not that
      useful anymore if all it is used for is to envelope XML in a 'tidy'
      message for document exchange. I can do that much easier just over HTTP,
      and REST my case...

      I am not advocating to enhance SOAP RPC beyond a reasonable level,
      but I believe that SOAP RPC should be somewhere in between DOC/LIT
      and the data types commonly found in programming languages. For sake
      of argument, why would xsd:base64Binary be part of SOAP RPC if
      we have arrays (of bytes)?

      I do agree that generics are not orthogonal to structs and arrays,
      which is your basic concern. However, if SOAP RPC is to 'compete'
      as a viable alternative to DOC/LIT, we do want to keep it in the spec.

      To put this into perspective, the struct/arrays SOAP RPC parameter
      encoding is an illustrative example where the SOLE use of generics
      is an appropriate place. Variable parameter lists are very poorly
      represented and handled by arrays. In most cases, the array
      has to be an array of xsd:anyType to enable variable parameter list
      that contain parameters of different types. Does this simplify
      SOAP RPC processing? Generics are natural in this case. Please
      dare to see the horizon beyond implementation details that obscure
      our view.

      To demonstrate 'real-world' uses of generics in contemporary
      programming languages, consider the typical example of a struct
      in C with a pointer field to a dynamic array: it IS a (limited)
      generic. Sure, this can be represented as a struct with an embedded
      array, but the essence is lost in the transformation.

      - Cheers, Robert

      > Well put Jacek. I completely agree with all these arguments. I find no
      > place for Generics and have always found that any complex datatype can
      > be expressed by a combination of structs and arrays. Only the basic
      > building blocks should be provided from which all other types can be built.
      >
      > Pete
      >
      > Jacek Kopecky wrote:
      >
      > > Robert,
      > > it is apparent that SOAP RPC is the main use of SOAP Data Model
      > >(and SOAP Encoding). Although the Data Model is very versatile,
      > >noone really wants to use it, see for example the WSDL movement
      > >(mainly in WS-I) from rpc/encoded to document/literal, i.e. from
      > >remote procedure calls using a graph data model to just sending
      > >documents with XML in them.
      > > This is IMO not caused by any restrictions inherent in the Data
      > >Model but in the fact that everybody already knows XML but few
      > >seem to grasp how other data models serialized to XML could be an
      > >improvement.
      > > My point against generics in the data model is that it is
      > >completely unnecessary and foreign to most programming languages
      > >I know. Most languages have the notion of an array (an ordered
      > >sequence, list) and a struct (bag of named objects). Array alone
      > >are sufficient because you can map the names (known beforehand)
      > >to numbers and use those as indexes. Structs therefore are mostly
      > >a syntactic sugar. Mostly, not quite, because type checking can
      > >be done by assigning different types to the different members of
      > >a struct; this usually cannot be done for array members before
      > >runtime.
      > > So structs are very common. In XML, structs also bring
      > >decentralized extensibility - many parties can add members to a
      > >struct and if name conflicts don't arise (namespaces should help
      > >here), and if there are sensible rules about defaulting missing
      > >data and handling unknown data.
      > > A generic compound type, as defined by SOAP Data Model, feels to
      > >me like an array where each member has a name (type QName). An
      > >array of structs in disguise, isn't it? 8-)
      > > Sparse and partial arrays were removed from SOAP Encoding, being
      > >judged unnecessary for similar reasons.
      > > Finally, SOAP Data Model defines position as total order of a
      > >type's outbound edges. Generics could be imaginably used three
      > >ways:
      > > 1) accessing elements in order
      > > 2) accessing elements by name
      > > 3) accessing elements by order and name
      > > 4) accessing elements by name and order
      > > For the first, arrays suffice. For the second, structs suffice.
      > > For the third case, it is like getting the third element and
      > >then doing something depending on its name. The name is then a
      > >part of the application data and should go there; the solution
      > >being an array of structs that was mentioned before.
      > > The fourth case would first select all elements by their name
      > >and then access this selection by position. But the position here
      > >differs from what SOAP Data Model defines, being a partial order.
      > > Other use for a generic compound type would be if the data was
      > >to be used as a struct *or* an array at the discretion of the
      > >receiver. I've never seen any such application. In any case, such
      > >application don't form a significant percentage and the same
      > >thing can done using only structs and arrays.
      > > Therefore I ask - why do we need generic compound types? My
      > >implementation experience is that they don't fit nicely and
      > >cleanly into an implementation of SOAP Encoding.
      > > Best regards,
      > >
      > >
      > > Jacek Kopecky
      > >
      > > Senior Architect, Systinet Corporation
      > > http://www.systinet.com/
      > >
      > >
      > >
      > >On Fri, 19 Jul 2002, Robert van Engelen wrote:
      > >
      > > > 3. To comment on the Editor's request for comments on "generics":
      > > >
      > > > It is our opinion that generics should be kept in the specification.
      > > > Generics are useful mainly from a practical point of view because
      > > > generics do not widen the gap between SOAP RPC and SOAP DOC/LIT
      > > > data models. We believe that abolishing generics only widens this
      > > > data modeling gap, thereby unnecessarily limiting the expressiveness
      > > > of the data model of SOAP RPC.
      > > >
      > > > 4. We do not oppose the array representation of SOAP RPC invocation.
      > > > However, we do strongly suggest the use of generic types to support
      > > > both struct and array parameter paradigms. In fact, it is our
      > > > opinion that generics should be the ONLY parameter marshalling type.
      > > > In that way, polymorphic remote methods and remote methods with
      > > > variable number of parameters can be supported, while providing a
      > > > similar functionality as parameter marshallings based on structs
      > > > and arrays.
    • Pete Hendry
      I see it differently. Soap-enc s purpose is to provide common data types that are available in most programming languages. For datatypes that are not
      Message 2 of 2 , Jul 24, 2002
        I see it differently. Soap-enc's purpose is to provide "common" data
        types that are available in "most" programming languages. For datatypes
        that are not available to soap-enc directly, it should be possible to
        combine the types that are available to produce the missing types.
        Generics are not "common" to most programming languages. They may be
        mapped to some aspects of more complex languages (such as structs in C
        that use pointers perhaps) but these types can also be represented by
        combinations of structs and arrays.

        For Soap 1.1 some toolkits implemented Generics, others did not. Some
        that implement it have to hash it together using structs and arrays
        because their languages do not have the concept of Generic. I don't
        think soap-enc should be defining types that cannot be represented by
        common programming languages directly. Arrays and Structs are common
        language constructs - common enough that you expect them in almost any
        language.

        Robert van Engelen wrote:

        >Hi,
        >
        >I see two opposing forces pulling SOAP RPC either way: make it as
        >simple as possible within reasonable constraints, which is good for
        >interoperablility and 'light weightedness'. On the other hand, a limited
        >model will derail potential use of SOAP RPC in more complex cases
        >that can be handled without adding too much complexity to the SOAP RPC
        >encoding style. IMO, SOAP RPC might be extinct before we see any
        >real use of it, because users may hitch on to DOC/LIT's expressiveness.
        >Let me play the devil's advocate here and add that SOAP is not that
        >useful anymore if all it is used for is to envelope XML in a 'tidy'
        >message for document exchange. I can do that much easier just over HTTP,
        >and REST my case...
        >

        And you think removing Generics is all it will take for soap-enc to fall
        away? What is this based on when I have yet to see a use for generics in
        any real application (or interop test). You'd think if they were so
        important that they might be a little more common in the wild?

        >
        >I am not advocating to enhance SOAP RPC beyond a reasonable level,
        >but I believe that SOAP RPC should be somewhere in between DOC/LIT
        >and the data types commonly found in programming languages. For sake
        >of argument, why would xsd:base64Binary be part of SOAP RPC if
        >we have arrays (of bytes)?
        >

        There has to be some level of compromise where a type is required that
        makes common use practical. The size of a message becomes unwieldy for
        byte[] and base64Binary addresses that problem. This is a practicality.

        >
        >I do agree that generics are not orthogonal to structs and arrays,
        >which is your basic concern. However, if SOAP RPC is to 'compete'
        >as a viable alternative to DOC/LIT, we do want to keep it in the spec.
        >

        Again I don't see how this can be true when almost no-one has used them
        up to now. Because they don't map to common languages, there is little
        reason for soap toolkits in those languages to want to implement support
        for them (and any support will not be a natural part of the language,
        but an awkward wrapper type).


        >
        >To put this into perspective, the struct/arrays SOAP RPC parameter
        >encoding is an illustrative example where the SOLE use of generics
        >is an appropriate place. Variable parameter lists are very poorly
        >represented and handled by arrays. In most cases, the array
        >has to be an array of xsd:anyType to enable variable parameter list
        >that contain parameters of different types. Does this simplify
        >SOAP RPC processing? Generics are natural in this case. Please
        >dare to see the horizon beyond implementation details that obscure
        >our view.
        >

        I think this is a separate argument about whether there should be both a
        struct and array representation of parameter lists. It's lost on me to
        be honest. I would like to see the array representation dropped since,
        with any other RPC mechanism I have used, parameters are named (and when
        defining a service in WSDL you name the parts of the request/response).

        >
        >To demonstrate 'real-world' uses of generics in contemporary
        >programming languages, consider the typical example of a struct
        >in C with a pointer field to a dynamic array: it IS a (limited)
        >generic. Sure, this can be represented as a struct with an embedded
        >array, but the essence is lost in the transformation.
        >

        In what sense lost? You can reconstruct the data type from the wire
        encoding if it uses struct/array so what is lost? It may not be as
        natural as you would like, but I'm sure there are many examples
        (especially with pointers involved) where you could come up with even
        more cases where soap-enc (including generics) would not be sufficient
        not to "lose the essence" in the transformation. As long as the
        transformation is there that allows reconstructing a type then the
        representation is sufficient.

        Pete
      Your message has been successfully submitted and would be delivered to recipients shortly.