Actor and intermediaries

[Paul Kulchenko <pa...@yahoo.com>]

I'm back to this topic again.
Recently I went through log of IRC chat on ApacheSOAP and need to say
it was very interesting and close to what I'm doing now. Hope I'll be
able to join you on next chat, but let me express my thoughts now.

[4.2.2]
A SOAP message travels from the originator to the ultimate
destination, potentially by passing through a set of SOAP
intermediaries along the message path. A SOAP intermediary is an
application that is capable of both receiving and forwarding SOAP
messages. Both intermediaries as well as the ultimate destination are
identified by a URI.
Not all parts of a SOAP message may be intended for the ultimate
destination of the SOAP message but, instead, may be intended for one
or more of the intermediaries on the message path. The role of a
recipient of a header element is similar to that of accepting a
contract in that it cannot be extended beyond the recipient. That is,
a recipient receiving a header element MUST NOT forward that header
element to the next application in the SOAP message path. The
recipient MAY insert a similar header element but in that case, the
contract is between that application and the recipient of that header
element.
The SOAP actor global attribute can be used to indicate the recipient
of a header element. The value of the SOAP actor attribute is a URI.
The special URI "http://schemas.xmlsoap.org/soap/actor/next"
indicates that the header element is intended for the very first SOAP
application that processes the message. This is similar to the
hop-by-hop scope model represented by the Connection header field in
HTTP.
Omitting the SOAP actor attribute indicates that the recipient is the
ultimate destination of the SOAP message.
This attribute MUST appear in the SOAP message instance in order to
be effective (see section 3 and 4.2.1).

[4.4]
The faultactor element is intended to provide information about who
caused the fault to happen within the message path (see section 2).
It is similar to the SOAP actor attribute (see section 4.2.2) but
instead of indicating the destination of the header entry, it
indicates the source of the fault. The value of the faultactor
attribute is a URI identifying the source. Applications that do not
act as the ultimate destination of the SOAP message MUST include the
faultactor element in a SOAP Fault element. The ultimate destination
of a message MAY use the faultactor element to indicate explicitly
that it generated the fault (see also the detail element below). 

Let's consider:

message
headerA Actor=A     Actor=Next x
headerB Actor=B     Actor=B    Actor=D ?
headerC Actor=C     Actor=C    Actor=C x
headerD Actor=Next  ?
headerE o           o          o       o

        Source      A          B       C (Destination)

Route is based on two variants: 
  1. source knows route, and 
  2. route is defined dynamically

1. If route is static where should information be stored about it?
Specific header? In that case it shouldn't have Actor, because it
needs to
be available to all recipients (if intermediaries can use header
WITHOUT
Actor attribute. Can they?) or it should have Actor and all hops
stored inside as stack (array) and intermediary will take first, send
message there and change Actor on this header accordingly (question
is: could intermediary 
insert header with the SAME name, but different ACTOR and content.
Spec 
says "recipient may insert SIMILAR header....". What does this
'similar' 
mean?). Last variant I can see: each hop will be coded with different

header with different Actor and next intermediary will take first in 
document order and send it there. What will you choose?

2. Route is defined dynamically. 
No questions. Based on information in header/body intermediary
defines 
where message should be routed. 

Is combination of these two possible?

Now back to scheme.

[A] gets message and process it. Header with Actor=A is processed and

changed to Actor=Next.
Can HeaderE be processed? It doesn't have Actor, but spec doesn't say

that header CANNOT be processed by nonrecipient. So it's possible.
Related question, should it be deleted if processed by nonrecipient?
Spec says nothing about it.
What to do with HeaderD if [A] doesn't understand it? It should be
removed 
from message nevertheless.
If [A] for some reasons wants to generate fault it should include
faultactor. faultactor is required only for intermediaries, however
if 
[A] failed to process message it doesn't know is it intermediary for 
this message or not. So, faultactor SHOULD BE generated in any case.
If [A] gets fault message from [B] it can pass it to source without
parsing at all, right? BTW, source is waiting for respond (in case of
HTTP).

[B] processes HeaderB and changes Actor to 'D', process HeaderA and
pass message to Destination.

[C] gets HeaderE (no Actor), HeaderC (Actor=C) and HeaderB (Actor=D),
process HeaderE and HeaderC and ignore HeaderB. Presence of HeaderB
is
not error, becase if it can be ignored by Intermediaries why it
cannot
be ignored by destination. Even if it has mustUnderstand, we ignore
it,
because it's not for us.
 
Effect: intermediary CANNOT add NEW header, only replace processed
(but
not neccessarily).

Trickiest part is to define am I intermediary or not. Spec says about
being CAPABLE to receive and forward messages, but service can be 
intermediary for some and destination for other messages. 
Intermediary can be defined by message context (as it should be IMHO)

and by configuration. Service description can play in both cases.

Small comment to chat log. I don't see reason why SOAPAction cannot
be used for SMTP/POP3 messages also.

Last question. I'm accepting messages by POP3 and sent it back (to
Reply-To) with SMTP. Am I intermediary or destination? It depends
on message, right? If it's one-way message -- I'm intermediary. If
it's two-way message -- I'm destination. 

Thoughts? Comments? 

Best wishes, Paul.


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/