Re: DR201, DR202 and DR203: Programming Language Bindings

Noah,

I'm not on the xml-dist-app mailing list, but my colleague Henry Lowe, who
is, forwarded your note to me. I haven't seen the surrounding thread, so
I'm just reponding to this one note. I apologise if I'm repeating anything
anyone has said elsewhere in the thread - however, I do feel it's important
to clear up some misconceptions that seem to be floating around.

You wrote:

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

It would be much more accurate to characterise ORB-based systems as "I've
want to provide remote access to a bunch of services".

If you read the specifications CORBA-based services we've standardised,
such as Patient Identification (for healthcare), Product Data Management
(for manufacturing), Telecom logging (for Telecoms), you'll find they
provide remote access to medium- or large-grained services, not
fine-grained programming objects. Once upon a time there may have been
people who thought that ORBs were for providing remote access to individual
programming language objects, but their delusions didn't survive their
first implementation project.

By the way, the examples I'm giving aren't hypothetical, they're
specifications being used in real production systems at large companies.
You can download the specs from OMG's Web site.

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

You're confusing language bindings with Interface Definition Languages (IDLs).

An IDL is a language-neutral notation for specifying what a service
interface does. Rather than expose details about implementation, it's there
to *hide* the implementation behind a service interface which presents only
the things the client needs to know about the service.

IDLs are completely separate from language bindings.

Language bindings allow you to build a service implementation in a
particular programming language and bind it to the ORB infrastructure.
Everything about the language binding and the programming language used is
completely hidden from the client of the service, which cannot tell if the
server was built using C++, Java, Ada, Common Lisp, Smalltalk, PL/1, or
whatever. The reason we standardise language binding is *only* to provide
application portability between different implementations of the ORB
infrastructure. Those who don't want this portability can use home-grown
(non-standard) language bindings, and still advertise services specified in
IDL. Clients will never know.

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

This is the crucial point that you're missing.

We do *exactly* this in ORBs using IDL. As you point out, we do not want to
know "anything about the  programming technology used at one end of the
line or another", and we don't have to. In your example, we would advertise
an IDL "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". I've quoted your words exactly because they
apply *exactly* to the ORB case.

The distinction you are trying to make between your XP proposal and
long-established ORB technology does not exist.

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

This is true of IDL-based ORB technology.

>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 exactly the level of abstraction provided by an ORB via its IDL.

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

In the ORB world these tools are called "IDL compilers". They turn IDL
descriptions into stubs and skeletons in particular programming languages.

As I've pointed out, we need standardised language binding only for
application portability. People can and do design their own language
bindings. If they do, all that they sacrifice is application portabilty
between different vendor's ORBs (which may not matter to them).

Of course, we all understand that software vendors are pure in thought,
word and deed, but if there was such a thing as a machiavellian vendor that
wanted to lock his customers into using only his own products (while still
giving him the illusion that he was getting the benefit of using
"standards") then he'd do exactly what you propse - create standards for
wire protocols alone, and not the tools that drive the protocol nor the
language bindings to those tools. In this hypothetical world of cynical,
self-serving software vendors, customers would be told that not having
standard language bindings or standard tools was freeing them from a
straightjacket of inflexibility, and might not notice until it was too late
that wire protocol standardisation *alone* isn't enough to give them the
benefits of open, vendor-neutral systems. What a good thing we don't live
in such a world, and all software vendors are far too high-minded to try to
lock in their customers. However, just be to completely sure, we in OMG
have for many years been creating standards for tool interfaces and
language bindings.


                            Regards,

                                 Andrew
 Andrew Watson                              Tel:     +1 781 444 0404 x111
 Vice President & Technical Director,       Fax:     +1 781 444 0320
 Object Management Group,                   Email:   andrew@omg.org
 250 First Avenue, Suite 201                Lat/Lon: 42.3122 N 71.3927 W
 Needham, MA 02494, USA                     http://www.omg.org/~andrew

Received on Thursday, 23 November 2000 13:25:07 UTC