Re: DR201, DR202 and DR203: Programming Language Bindings

Noah_Mendelsohn@lotus.com wrote:
[...]

> Why I think we're confusing each other
> ======================================
> 
> A traditional application of earlier Remote Procedure Call or ORB systems 
> might be explained informally as:  "I've got these objects lying around, 
> how can I access them remotely?"  In this view, the objects and their 
> interfaces are a given, and the detailed semantics of their correct use 
> are  wrapped up in particular programming languages (e.g. Java) or objects 
> systems (e.g. COM or CORBA).  When building an RPC system for this world, 
> success is proving that you can remotely expose these interfaces in all 
> their detail.  If you subscribe to this view for XP (I don't), then it is 
> clear why you would want to specify and verify language bindings.

I never subscribed to this model as desirable.  But enough other people 
have clung to this use case, and it seemed to me to be a plausible way 
of weening them away from their specific language-, object-, or 
IDL-centric way of defining implementation-biased interaction interfaces.

> I believe that the interesting target for XP and SOAP is modeled very 
> differently.  Let's say that I want to offer a credit card validation 
> service on the Web using XP RPC.  I advertise (using WSDL, UDDI, talking 
> to you on the phone or whatever) an XP interface which is a single method 
> that takes as arguments a string credit card number and a decimal amount, 
> and returns a Boolean to indicate whether the card is valid.

Please define an XP interface, tell me how it is specified, and tell why 
it  is different from an XML message and an IDL declaration.  You appear 
to be dragging in language-isms or IDL-isms that in my experience are 
not necessarily useful in such a message.

A year or two ago, I created the XML message schema (not Schema) and 
services currently in use by a major credit card / check/ electronic 
cash clearing house for doing precisely validations and a set of related 
operations.

Such a message often most-usefully contains multiple related requests, 
not a single request.  There is a natural structure to the information, 
of which CC number is only a small member, that tends to unify the 
information into a larger content model (that is poorly modelled as 
simple parameters).  There are also a number of returns that may have 
structure and relationship as well.

Simple language-style method names, parameters, and returns do not serve 
as well as simple XML for structuring these request messages, in my 
experience.

> Crucial point:  in this scenario, I do not want to know anything about the 
> programming technology used at one end of the line or another.  Even if we 
> have chosen a similar language (e.g. Java), it is none of my business 
> whether you have bound the method call in the same way that I have.  For 
> example, I at the credit card company might very well be using a switch 
> statement instead of a method invocation:

[...]
Certainly, this is a principle I have always held to for what I would 
call the better half of the proposal -- message based exchanges.

But certain SOAP and XP advocates seem driven by the idea that XML and 
schemas are inadequate or inapropriate for messages that are 
RPC-in-nature, and for passing the native objects of some languages.  I 
can agree with that sentiment as long as binding to these languages and 
its objects in specific ways is designated as significant by way of 
requirement.

> Ray: perhaps now it is clearer why some of us are suggesting that language 
> bindings should be beyond the scope of our specification, and why I argue 
> for more emphasis on terminology like "service" than "method" or 
> "procedure".

I never disagreed with the best way to exchange XML messages, using a 
schema-based specification and forcing client and server to bind to them 
using whatever adapters they can devise, which were not designed with 
the language binding in mind at all, but rather with the needs of the 
message in mind.

But in this case, I see no need for an RPC section or for the special 
default object encoding (section 5).  The default encoding can be XML, 
using schemas as they have always been used.  If certain new 
requirements on Schema are identified, then so be it, but we should 
expect to find most things already there because we are doing nothing 
but structuring and exchanging data as we always have in XML (or SGML 
before it).  If this is the message, I agree.

But I haven't heard this message generally, so while there is a set of 
RPC requirements and a percieved need for a "default encoding" I have to 
try to make sense out of  the requirements for one -- seamlessly binding 
into languages, probably using some form of IDL to generate and marshal 
the arguments to a traditional method call.

If the default encoding is not pure schema-based XML, then where is the 
language that describes such a specification.  Whose IDL is it that 
defines such an exchange, explicitly or implicitly?  I think you will 
find Microsoft supporters generating the interfaces using MIDL, corba 
supporters using Corba IDL, Javascript suppliers using Javascript 
binding mechanisms, RMI supporters using RMI, etc.  In these cases, the 
message is transformed IDL which will not always match nicely between 
PLs.  Each language will talk well to the other end if it is the same 
PL, and only with difficulty and manual adaptation where it is not, 
puting the language models in control rather than XML schema.  You have 
to take the CORBA approach and acknowledge this from the beginning so 
that you can intentionally create common ground where all the important 
bindings interoperate fairly cleanly using some form of definition they 
all can tolerate.

> What I think we need
> ====================
> 
> So let's think about what is necessary for success in the above scenarios 
> (which I think should be included in our use cases).
> 
> All parties involved need to understand that there are a set of 
> abstractions provided by XP itself.  These include:
> 
>         - the abstract notion of invoking
>           a named procedure or service
>           (checkCreditCard)
>         - the abstract notion of supplying
>           parameters, getting results,
>           etc..
>         - a type system and data model
>           usable for the parameters and 
>           results.

These things are good for binding to an IDL or language.  Where that is 
a goal, it needs to be explicitly understood and pursued.  Otherwise, 
you will get a good binding to the one language or IDL that the primary 
creator had in mind but has not explicitly stated, and everything else 
will be relative to how mappable the concepts of that language are to 
other languages that might desire similar functionality.

If binding to a language and object model is not a goal, then focusing 
on the programming-language-like notion of parameters and 
programming-language-like objects is neither abstract nor optimal to the 
purpose.

> This is what you can "see on the wire".  Not coincidentally, SOAP 1.1 
> provides exactly these pieces in conjunction with its RPC.  Making it easy 
> to generate bindings to programming languages is a good thing, because 
> many programmers will want automated tools to generate their XP skeletons. 
>  Still, we should not be generating or providing conformance rules for 
> such mappings, except insofar as they follow directly from the contract 
> "on the wire".

I still see wavering here between "we intend to bind directly to 
programming languages" and "no programming model should be implied".  
XML, surrounded by any necessary layer for aggregating related but 
orthogonal requests is what we need on the wire if we do not consider 
programming models.

We also need the model that binds transparently to PLs, if and only if 
that is an important requirement.

> I think the notion of data model needs a bit more emphasis.  Everyone 
> seems to agree on a more or less compatible notion of simple type as found 
> in XML schemas (integer, string, etc.)  To motivate the need for a data 
> model, consider the following Java fragment:
> 
>         Employee e = new Employee(...);
> 
>         // register employee takes 2 arguments,
>         // the employee to register and the 
>         // group manager, which may be the same
>         // as they are in the example below.
> 
>         registerEmployee(e, e);
> 
>         ..........
> 
>         void registerEmployee(Employee newEmp, 
>                                 Employee manager) {
>                 // note == tests object identity
>                 if (newEmp == manager)
>                         System.out.println(
>                           "New employee is the group manager"
>                          );
>         }

This is one representation, but modelling on Java does not necessarily 
yield an optimal or most-abstract message.  Where modelling on a 
specific PL is a desired goal, it should be explicitly stated.  
Statements in the charter that seem to claim that these PL objects are 
somehow more abstract than Schema objects.  How?

> Java semantics make clear that the invoked method code (registerEmployee) 
> can determine the identity of the two arguments.  Question:  can XP 
> invocations carry such rich notions of identity?  In SOAP they can, 
> because the data model used by RPC supports a graph model;  the two method 
> arguments can be edges referring to the same (multiref) object, and the 
> receiving code can unambiguously determine that a single object has been 
> passed for both arguments. 
> Again:  I am not suggesting that there be a single unique mapping of a 
> registerEmployee XP message to Java or to any other language;  I am using 
> the Java code above to illustrate the value of having a well specified and 
> appropriate data model in conjunction with XP RPC.  I can still use switch 
> statements to process registerEmployee.

In fact, identity is often more difficult than has been shown here.  The 
language mapping detail that was omitted on both ends would contain 
things worth studying and questioning.  Identify is more-robustly 
supportable in XML by means of an identity code, rather than relying on 
object reference uniqueness which is often less prevalent than identity 
uniqueness.

I appreciate your response.

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 21 November 2000 20:00:41 UTC