OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-caf] Context query


In thinking about this it may help to distinguish:
	a) what a user might want to do
	b) what a product might do to deliver that
	c) what standards must specify so the product can work in
heterogeneous environment

I think we can all see circumstances in a soap-based environment where
entities receiving
certain soap headers pass them on in outbound consequential processing.
Marking all the
activity arising from a particular initial event (travel request,
customer enquiry, purchase order,
transaction initiation) sounds useful. But what is "consequential"
processing - it will
clearly depend on what the intermediate [1] does - a merchant system
might consider all the
actions to deliver, invoice, update customer records as "consequential"
in this sense on 
the purchase order but not stock replenishment if the order triggered
that. (c.f. 'nested'
top-level transactions)  And it will generally need to know who to pass
the header to -
a header identifying the initiating internal user may need to go
everywhere inside the 
company but not outside.  And there may be multiple answers to this -
the customer may want
a header carrying his request identification to be passed back on
delivery note, invoice etc
while the merchant wants to pass only his identification of the customer
deeper into his
systems. The full interpretation of a header may not be known to the 
process that does the passing on - only that it is to be passed on
appropriately.

Software to do that needs only to answer the question, in a particular
case "which of the headers received on the inbound request that was the
immediate cause of this
particular outbound request should be copied to it without
modification". It will need to
establish some sort of local concept of "immediate cause", but that
could easily be
process thread in the first instance (or business process thread to be a
bit more flexible).
It might be an explicit option available to the using process to break
that immediate cause
chain (c.f. deployment descriptor values of none or new transaction) in
the processing, or
make it implicit on some existing structure (e.g. inner scopes share,
separate processes don't).
But that only identifies the candidate headers - there is almost
certainly a need to allow 
different sets of headers to be propagated in different directions.

At the standard level, defining a single characteristic of headers that
marks them as
appropriate for that sort of passing on doesn't seem right. There would
need to be a
set of markers, then a system owned by Acme Inc, could declare (for
example, and leaping to solution unwisely)
	any header with attribute
forward="http://www.acme.com/soap/customer-forwarding-header"; received
on a purchase order will be copied on any resulting invoice and delivery
note. It will not necessarily be copied on related queries.

One would expect implementations to be flexible in what values they can
put in such an attribute, and what passing on rules they apply to
received one.

Making the fact of derivation from context be the marker is to
broad-brush. It would mean there was just one marker for all purposes.

For those who disagree, can I suggest attempting to define, in half a
page of specification text exactly what behaviour is expected and
required of the passing on system. Something that could be the basis of
a conformance assertion and demonstrable in an out-of-the-box interop.
If it is only "implementations MAY pass on these headers on SOME other
invocations to SOME systems", then it perhaps doesn't belong in the
spec.

few more comments interspersed below

Peter



> -----Original Message-----
> From: nknrc1 [mailto:Kevin.Conner@arjuna.com] 
> Sent: 17 June 2005 06:30
> To: Green, Alastair J.; WS-CAF
> Subject: RE: [ws-caf] Context query
> 
> 
> >After quite a bit of thought, I've come to the conclusion that the 
> >ability to know that this is a "base context" is not a 
> useful feature.
> 
> Then I hope I can convince you otherwise :-). I will attempt 
> to answer your 
> points before giving a scenario that I hope will explain my position.
> 
> >What can a processor do that understands it has received a 
> context, but 
> >does not know the type of the context?
> 
> It can simply pass it through.
> 
> >(Parenthetically: if the question arises: "how do I 
> understand the type 
> >of the context?", then surely it very simple for a header 
> processor to 
> >look for a header of type [namespace etc] X, rather than 
> look for one 
> >of type WSCTX, and then examine it to see whether it is X? 
> It must be 
> >able to discriminate X from Y to do anything useful, anyway.)
> 
> It is not always a requirement to understand nor identify the 
> type of a 
> context in order for a processor to choose to pass it 
> through, it may be 
> sufficient to identify it as a context.

or "it is not a requirement to understand the purpose of a header
other than to identify it as to be considered for pass through"

i.e. the discussion is about whether "header is a context" is THE 
flag that says "pass through to 'consequential' messsages", so 
we should think of the pass-throughness, not the contextness.

> >A receiver of a context can either process it (which requires 
> >understanding its type and its nature and its specific 
> content) or it 
> >can forward the context to someone else who does understand 
> it (which, 
> >I will argue cannot meaningfully occur without processing it, with 
> >understanding of its type, and nature, if not content).
> 
> Whereas I believe that forwarding of the context can 
> meaningfully occur 
> without processing it.
> 
> >In order to forward it, the forwarder must understand to 
> whom it must 
> >be sent, and in the headers of which messages.
> >
> >If a message is sent out by an application then the 
> forwarding entity 
> >could, by interception, add the context silently to the application 
> >message. In order to understand which application messages should be 
> >"contexted" the forwarder would have to have an 
> application-aware rules 
> >processor. This rules processor would examine outbound messages in 
> >order to establish type, instance and addressing information. The 
> >inbound equivalent can be imagined (it's the start of this 
> hypothetical 
> >scenario).
> 
> The forwarder would have to have knowledge but this need not 
> be application 
> specific.  A forwarder could decide to pass all contexts, it 
> could base the 
> decision on the originator/receiver or it could be based on 
> other, non 
> application specific, criteria.
> 
> >However, at this point we have made a nonsense of the proposed 
> >approach. The rules processor understands application 
> messages: their 
> >schema, the import of their instance values, the catalogue 
> of all such 
> >messages and of them which ones are contextable, which addresses are 
> >relevant, and, from all of that application-specific 
> information, which 
> >messages should actually be contexted. Its attempt to deal with the 
> >context as something opaque has turned out to be a sham. It has in 
> >fact, processed it: not handed it off.
> 
> In your scenario yes, but not in mine.
> 
> >To ask such a processor to know the nature and type of a context 
> >(recognize that a header is a context of a specific type) is to ask 
> >very little extra or new of it: it is only a new facet of a 
> >multi-faceted application awareness.
> 
> I agree but to change this, even if it is a small change, may 
> be an expensive 
> operation for other reasons.
> 
> >If a forwarder is completely dumb (gets context on an 
> inbound message, 
> >and outputs on all outbound messages) then it could, in 
> principle, be 
> >unaware of the nature of the contexts.
> 
> >But it would be trivial to create a forwarder that had a small 
> >catalogue of known context types, and which was therefore able to be 
> >not completely dumb. It seems unlikely that there is any 
> gain in having 
> >a dumb forwarder. And one of even minimal intelligence ... requires 
> >type information at the very least.
> 
> One with minimal intelligence need have no knowledge of the 
> context type, in 
> fact this may be desirable to reduce coupling in the system.
> 
> >(The completely dumb forwarder is so primitive as to be of dubious 
> >value under any circumstances, in any event)
> 
> Unfortunately those who design systems do not always agree 
> with this :-)
>
> >Anyway you cut it: if you want to handle a context then you need to 
> >know what it is, why it is and for whom it is.
> 
> >P.S. Supplementary to this: I believe that any attempt to 
> state "must 
> >propagate" is meaningless. Propagate to whom? On what successor 
> >messages? How can I tell that the instruction has been received or 
> >obeyed? How is it relevant to me and who am I to issue such 
> >instructions?
> 
> So do I and I have never argued for that.  My point is that 
> neither you nor I 
> are in a position to understand the specific requirements 
> placed on a system, 
> this is a question for the Architect.  The decision to pass a 
> context through 
> their system without understanding the type is one that only 
> they can make.  
> It is an option that, IMHO, we do not have the right to prevent.
> 
> By way of an example consider the following.
> 
> There are three systems within an organization, X, Y and Z.  
> X and Z share 
> knowledge of a context type, C1, whereas Y has no reason to 
> process it.  X 
> creates context C1 and makes a call(s) on Y (including C1), 
> which in turn 
> makes a call(s) on Z (passing C1).
> 
> In your argument it is necessary for Y to identify C1 as such 
> before passing 
> it through.  This creates a dependency which, IMHO, need not exist.
> 
> Now suppose that X and Z decide to use context C2 instead of 
> C1.  This would 
> necessitate a change to Y, a system that does nothing with C2 
> except pass it 
> through.  There are a number of reasons I can think of why 
> this may be 
> undesirable
> 
>  - Y may be controlled by a different team within the 
> organization and,
>    therefore, change may not be possible (or easy).
>  - Y may serve more systems than X and Z and therefore cannot 
> easily be taken
>    down to make the change.
>  - The organization may have a policy whereby any changes to 
> Y, however
>    insignificant, must go through a lengthy QA process before 
> being released.
> 
> These are all barriers to a simple change.
> 
> The Architect may have decided that, in order to mitigate the 
> impact of 
> changes in X and Z (or any other systems that it may 
> support), it is safe and 
> desirable for Y to pass contextual information through without having 
> knowledge of the type.  This would break the dependency Y 
> currently has on the 
> context and reduce the coupling in the system.
> 
> This is an option that only the Architect of the system can 
> make and is one 
> that we currently rule out.  I do not believe we have the 
> right to make such a 
> decision.
> 
>     Kev
> 
> --
> Kevin Conner
> Arjuna Technologies Ltd.
> 
> Kevin Conner
> Arjuna Technologies Ltd.
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]