[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]