RE: Late binding

This is pretty good Roger. I'd like to chime in here to make a more
detailed delineation of binding timing options with Web services. It has
been useful for me to explain to others that we have 4 choices based on
when the interface is set and the location is set. I'll go thru these from
most static to most dynamic. Any of these types can use DII style
invocation.

In these the WSDL PortType is known at development time and the options
vary on when you pick a location.
1. Static Development Time Binding - The WSDL Port is known and set at
development time. This means you know the PortType and the Location.
Typically the programming model for this is Stub based - stubs are
generated based on the WSDL PortType and the location is set in the Stub by
the Stub generation tool or the service requestor program. (scenario:
Hospital always buys rubber gloves from MedSupplierGeneral because they
sign yearly contracts.  PortType may be standard or prescribed by
MedSupplierGeneral)

2. Static Deploy Time Binding - The WSDL PortType is known and set at
development time, but  the Location is not set until deployment of the
service. This means that at deployment  the deployment program look up and
select a Port and gets a Location from it.  Typically the programming model
for this is Stub based - stubs are generated based on the WSDL PortType and
the location is set for the Stub (in some environment variable, etc.) by
the deployment program. (scenario: Hospital is part of a Hospital Group and
has the freedom to contract with and pick its own rubber glove supplier.
Hospital Group provides the ordering software to Hospital. Works best if
theres a defacto standard PortType for ordering gloves)

3. Static Runtime Binding - The WSDL PortType is known and set at
development time, but NOT the Location. This means that at deployment or
Runtime, the service requestor program look up and select a Port and get a
Location from it.  Typically the programming model for this is Stub based -
stubs are generated based on the WSDL PortType and the location is set in
the Stub by the service requestor program. In a fancy Web services
infrastructure, the infrastructure may pick the location for the requestor
based on factors outside the requestor's knowledge. (scenario: Hospital
doesn't do contracts with vendors and always polls a set of vendors for
best available price on gloves. Almost requires a standard PortType for
price quotes and ordering gloves )

In these the WSDL PortType is NOT known at development time
4. - Dynamic Binding - The WSDL PortType is not known or set at development
time. Neither is the location. The service requestor is repsonsible for
finding a service it wants to use, introspecting the portType and invoking
it using a DII or a runtime generated Stub or Proxy. (scenario: Hospital
doesn't do contracts with vendors and always polls a set of vendors for
best available price on gloves. If there are no standard PortTypes for
price quotes and ordering gloves, the softward could introspect a variety
of WSDLs looking for a certain message signature or variations of a message
signature it can recognize as a getPrice or orderGloves operation. Since we
don't have many (or ANY!) stardized PortTypes yet.... you can see how this
has to happen. )

A variation on 4 is where you know your location at development or
deployment time, but not the PortType you will use. In this case you query
the location for supported Ports, introspect and pick a port. (you always
send the IRS your tax return, but not sure which portType to use...)

We are seeing implementations of the first three fairly commonly. The last
is a little more 'out there', but its possible and desirable for some
scenarios.
I feel that we must be prepared to develop an architecture that can support
it all three of these binding timings.

Heather Kreger
Web Services Lead Architect
STSM, SWG Emerging Technology
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572


"Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>@w3.org on
06/26/2002 11:31:18 AM

Sent by:    www-ws-arch-request@w3.org


To:    "'bytecode@Phreaker.net'" <bytecode@Phreaker.net>, w3arch <www-ws-
       arch@w3.org>
cc:
Subject:    RE: Late binding




I cannot give you a clear and precise definition of early and late binding
in web services, but since the answers to your queries seem to be
discussions of GET, let me tell you what my imprecise understanding is:

If I am writing a piece of code that intends to call a web service, one
alternative is to bring the WSDL into the development environment which
examines it and presents me with programming objects (I told you this would
be imprecise) that expose the methods of the web service.  I can, if I
wish,
then write code that invoke those methods and arrange so that invokations
of
that code go directly to the web service and invoke those methods without
looking at the WSDL again.  In a controlled environment where I can depend
on the web service being stable this approach can have attractive
performance characteristics because it avoids constant messing with WSDL
files.  This is early binding (and is mostly the way I think we would use
web services in business applications, which do tend at this point to be
rather controlled environments).

The late binding scenario would be to write code which discovers at
runtime,
by examining the WSDL of the web service, what the interface is and then
uses that interface.  This is more robust to discovering and using web
services that might change unpredictably or have variable characteristics,
but in practice there is a considerable performance hit from messing around
with the WSDL every time you access the web service.  And since the
interface is unknown at design time the IDE cannot give you as much
assistance in using the web services.

These comments obviously reflect our preference for early binding -- I'm
sure that there are ways of describing how early and late binding work that
would emphasize the strengths of late binding.  Both techniques obviously
have their strengths and circumstances where use is appropriate.

-----Original Message-----
From: Sam [mailto:bytecode@Phreaker.net]
Sent: Tuesday, June 25, 2002 7:14 PM
To: w3arch
Subject: Re: Late binding



I m looking for a clear and precise definition of early
and late binding in the context of web services.

Can anyone help me with that

Thanks
/sam



Mark Baker wrote:
>
> Hi Roger,
>
> On Tue, Jun 25, 2002 at 12:46:46PM -0700, Cutler, Roger (RogerCutler)
> wrote:
> > I'm not sure why you think that early binding is such a bad thing.
> > In many instances late binding is a bad thing for various practical
> > reasons.  I myself tend to avoid late binding if I possibly can.
> > This is not just me -- it is an accepted architectural principle in
> > our company's development community, and I believe that there are
> > other companies with similar views.
> >
> > Actually, I don't think that a discussion of whether early or late
> > binding is a "good" or "bad" thing is likely to be very productive.
> > I think that both are necessary and both must be supported.  I would
> > be very, very resistant to a suggestion that early binding should
> > somehow be forbidden or made impossible.  If you feel that
> > supporting late binding is critical I won't argue with you -- as
> > long as you leave my early binding alone.
>
> For sure.
>
> But just so you know my position, late binding is absolutely required
> for Internet scale services, primarily because the coordination costs
> of early binding are prohibitive between parties that don't already
> know one another (and have a trusted relationship in which they can
> exchange information about their services).
>
> You can observe this with any SOAP 1.1 based service.  If I come
> across some WSDL, where I had no previous knowledge of that service,
> then I can't use the service.
>
> Contrast this with the Web; if I come across a HTTP URI, I know that I
> can interact with the resource using HTTP's methods.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com