[AXIS] Pictures of Handlers, Actors (updated)

[Jacek Kopecky <ja...@idoox.com>]

 As per Dug's comments I updated the pictures and here follows the
updated description.
 I just thought that maybe it could be added to the arch doc if
there's no disagreement... What do you think, Steve?

 The updates are: added paragraph talking about Transport and Global
chains, reworded paragraph about one-way service.
 Follows the updated description:


 You can find the pictures at http://www.idoox.com/~jacek/

 Generally: Every arrow indicates a message is passed from somebody to
someone else, the passing is done by the box that contains the link,
not by the handler where the link originates.
 Links leading to the boundary of a box mean the message is returned
to the upper box.
 Actually for the sake of formal correctness the services should be
enclosed in the Axis engine, but this way it seemed clearer to me.

 Please post your comments (or mail them to me), I can change the
pictures easily. I can also make a postscript (or eps) version. The
original version is a .fig from xfig.

 To the first picture - simple services:

 First the picture shows how the message flows through the Transport
and Global chains, then it's routed to one of our services.

 Service no.1 is a usual service implemented on our node. The
service's main handler is a chain container with an input chain, pivot
handler and an output chain. The messages are passed into the chain
container, into the input chain, into the handlers inside the input
chain, then into the pivot point, then into the output chain, its
handlers, and it is returned to the transport layer to do whatever it
will.

 Service no.2 is just the one-way equivalent. I've added an output
chain so that there can be post-processing (no output message needed).
So it's the chainContainer who must know it's one-way (e.g.
OneWayChainContainer extends ChainContainer) and return nothing.

 Service no.3 is an intermediary: it does what it will and the actual
deepmost pivot point is a forwarder (should be added with the
distro), a preprogrammed handler that gets a URI from the
configuration and forwards its messages there, returning the message
that came back.

 The second picture shows how multiple actors can be conbined in one
service. In the main service Chain Container the input chain is an
Actor (it was given an Actor URI from the config when the WSDD was
compiled). This chain may use handlers that are packaged with Axis and
that do mustUnderstand processing and so on.

 The pivot handler of the outermost chain container is in itself a
chain container and the default Actor (empty, non null, Actor URI -
probably handled specially in WSDD), again here the input chain may
contain the handlers that do mustUnderstand etc.

 The main output chain contains a handler that's also been assigned an
Actor URI, but this handler decides it will do all the necessary actor
processing by itself.

 I think that the simple fact that a handler has an Actor URI
associated to it doesn't mean that _this_ handler must do all the
processing required by SOAP Spec. But wait before you go all mad at
me. 8-)
 I decided so because this allows chains (or CCs) to set the inner
handlers' actor URI to the the containing chain's one. This could make
it easy to process mustUnderstand - could be done by a handler at the
end of a chain which would just look for the unprocessed headers meant
for this actor and yell if it found any that must be understood.
 Yes this would put the burden of controlling mustUnderstand on the
administrator, but the WSDD the admin uses would usually come with
this handler chained in so it wouldn't be much of a burden.

 I think that a handler (h, c, cc) contained in an Actor handler COULD
be set to a different actor uri, see the following usecase:

 We want to deploy to one server an application A consisting of an
intermediary I and a service S. 'I' works on both incoming and
returning path. It would be modelled as shown in the third picture:

 'I' is the outermost chain container, it contains 'S' as its pivot
point, 'S' has the default actor URI (empty non null).

 Well, I certainly hope I didn't forget anything important, I should
go get some lunch now.

                            Jacek Kopecky
                               Idoox