[AXIS] Pictures of Handlers, Actors

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

 Hello. 8-)
 As promised in yesterday's chat I drew three pictures of how I
perceive chaining etc. and Actors. My views should be quite close to
the general opinion, at least the chat suggested this.

 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:

 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 think it should stop
at the Pivot handler with no post-processing but I've added an output
chain anyway. 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

RE: [AXIS] Pictures of Handlers, Actors

[James Snell <js...@lemoorenet.com>]

Jacek,

Thanks for putting these together, they look good although I'll had a few
modification requests.  I post these in a little while.

- James

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Wednesday, January 17, 2001 3:01 AM
> To: soap-dev@xml.apache.org
> Subject: [AXIS] Pictures of Handlers, Actors
>
>
>  Hello. 8-)
>  As promised in yesterday's chat I drew three pictures of how I
> perceive chaining etc. and Actors. My views should be quite close to
> the general opinion, at least the chat suggested this.
>
>  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:
>
>  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
> hanlers, and it is returned to the transport layer to do whatever it
> will.
>
>  Service no.2 is just the one-way equivalent. I think it should stop
> at the Pivot handler with no post-processing but I've added an output
> chain anyway. 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
>
>
>
>