- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Mon, 8 Nov 2004 11:55:50 -0500
- To: "Vinoski, Stephen" <Steve.Vinoski@iona.com>
- Cc: "David Orchard" <dorchard@bea.com>, "Newcomer, Eric" <Eric.Newcomer@iona.com>, public-ws-addressing@w3.org, "Bergersen, Rebecca" <Rebecca.Bergersen@iona.com>
- Message-ID: <OF6558FED4.0B6D11ED-ON85256F45.00741565-85256F46.005D0147@us.ibm.com>
I agree the spec is not clear about how to do this.
Paco
"Vinoski,
Stephen" To: Francisco Curbera/Watson/IBM@IBMUS
<Steve.Vinoski@io cc: "David Orchard" <dorchard@bea.com>, "Newcomer, Eric" <Eric.Newcomer@iona.com>,
na.com> <public-ws-addressing@w3.org>, "Bergersen, Rebecca" <Rebecca.Bergersen@iona.com>
Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR
11/06/2004 11:56
PM
Hi Paco,
I'm aware of the specification's words regarding "logical addresses." I
just don't think it's very clear in this regard, which is why I'm asking
the questions I'm asking. We cannot live without some form of multi-address
EPR. If the current EPR can already do that, as Sanjiva, Dave, and now you
have suggested, then let's augment the spec to make it clear how that is
supposed to work.
thanks,
--steve
-----Original Message-----
From: Paco Curbera, Francisco
Sent: Saturday, November 06, 2004 11:28 PM
To: Vinoski, Stephen
Cc: David Orchard; Newcomer, Eric; Martin Gudgin;
public-ws-addressing@w3.org; public-ws-addressing-request@w3.org;
Bergersen, Rebecca
Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR
One possible approach is to architect embedded metadata into the EPR
that allows encoding alternative addresses for each protocol -
somehow using the address field as a logical address in this case.
This is a possible use case of the embedded metadata I was asked to
rationalize and a possible alternative for this issue. Comments?
Paco
(Embedded image moved to file: pic17296.gif)Inactive hide details for
"Vinoski, Stephen" <Steve.Vinoski@iona.com>"Vinoski, Stephen"
<Steve.Vinoski@iona.com>
(Emb (Embedded image moved to file: (Embedded image moved to file:
edde pic29301.gif) pic26460.gif)
d "Vinoski
imag , To: "David Orchard"
e Stephen" <dorchard@bea.com>, "Martin Gudgin"
move <Steve.V <mgudgin@microsoft.com>,
d to inoski@i "Bergersen, Rebecca"
file ona.com> <Rebecca.Bergersen@iona.com>,
: Sent by: <public-ws-addressing@w3.org>
pic0 public-w cc: "Newcomer, Eric"
2689 s-addres <Eric.Newcomer@iona.com>
.gif sing-req Subject: RE: WS-A Issue 28 -
) uest@w3. Multiple ports needed in an EPR
org
11/06/20
04 04:54
PM
Hi Dave,
I understand the desire for simplicity. But if it's simplicity that
you want, why not forego the EPR entirely and use a URI? You stated
your opinion for why we need an EPR over just a URI in a separate
thread. By what criteria do you judge your need for an EPR rather
than just a URI to be acceptable, while judging our need for
multi-address EPRs to be too complicated?
Obviously you can raise all kinds of hypothetical complications
regarding multi-address or multi-mechanism services. In practice,
it's really not that complicated. Middleware has supported such
constructs for well over a decade now, the best example of which is
probably the CORBA IOR. IORs may consist of one or more profiles,
where each profile may contain a separate address, but all profiles
in the same IOR "point" to the same target object. In practice, most
IORs consist of only a single IIOP profile, but the flexibility for
multiple profiles is there, and it's amazingly handy when you need
it.
If you want to keep the EPR simple, as you stated, are you instead
proposing that this WG also standardize some kind of composite EPR as
well? Because if this WG doesn't address the multi-address issue,
then the layering you're proposing will be strictly proprietary and
non-interoperable, and will proliferate the complication. I already
pointed out the problem with the layering approach in my reply to
Gudge, and that is that it just pushes the problem into the higher
levels of software where it has to be handled again and again and
again, which makes it less likely that it will be handled at all,
which will result in rigid inflexible systems that cannot deal with
protocol, format, and service evolution. Imagine, for example, if all
IORs could contain only a single profile. That would force all CORBA
applications to be able to accept sequences of IORs in all the places
they would normally just accept a single one-or-more-profile IOR. It
forces all the complication up into the applications. Do you really
want to make your users' lives more complicated?
--steve
-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Saturday, November 06, 2004 3:31 PM
To: Vinoski, Stephen; Martin Gudgin; Bergersen, Rebecca;
public-ws-addressing@w3.org
Cc: Newcomer, Eric
Subject: RE: WS-A Issue 28 - Multiple ports needed in an
EPR
Steve,
I agree that in some indeed many cases there may be a
need for multiple "addresses" for a service. But don't we
need an atomic address at some point? I think we do have
a pretty good handle on what the minimum is to address a
single "thing". I'd suggest that any kind of
multi-address construct can be layered on. And there will
be lots of complexity: What's the order of precedence?
Are there any commonalities, like policy across all the
address? Are there policies specific to an endpoint? Are
there different bindings/required properties per
endpoint? I propose that multi-address information should
be layered on top and EPRs remain as simple as we can
keep them, rather than pushing the multi-stuff into EPRs.
By analogy, I agree that molecules are great. And
sometimes just atoms are the thing we want, like gold or
oxygen. The universe deals well with both constructs, but
they do have a layering/composition model.
Another saying I like for standards is "you know your
standard is successful when people go great, but can you
add foo, bar, baz..". That means it hit the minimum
necessary for success.
Cheers,
Dave
From: public-ws-addressing-request@w3.org [
mailto:public-ws-addressing-request@w3.org] On Behalf Of
Vinoski, Stephen
Sent: Friday, November 05, 2004 1:50 PM
To: Martin Gudgin; Bergersen, Rebecca;
public-ws-addressing@w3.org
Cc: Newcomer, Eric
Subject: RE: WS-A Issue 28 - Multiple ports needed in an
EPR
Gudge, take a look at your own business card. Does it
have your address, work phone number, fax number, mobile
number, email address, instant message ID, and your home
page all listed on it, or do you actually have multiple
business cards, one listing your address, a separate one
listing your work phone, another listing your email
address, etc.?
You seem to imply that an endpoint is accessible via only
a single transport and protocol. Where I come from,
endpoints can be accessed over any number of transports
and protocols. Why limit an EPR to describing only a
single path to an endpoint? There is much middleware
prior art in exsitence that proves that such a limit is
completely unnecessary.
--steve
-----Original Message-----
From: Martin Gudgin [
mailto:mgudgin@microsoft.com]
Sent: Thursday, November 04, 2004 2:35 PM
To: Bergersen, Rebecca;
public-ws-addressing@w3.org
Cc: Newcomer, Eric; Vinoski, Stephen
Subject: RE: WS-A Issue 28 - Multiple ports
needed in an EPR
I take issue with the assertion "where there
are different protocols/transports/formats
available for the same service, the "access
to a Web service endpoint" requires the
client to choose among alternatives".
If I, the service, give you, the client, a
single EPR then as far as you are concerned,
there is only one mechansim with which you
can communicate with me. So you don't need to
make any choices ( except whether to
communicate or not, I guess ).
If I am available on multiple EPRs, then I'll
provide you with multiple EPRs (perhaps in a
WSDL document), *then* you have to choose one
from the set.
Gudge
From: public-ws-addressing-request@w3.org [
mailto:public-ws-addressing-request@w3.org]
On Behalf Of Bergersen, Rebecca
Sent: 04 November 2004 11:53
To: public-ws-addressing@w3.org
Cc: Newcomer, Eric; Vinoski, Stephen;
Bergersen, Rebecca
Subject: WS-A Issue 28 - Multiple ports
needed in an EPR
Issue 28 - Multiple ports needed in an EPR
According to the ws-addressing submission,
"Endpoint references convey the information
needed to identify/reference a Web service
endpoint, and may be used in several
different ways: endpoint references are
suitable for conveying the information needed
to access a Web service endpoint...."
However, in the situation where there are
different protocols/transports/formats
available for the same service, the "access
to a Web service endpoint" requires the
client to choose among alternatives, each
accessible in the standard manner through a
port - but there are different ports for each
protocol/transport/format alternative. When
such alternatives exist, the EPR must be able
to identify those multiple ports.
Rebecca Bergersen
Principal Architect, Middleware Standards
rebecca.bergersen@iona.com
-------------------------------------------------------
IONA Technologies
200 West Street Waltham, MA 02451 USA
Tel: (781) 902-8265
Fax: (781) 902-8001
-------------------------------------------------------
Making Software Work Together TM
Attachments
- image/gif attachment: pic17296.gif
- image/gif attachment: pic02689.gif
- image/gif attachment: pic29301.gif
- image/gif attachment: pic26460.gif
Received on Monday, 8 November 2004 16:56:39 UTC