Re: encodings in RPC

 Noah,
 excuse my not responding before, I was vacationing the past
almost three weeks.
 Firstly, I don't think that the change of encodingStyle would
come unexpected on the server. Of course the client and the
server would have agreed that both support the other encoding.
 I tend to agree that a change of encoding should have to be
explicitly allowed by the enclosing encoding. IMHO SOAP/1.1 does
allow such a change. For example SOAP version 1.2 could say in
its encoding chapter:
 "An accessor that indicates a changed encodingStyle represents
a primitive value from the abstract data model point of view.
The actual value of the accessor can be anything, even a complex
data structure."
 I don't like the idea of modeling the rpc structures in terms of
the abstract data model (as opposed to terms of the actual
encoding). This would mean that above the abstract data model
we would have to specify rules for extending it and that way
chaos lies (or at least complexity unnecessary for SOAP).
 If an RPC application needs some other encoding for the
parameters, it can always switch the encoding on the parameters
themselves. If I understand you correctly, you are suggesting
that the application's special encoding's data model would extend
SOAP's data model. I don't think that mandating such a thing is a
good idea.
 If the message indicates the encodingStyle change (with the
encodingStyle attribute), and as long as the encoding styles are
supported by the system, the deserializers have all the
information they need to deserialize the data into an object
graph.
 As you might know, I was even suggesting that RPC be defined
completely independently of any data model/encoding because it's
such a simple application that doesn't need to use a generic data
model. This approach has some drawbacks (mostly in backwards
compatibility) so now I'm advocating basing RPC on the concrete
encoding.
 Best regards (hoping you aren't in lower Manhattan right now)

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Thu, 23 Aug 2001 Noah_Mendelsohn@lotus.com wrote:

 > Jacek Kopecky wrote (..last week, sorry for being slow.  I'm still way
 > behind on email):
 >
 > >> Hello Noah. 8-)
 > >>  On today's telcon, you seemed to suggest that you would support
 > >> completely tying RPC to the SOAP data model or even encoding.
 > >>  Does that mean that you would disallow using encodingStyle
 > >> inside the data? Would you disallow the following?
 > >>
 > >>  <Body>
 > >>    <foo:processUDDIRequest>
 > >>      <theRequest SOAP-ENV:encodingStyle="urn:uddi">
 > >>        <findTModel>
 > >>          ...
 > >>        </findTModel>
 > >>      </theRequest>
 > >>    </foo:processUDDIRequest>
 > >>  </Body>
 > >>
 > >>  Let's say that urn:uddi signifies an encoding of a different
 > >> data model than SOAP's.
 > >>  My opinion is that this should be possible (as opposed to
 > >> forbidden).
 >
 > I think I would mostly forbid it, or at least have the results dependent
 > on the outermost encoding.  More specifically, I would suggest the
 > following:
 >
 > * The purpose of Chapter 7 is to allow general purpose middleware to bind
 > SOAP messages to languages such as Java, PERL, etc.  To do this
 > effectively, any given implementation needs to know in advance the range
 > of data models and encodings to be accepted.
 >
 > * SOAP 1.1 chapter 5 embodies a data model (structs, arrays, schema simple
 > types) and one encoding of that model.  SOAP v1.1 chapter 7 specifically
 > says that the arguments to an RPC are modeled as a struct.  Of course, to
 > understand what the struct is you must understand the types and encodings
 > of the entire data graph that the struct references.  So, if somewhere in
 > the graph you switch to an encoding that is arbitrary, I don't see how the
 > deserializers and language bindings can do their job.
 >
 > * I have suggested that the dependency should be on the model (structs)
 > rather than on the particular encoding.  So, I would suggest that it be
 > possible, if not necessarily desireable, for you to be able to define a
 > new encoding that (a) includes the base SOAP data model, and therefore
 > provides the struct model on which the RPC spec depends and (b)
 > specifically defines the interpretation of a nested encoding switch, in
 > effect including the new encoding in its own definition.
 >
 > In short, I think you want the deserializers to have the information they
 > need to reconstruct the data graph in all cases.  Otherwise, you're
 > effectively switching into flat message mode in the middle of an RPC.
 > Actually, I do think it would be interesting to add some types that
 > represent XML itself, but that's mostly a different discussion.
 >
 > -----------------------------------------------------------------------
 > Noah Mendelsohn                                    Voice: 1-617-693-4036
 > Lotus Development Corp.                            Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------------
 >
 >
 >

Received on Tuesday, 11 September 2001 10:53:00 UTC