[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
_____
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: Friday, May 28, 2004 11:53 AM
To: Jan Alexander; 'Greg Pavlik'; 'Furniss, Peter'
Cc: 'Green, Alastair J.'; 'ws-caf'
Subject: Re: [ws-caf] Mt Everest and WS-CF
Jan, I hope you didn't think I was suggesting that WS-Addressing does place
context into the address, but rather commenting on 'WS-Addressing is
particularly interesting because it is essentially "opaque context"' As I
said, context shouldn't be within an address.
However, it's a different argument as to whether the use of
ReferenceProperties to create the equivalent of an IOR
(ReferenceProperties==Object Key) is a good thing. If you read the recent
paper on WSJ comparing WS-Context with WS-RF I think you'll see the argument
against in a much stronger way than I have time to write in this email.
Mark.
----- Original Message -----
From: Jan Alexander <mailto:alex@systinet.com>
To: 'Mark Little' <mailto:mark.little@arjuna.com> ; 'Greg
<mailto:greg.pavlik@oracle.com> Pavlik' ; 'Furniss, Peter'
<mailto:Peter.Furniss@choreology.com>
Cc: 'Green, Alastair J.' <mailto:Alastair.Green@choreology.com> ; 'ws-caf'
<mailto:ws-caf@lists.oasis-open.org>
Sent: Friday, May 28, 2004 10:42 AM
Subject: RE: [ws-caf] Mt Everest and WS-CF
WS-Addressing does not place context into the address. What it does, it uses
set of SOAP headers to identify execution context for the particular
"Endpoint" by introducing EndpointReference abstraction. The EndpointReference
itself additionally contains logical address of the endpoint and a set of
policies, which are relevant to the use of that EndpointReference.
It is important to distinguish between a service address and a service
instance identifier. The first is similar to for instance IP addresses and
port number, the second to CORBA IOR. I don't see anything against "SOA
principles" in the EndpointReference concept as it is not just a service
address. I agree that it would be useful to use WS-Context for mapping
EndpointReferenceProperties into SOAP headers as they identify the execution
context of the endpoint.
Jan
_____
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: Friday, May 28, 2004 11:25 AM
To: Greg Pavlik; Furniss, Peter
Cc: Green, Alastair J.; ws-caf
Subject: Re: [ws-caf] Mt Everest and WS-CF
+1.
I'd also like to suggest that context embedded in an address isn't really the
right way to go. Despite the fact that we (Jim, Savas, myself and others) have
suggested that ReferenceProperties *could* use WS-Context, that doesn't
necessarily mean that it's the best way of tackling the problem. Suggesting
that context within an address is the right model is ignoring SOA principles.
Mark.
----- Original Message -----
From: Greg Pavlik <mailto:greg.pavlik@oracle.com>
To: Furniss, Peter <mailto:Peter.Furniss@choreology.com>
Cc: Green, Alastair J. <mailto:Alastair.Green@choreology.com> ; Mark
<mailto:mark.little@arjuna.com> Little ; ws-caf
<mailto:ws-caf@lists.oasis-open.org>
Sent: Thursday, May 27, 2004 3:56 PM
Subject: Re: [ws-caf] Mt Everest and WS-CF
Furniss, Peter wrote:
Greg,
<snip the earlier part of the alastair .. thread>
A further comment on the IBM/MS product specs: there are in
fact three
contextualization mechanisms: one in WS-Coordination, one in
WS-ReliableMessaging, and one in WS-Addressing. Putting aside
WS-Addressing for a moment since it introduces a new model to the web
services environment that I don't want to argue about here, let me
observe that there is no fundamental distinction between the
lifecycle
control interface in WS-Coordination and WS-ReliableMessaging. Why
shouldn't these be based on a common model? Wouldn't that in fact be
simpler and less error prone? From there, it seems a small step to
imagine the reliability and coordination/transaction contexts
having a
common root. I submit that this is in fact a flaw, not a strength, of
the specification set; they they are unnecessarily complex due to the
failure to deal with common constructs, idioms and patterns as, well,
things-in-common.
Well the WS-Coordination and WS-RM both have equivalent of "begin".
WS-RM doesn't always use it,
and when it is used, it is asked of the eventual receiver. The
termination sequences are different, since WS-RM is just stopping, and
WS-Coordination will have delegated to a transaction protocol.
As contextualization, it is true that a message carrying the relevant
headers is "in the context" of those headers, and subject to their
implications. But the same is true of more or less any header - that's
what they're for. WS-Addressing is particularly interesting because it
is essentially "opaque context" - the reference properties don't need to
contain any kind of identifier in the ws-context sense at all (it might
tell the receiver which database to look in, but since only the receiver
knows what they meant, that's fine - it's just a piece of syntactic
partitioning of the address)
Is it fine? What if it happens to conflict with another header since there are
no restrictions? I'd like to suggest that WS-Addressing would benefit from a
container and that this is generally a problem for contextualization based
solely on headers.
. The other two would have an identifier but
that's the only thing they share, I think.
Peter
------=_NextPart_000_0046_01C444B9.50BEB310
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D152092111-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2>So if I understand this correctly, your =
original=20
comment was not about WS-Addressing at all, =
since WS-Addressing does=20
not place context related information within an address. The other =
question=20
is, whether the concept of the EndpointReference (encapsulation of the =
address=20
and other endpoint instance related information), as defined by =
WS-Addressing,=20
is appropriate for Web Services. Is it right? </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D152092111-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D152092111-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2>From my experience with Web Services, having =
only a=20
transport address of the endpoint is not always enough to be able =
to=20
communicate with the service - I'm not talking about message formats =
here,=20
you have to know them too of course . It is helpful to =
have a=20
mechanism to embed additional properties (like policies) to the =
particular=20
web service instance reference, that, as you said, shouldn't be placed =
inside=20
the original Web Service endpoint address. Such a endpoint reference can =
then be=20
placed into a WSDL describing that particular web service instance =
instead of=20
the transport address of the endpoint. Unfortunately this cannot be =
easily=20
accomplished using WSDL 1.1. This is not about WS-RF, which is going a =
lot of=20
further and is defining concept of resource and association between the=20
resource and the service, which executes in the=20
resource context. I agree, that this is rather a questionable thing =
to do=20
in Web Services environment in general.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D152092111-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D152092111-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2>Jan</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Mark Little=20
[mailto:mark.little@arjuna.com] <BR><B>Sent:</B> Friday, May 28, 2004 =
11:53=20
AM<BR><B>To:</B> Jan Alexander; 'Greg Pavlik'; 'Furniss, =
Peter'<BR><B>Cc:</B>=20
'Green, Alastair J.'; 'ws-caf'<BR><B>Subject:</B> Re: [ws-caf] Mt =
Everest and=20
WS-CF<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>Jan, I hope you didn't think I was suggesting that WS-Addressing =
does=20
place context into the address, but rather commenting =
on 'WS-Addressing=20
is particularly interesting because it is essentially "opaque =
context"' As I=20
said, context shouldn't be within an address.</DIV>
<DIV> </DIV>
<DIV>However, it's a different argument as to whether the use of=20
ReferenceProperties to create the equivalent of an IOR=20
(ReferenceProperties=3D=3DObject Key) is a good thing. If you read the =
recent=20
paper on WSJ comparing WS-Context with WS-RF I think you'll see the =
argument=20
against in a much stronger way than I have time to write in this =
email.</DIV>
<DIV> </DIV>
<DIV>Mark.</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3Dalex@systinet.com href=3D"mailto:alex@systinet.com";>Jan =
Alexander</A>=20
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dmark.little@arjuna.com=20
href=3D"mailto:mark.little@arjuna.com";>'Mark Little'</A> ; <A=20
title=3Dgreg.pavlik@oracle.com =
href=3D"mailto:greg.pavlik@oracle.com";>'Greg=20
Pavlik'</A> ; <A title=3DPeter.Furniss@choreology.com=20
href=3D"mailto:Peter.Furniss@choreology.com";>'Furniss, Peter'</A> =
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
title=3DAlastair.Green@choreology.com=20
href=3D"mailto:Alastair.Green@choreology.com";>'Green, Alastair =
J.'</A> ; <A=20
title=3Dws-caf@lists.oasis-open.org=20
href=3D"mailto:ws-caf@lists.oasis-open.org";>'ws-caf'</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, May 28, 2004 =
10:42=20
AM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [ws-caf] Mt =
Everest and=20
WS-CF</DIV>
<DIV><BR></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D913533109-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2>WS-Addressing does not place context into =
the address.=20
What it does, it uses set of SOAP headers to identify execution =
context for=20
the particular "Endpoint" by introducing EndpointReference =
abstraction. The=20
EndpointReference itself additionally contains logical address of =
the=20
endpoint and a set of policies, which are relevant to the use of =
that=20
EndpointReference. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D913533109-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D913533109-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2>It is important to distinguish between a =
service=20
address and a service instance identifier. The first is similar to =
for=20
instance IP addresses and port number, the second to CORBA IOR. I =
don't see=20
anything against "SOA principles" in the EndpointReference concept =
as it is=20
not just a service address. I agree that it would be useful to use=20
WS-Context for mapping EndpointReferenceProperties into =
SOAP headers as=20
they identify the execution context of the =
endpoint.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D913533109-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D913533109-28052004><FONT =
face=3DTahoma=20
color=3D#0000ff size=3D2>Jan</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Mark Little=20
[mailto:mark.little@arjuna.com] <BR><B>Sent:</B> Friday, May 28, =
2004=20
11:25 AM<BR><B>To:</B> Greg Pavlik; Furniss, Peter<BR><B>Cc:</B> =
Green,=20
Alastair J.; ws-caf<BR><B>Subject:</B> Re: [ws-caf] Mt Everest and =
WS-CF<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>+1.</DIV>
<DIV> </DIV>
<DIV>I'd also like to suggest that context embedded in an=20
address isn't really the right way to go. Despite the fact =
that we=20
(Jim, Savas, myself and others) have suggested that =
ReferenceProperties=20
*could* use WS-Context, that doesn't necessarily mean that it's =
the best=20
way of tackling the problem. Suggesting that context within an =
address is=20
the right model is ignoring SOA principles.</DIV>
<DIV> </DIV>
<DIV>Mark.</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3Dgreg.pavlik@oracle.com=20
href=3D"mailto:greg.pavlik@oracle.com";>Greg Pavlik</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
title=3DPeter.Furniss@choreology.com=20
href=3D"mailto:Peter.Furniss@choreology.com";>Furniss, Peter</A> =
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
title=3DAlastair.Green@choreology.com=20
href=3D"mailto:Alastair.Green@choreology.com";>Green, Alastair =
J.</A> ; <A=20
title=3Dmark.little@arjuna.com =
href=3D"mailto:mark.little@arjuna.com";>Mark=20
Little</A> ; <A title=3Dws-caf@lists.oasis-open.org=20
href=3D"mailto:ws-caf@lists.oasis-open.org";>ws-caf</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, May 27, =
2004 3:56=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [ws-caf] Mt =
Everest=20
and WS-CF</DIV>
<DIV><BR></DIV><BR><BR>Furniss, Peter wrote:<BR>
<BLOCKQUOTE=20
=
cite=3Dmid221369570DEDF346AE42821041345E895A24C2@imap.choreology.com=20
type=3D"cite"><PRE wrap=3D"">Greg,
<snip the earlier part of the alastair .. thread>
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">A further comment on =
the IBM/MS product specs: there are in=20
fact three=20
contextualization mechanisms: one in WS-Coordination, one in=20
WS-ReliableMessaging, and one in WS-Addressing. Putting aside=20
WS-Addressing for a moment since it introduces a new model to the web=20
services environment that I don't want to argue about here, let me=20
observe that there is no fundamental distinction between the=20
lifecycle=20
control interface in WS-Coordination and WS-ReliableMessaging. Why=20
shouldn't these be based on a common model? Wouldn't that in fact be=20
simpler and less error prone? From there, it seems a small step to=20
imagine the reliability and coordination/transaction contexts=20
having a=20
common root. I submit that this is in fact a flaw, not a strength, of=20
the specification set; they they are unnecessarily complex due to the=20
failure to deal with common constructs, idioms and patterns as, well,=20
things-in-common.
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
Well the WS-Coordination and WS-RM both have equivalent of "begin".
WS-RM doesn't always use it,=20
and when it is used, it is asked of the eventual receiver. The
termination sequences are different, since WS-RM is just stopping, and
WS-Coordination will have delegated to a transaction protocol.=20
As contextualization, it is true that a message carrying the relevant
headers is "in the context" of those headers, and subject to their
implications. But the same is true of more or less any header - that's
what they're for. WS-Addressing is particularly interesting because it
is essentially "opaque context" - the reference properties don't need to
contain any kind of identifier in the ws-context sense at all (it might
tell the receiver which database to look in, but since only the receiver
knows what they meant, that's fine - it's just a piece of syntactic
partitioning of the address)</PRE></BLOCKQUOTE>Is it fine? What if it=20
happens to conflict with another header since there are no =
restrictions?=20
I'd like to suggest that WS-Addressing would benefit from a =
container=20
and that this is generally a problem for contextualization based =
solely=20
on headers.<BR><BR>
<BLOCKQUOTE=20
=
cite=3Dmid221369570DEDF346AE42821041345E895A24C2@imap.choreology.com=20
type=3D"cite"><PRE wrap=3D"">. The other two would have an =
identifier but
that's the only thing they share, I think.
Peter
=
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></=
BODY></HTML>
------=_NextPart_000_0046_01C444B9.50BEB310--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]