Resend: [ws-caf] specifications - referencing and otherwise

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Title: Message

The oasis email archiver mangles messages that have "From " as the first characters on a line, so I am resending this for the record.

 

-----Original Message-----
  -Fro   m: Furniss, Peter
Sent: 06 July 2004 10:31
To: ws-caf@lists.oasis-open.org
Subject: [ws-caf] specifications - referencing and otherwise

In yesterday's discussion, it seemed that there may be different views about what is meant by "referencing specification", and since, I think, I first put the term into ws-caf circles (issue 64), and I use the term very frequently in discussions on this list, I thought I'd expand on what I understand by it.  I believe the term is used in 0.3 in the same sense, though I haven't checked explicitly.

 

One can distinguish various sources of definition for the behaviour of a particular web service and its client using ws-context:

 

a) general web-service specification - soap, xml, mime-types etc

b) the particular application protocol - whose data is carried in the soap body

c) the ws-context specification itself

d) other specification building on ws-context that defines the meaning and implication of the context header

e) specification of other soap headers

f) implementation choices

 

One could chop things differently, and certainly name things differently, but the key characteristics are:

 

a-e all have to be understood by both parties; f) is defined as being of concern only to one side. If a-e offer a choice to one implementation on what is sent, then a-e must also demand that the other side can accept and handle anything arising fr-om that choice. (if a-e do not do this, they are broken as interoperable specifications)

 

The use of the term "specification" is not intended to imply any special level of formalisation - other than the critical feature that both sides must understand and implement the same (or corresponding) thing.

 

a) is the substrate on which we are working, so can be left out of further discussion (though obviously affects reality)

 

the distinction between b) and (c+d+e) is inherent in the soap body + headers pattern. In one sense, the totality of the message is part of the application protocol. However, the concept of a header implies a piece of specified protocol (messages and behaviour) that has been factored out of the application (usually on the basis that it is common to many application protocols).

 

c+d together define the semantics of a particular SOAP header that uses ws-context. The specification d) may or may not add extension elements to the base ws-context <context> element. It may or may not imply the existence of other web services (like a coordinator). d) may itself be compound or layered (as with the input versions of  ws-cf + ws-txm lra, say).

 

F-r-o-m the perspective of the ws-context document, "referencing specification" was meant to refer to d) - i.e. that which must be mutually understood by both parties concerning the ws-context header as a whole but which is distinct from the particular application protocol. The same thing is also sometimes called a "higher specification"

 

It is also this "d)" that is identified by the context type URI, in my understanding.

 

Since, in a sense, the whole SOAP envelope is an application protocol message (e.g. an update request with a ws-txm acid context is not seeking the same behaviour as an update request with no transactionish context), it can be argued that the d) : b) boundary is ill-defined. A WSDL definition is the normal way of stating the application protocol's interface, but if the WSDL binding demands that particular headers carry particular values, then the header:body distinction becomes perhaps insignificant. However, insofar as it made sense to factor out the header in the first place, a distinction can usefully be made. Using a header, rather than carrying the field in the application's "own" protocol presumably picks up some semantics that consequently don't need to be spelled out in the application protocol's specification (which may be no more than some human-language text explaining the methods and parameters, or they may even be assumed to be "obvious" f-rom their names - though that would be rather under-specified)

 

The "referencing specification" is thus a placeholder term for everything that has to be known to both sides, isn't in the ws-context document and is intended/implied by the use of the context header in a particular case.

 

 

I think it would be appropriate to have an explanation of a "specification model" of this nature in the text. This would be essentially editorial (it explains the text, without changing the requirements on implemenations) but we need to be sure of consensus

 

So, if the above is contrary to your perception, please correct or refute.

 

 

Peter

 

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email: peter.furniss@choreology.com
phone: +44 870 739 0066
mobile: +44 7951 536168