[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
=20 ------_=_NextPart_001_01C4633B.F41A9105 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>In = yesterday's=20 discussion, it seemed that there may be different views about what is = meant by=20 "referencing specification", and since, I think, I first put the term = into=20 ws-caf circles (issue 64), and I use the term very frequently in = discussions on=20 this list, I thought I'd expand on what I understand by it. I = believe=20 the term is used in 0.3 in the same sense, though I haven't checked=20 explicitly.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>One = can=20 distinguish various sources of definition for the behaviour of a = particular=20 web service and its client using ws-context:</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>a) = general=20 web-service specification - soap, xml, mime-types = etc</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>b) the = particular=20 application protocol - whose data is carried in the soap=20 body</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>c) the = ws-context=20 specification itself</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>d) = other=20 specification building on ws-context that defines the meaning and = implication of=20 the context header</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>e) = specification of=20 other soap headers</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>f) = implementation=20 choices</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>One = could chop=20 things differently, and certainly name things differently, but the key=20 characteristics are:</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>a-e = all have to be=20 understood by both parties; f) is defined as being of concern only to = one side.=20 If a-e offer a choice to one implementation on what is sent, then a-e = must also=20 demand that the other side can accept and handle anything arising from = that=20 choice. (if a-e do not do this, they are broken as interoperable=20 specifications)</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>The = use of the term=20 "specification" is not intended to imply any special level of = formalisation -=20 other than the critical feature that both sides must understand and = implement=20 the same (or corresponding) thing. </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>a) is = the substrate=20 on which we are working, so can be left out of further discussion = (though=20 obviously affects reality)</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>the = distinction=20 between b) and (c+d+e) is inherent in the soap body + headers pattern. = In one=20 sense, the totality of the message is part of the application protocol. = However,=20 the concept of a header implies a piece of specified protocol (messages = and=20 behaviour) that has been factored out of the application (usually on the = basis=20 that it is common to many application protocols).</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>c+d = together define=20 the semantics of a particular SOAP header that uses ws-context. The=20 specification d) may or may not add extension elements to the base = ws-context=20 <context> element. It may or may not imply the existence of other = web=20 services (like a coordinator). d) may itself be compound or layered (as = with the=20 input versions of ws-cf + ws-txm lra, say).</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT size=3D+0><SPAN = class=3D665422708-06072004></SPAN></FONT><FONT face=3DArial=20 size=3D2><SPAN class=3D665422708-06072004>From the perspective of the = ws-context=20 document, "referencing specification" was meant to refer to d) - i.e. = that which=20 must be mutually understood by both parties concerning the ws-context = header as=20 a whole but which is distinct from the particular application protocol. = The same=20 thing is also sometimes called a "higher = specification"</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>It is = also this "d)"=20 that is identified by the context type URI, in my=20 understanding.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>Since, = in a sense,=20 the whole SOAP envelope is an application protocol message (e.g. an = update=20 request with a ws-txm acid context is not seeking the same behaviour as = an=20 update request with no transactionish context), it can be argued that = the d) :=20 b) boundary is ill-defined. A WSDL definition is the normal way of = stating the=20 application protocol's interface, but if the WSDL binding demands = that=20 particular headers carry particular values, then the header:body = distinction=20 becomes perhaps insignificant. However, insofar as it made sense to = factor out=20 the header in the first place, a distinction can usefully be=20 made. Using a header, rather than carrying the field in the = application's=20 "own" protocol presumably picks up some semantics that consequently = don't need=20 to be spelled out in the application protocol's specification (which may = be no=20 more than some human-language text explaining the methods and = parameters, or=20 they may even be assumed to be "obvious" from their names - though that = would be=20 rather under-specified)</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>The = "referencing=20 specification" is thus a placeholder term for everything that has = to be=20 known to both sides, isn't in the ws-context document and is=20 intended/implied by the use of the context header in a particular=20 case.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>I = think it would be=20 appropriate to have an explanation of a "specification model" of this = nature in=20 the text. This would be essentially editorial (it explains the text, = without=20 changing the requirements on implemenations) but we need to be sure of=20 consensus</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D665422708-06072004>So, if = the above is=20 contrary to your perception, please correct or = refute.</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D665422708-06072004></SPAN></FONT><FONT=20 face=3DArial size=3D2><SPAN = class=3D665422708-06072004></SPAN></FONT> </DIV> <DIV align=3Dleft><FONT face=3DArial size=3D2>Peter</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV align=3Dleft><FONT face=3DArial=20 size=3D2>------------------------------------------<BR>Peter = Furniss<BR>Chief=20 Scientist, Choreology Ltd<BR>web: <A=20 href=3D"http://www.choreology.com/";>http://www.choreology.com</A><BR>emai= l: <A=20 href=3D"mailto:peter.furniss@choreology.com";>peter.furniss@choreology.com= </A><BR>phone:=20 +44 870 739 0066<BR>mobile: +44 7951 536168<BR></FONT></DIV> <DIV> </DIV></BODY></HTML> ------_=_NextPart_001_01C4633B.F41A9105--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]