Re: DR201, DR202 and DR203: Programming Language Bindings

(long note warning)

Ray Whitmer writes:

>> I thought that binding to programming languages 
>> was the whole point of defining yet another 
>> way of serializing objects.

Underlying this discussion is an important difference of opinion regarding 
the reasons for having an RPC model and associated data model.  Let me 
briefly repeat the point of view that I expressed at our face to face 
meeting in Raleigh. 

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

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:

                switch(element.Name) {
                        ....
            case checkCreditCard:
                        ...validate credit card here...
                break;
                        ...
                };
                // yes I know Java doesn't
                // switch on strings, but
                // you get the idea

Indeed, a second credit card company might implement the same XP interface 
in Java using methods after all.  You as a client should be able to invoke 
either implementation transparently.

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".

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.

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 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"
                         );
        }

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.

I suspect this note will generate some discussion, but I should point out 
that I expect to be out of touch next week.  Please take no offense if I 
am not there to respond to comments for awhile, and thanks for your 
patience with this long note.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Friday, 17 November 2000 16:32:38 UTC