You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Deepal Jayasinghe <de...@opensource.lk> on 2005/04/07 06:07:12 UTC
[Axis2]Proposed Deployment changes
hi all,
I am sorry the previous mail was with wrong subject so I am mailing it again with correct subject.
At the axis2 face to face we did number of changes to axis2 architecture, had to get rid of EngineRegistry and introduce new set of contexts ( www.apache.org/~deepal/axis2f2f/axiscontext.jpg ) considering all those I will have to do some changes to the deployment module too. This mail describes purpose changes to that, so please read that carefully and feels free to give your comments and any suggestions.
Pre-dispatch phase:
This is a system inbuilt phase and which is not going to specify in the server.xml as available phase , and all the handlers in this phase run for each service, i.e they act as global handlers. The main rationality behind introducing phase like this is to provide a way to add global handlers by modules if they want.
How deployment work in new architecture (after face to face summit).
a.. Firstly it loads server.xml and using that creates EngineConfiguration (EC) object which is more like EngineRegistry in old architecture.
b.. Then if there are any module to be deploy then load them one by one
a.. Using its module.xml find the module name and then retrieve corresponding "Module Context" form EC. If this is the first time server gets started up, EC gives an empty Module Context else it gives the previously saved (when server shutdown) Module context corresponding to the module.
b.. While processing the module.xml if there are any handlers with the phase property as "Pre-dispatch" phase then those handlers will be added to the Pre-dispatch phase by DeploymentEngine.
c.. Then using the above Module context and EC, it calls the init() method of module implementation class , from that we give more flexibly for module developers to change the order of handlers in Pre-dispatch phase , add new handlers to that chain, if the module need to deploy a new service to do that and etc..
d.. Next add that module to the EC.
e.. Apply the same procedure for all the module.
c.. Next check to see whether there are any module references in srever.xml if so
a.. Gets the corresponding module (s) form EC and gets handlers of those modules.
b.. And add those handlers to the Post-dispatch phase , (those handlers are not going to be ordered at the deployment time)
d.. Next if there are any service have been deployed (drop in to /service directory) then load them one by one
a.. Read it service.xml and using service name retrieve the corresponding "Service Context" and while processing the xml file fill the Service context.
b.. Next check to see whether there are any module references if so gets handlers corresponds to those.
c.. Next using above handler come from
1.. modules (module references)
2.. service specific handlers (defined in service.xml)
3.. all the handlers in the Post-dispatch phase
Creates three kind of flows (or three kind of execution chains) called
1. In-Flow
2. Out-Flow
3. Fault-Flow
(Let's call those flows as serviceChain and those are also called pre compute handler chains)
a.. Next using above service context invokes init method of the service implementation class.
b.. Finally it will be added the created service to the EC.
· At the run time for each message arrive, it invokes engage(serviceChain , EngineContext) method of each and every module , then the depending on the WS-police module will decide what to do to the serviceChain , 99% of the time it will do nothing. But if we consider about 1% their module developer can use either Phase rule or any other mechanism to change the handler chain.
Thanks
Deepal
Re: [Axis2]Proposed Deployment changes
Posted by Deepal Jayasinghe <de...@opensource.lk>.
see my comments below;
> Hi all:
>
> Comments below.
>
> Eran Chinthaka wrote:
>> On Apr 7, 2005 10:07 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>>>At the axis2 face to face we did number of changes to axis2 architecture,
>>>had to get rid of EngineRegistry and introduce new set of contexts (
>>>www.apache.org/~deepal/axis2f2f/axiscontext.jpg )
>>>considering all those I will have to do some changes to the deployment
>>>module too. This mail describes purpose changes to that, so please read
>>>that
>>>carefully and feels free to give your comments and any suggestions.
>>>
>>>Pre-dispatch phase:
>>>This is a system inbuilt phase and which is not going to specify in the
>>>server.xml as available phase , and all the handlers in this phase run
>>>for
>>>each service, i.e they act as global handlers. The main rationality
>>>behind
>>>introducing phase like this is to provide a way to add global handlers by
>>>modules if they want.
>>
>>
>> If I add something more to this : We wanted somethings to happen
>> before any of the dispatch handlers run. For example, security, WSA,
>> erc., The name is just another name for a phase, but unlike other
>> phases this will be burnt in to the engine. All the other phases are
>> mentioned in the server.xml, or somewhere else, but we thought its
>> better even not to mention pre-dispatch phase in server.xml as if we
>> do that, one can go and delete that entry. So we will just put a
>> comment in the server.xml about this phase, but not an entry.
>>
>> This pre-dispatch phase can be considered as another global scoped
>> phase, but these should before any of the dispatch handlers.
>
> Um - guys? I don't recall talking about a "pre-dispatch" phase at all!
> (?) Where did this come from?
>
> IIRC, we just said that since you need to know the operation before
> engaging operation-specific handlers/modules (which might actually include
> security, etc), it's important to do this level of dispatch as early as
> possible. So if an HTTP handler figures out the operation based on the
> action parameter of the MIME type, then great! That just means the
> operation specific (and by definition the service-specific also) handlers
> can be merged onto the ExecutionChain by the OperationDesc (or whatever
> we're calling the WOM Operation thing) really early on.
>
> We also discussed the idea that our "baked-in" phases might actually all
> be immutable - there would probably only be a handful of these, such as
> "decryption", "reliability", etc., but we'd fix the relative order of
> those phases and make them always available even if nothing is in them,
> regardless of configuration. I don't think we settled on that as a path
> forward, but it came up in the same discussion.
>
>>>Using its module.xml find the module name and then retrieve corresponding
>>>"Module Context" form EC. If this is the first time server gets started
>>>up,
>>>EC gives an empty Module Context else it gives the previously saved (when
>>>server shutdown) Module context corresponding to the module.
>
> But it's up to the Module, not the engine, to figure out how to get the
> context, right? I.e. the Module would be the one doing any recovery from
> DB or disk and filling in the ModuleContext in the appropriate place.
[Deepal]
agreed , I have no objection regrading who is going to do the recovery
process, but I think if it is going to do by module he can do it the way he
wants.
>>>While processing the module.xml if there are any handlers with the phase
>>>property as "Pre-dispatch" phase then those handlers will be added to the
>>>Pre-dispatch phase by DeploymentEngine.
>
> Again, this doesn't match my recollection. I thought that we just had all
> the regular phases, like reliability, security, etc... and the Modules
> just got to deploy anywhere they wanted within those (or define their own,
> which I believe we did decide to move forward with).
>
> Oh, wait - maybe you were thinking of a "pre-dispatch ExecutionChain"? In
> other words, there is a "global" set of Handlers which is going to run by
> default.
[Deepal]
Yup , that is what we are talking about , which is going to be run for all
the services.
You know this chain before dispatch happens (it's the
> handlers+modules in the engine.xml), and that set acts as a template for
> each individual MessageContext's "real" ExecutionChain. So that set would
> likely include, for instance, the WSA handler and the WSS handler - but
> they'd still be deployed in whatever phases they wanted on the chain...
> i.e. no actual phase called "Pre-dispatch" (unless you wanted to custom
> build one, that is :)).
>
> Does this match others' understanding?
>
>> For example, the security module ot WSA module may add some handlers
>> to pre-dispatch phase.
>
> (see above)
>
>>>Then using the above Module context and EC, it calls the init() method of
>>>module implementation class , from that we give more flexibly for module
>>>developers to change the order of handlers in Pre-dispatch phase , add
>>>new
>>>handlers to that chain, if the module need to deploy a new service to do
>>>that and etc..
>>
>> this init() will only be called once and for all, during the life time
>> of the engine. Basically this will called during engine startup or the
>> corresponding module deployment ONLY.
>>
>> If one needs to do some other stuff per message basis within the
>> module, use the engage(...) method.
>
> I'm wondering if Modules might need to do things like send messages
> *after* all the other Modules are started, so that global policies get
> correctly followed even during recovery. If so, we might need some kind
> of work-queue that Modules could add themselves to during startup to get
> pinged again after everyone's ready (i.e. register for the "engine is up!"
> event...).
>
>>>Next add that module to the EC. Apply the same procedure for all the
>>>module. Next check to see whether there are any module references in
>>>srever.xml if
>>>so Gets the corresponding module (s) form EC and gets handlers of those
>>>modules. And add those handlers to the Post-dispatch phase , (those
>>>handlers are not
>>>going to be ordered at the deployment time) Next if there are any service
>>>have been deployed (drop in to /service
>>>directory) then load them one by one Read it service.xml and using
>>>service name retrieve the corresponding
>>>"Service Context" and while processing the xml file fill the Service
>>>context. Next check to see whether there are any module references if so
>>>gets
>>>handlers corresponds to those. Next using above handler come from
>>> modules (module references) service specific handlers (defined in
>>> service.xml) all the handlers in the Post-dispatch phase
>>> Creates three kind of flows (or three kind of execution chains)
>>> called
>>>1. In-Flow
>>>2. Out-Flow
>>>3. Fault-Flow
>>>(Let's call those flows as serviceChain and those are also called pre
>>>compute handler chains)
>
> This was pretty confusing to read... :)
>
> Didn't we talk about needing in/out/infault/outfault chains (potentially
> at each level global/service/operation)? You might want to do something
> very different for outgoing faults than for incoming ones....
>
[Deepal]
Agreed, I remember that we discuss about in-fault-flow and out-fault-flow ,
so in the deployment time all the four kind of chains will be crated.
>>>Next using above service context invokes init method of the service
>>>implementation class. Finally it will be added the created service to the
>>>EC.
>>>
>>>· At the run time for each message arrive, it invokes
>>>engage(serviceChain , EngineContext) method of each and every module ,
>>>then
>>>the depending on the WS-police module will decide what to do to the
>>>serviceChain , 99% of the time it will do nothing. But if we consider
>>>about
>>>1% their module developer can use either Phase rule or any other
>>>mechanism
>>>to change the handler chain.
>
> I thought we decided it was engage(chain, context) where context is simply
> the generic Context interface, so that Modules can be reused easily at all
> levels (it might be OperationContext, ServiceContext, EngineContext....)?
>
> Also, I don't think engage() is getting called as often as you think it
> does. That method gets called when a given Module learns that it should
> be applied to a given chain. So for the
> [engine/service/operation]-specific Modules (ones that are referenced in
> service.xml, say), that happens at init time, once. If Modules are
> *available* in the engine but not actually *engaged*, it's possible to
> engage them at runtime via some Handler which is processing something like
> policy metadata in an EPR.
>
> But engage() shouldn't always be called on every module for every
> message - should it? (it's late here, so maybe I'm misremembering, but I
> didn't think we went there)
>
>> Its like this. When engine asks for an execution chain for a service,
>> or for an operation, the engine configuration will do the phase
>> resolving as usual for all the handlers, irrespective of whether they
>> are in a module or not. But even after that, the engine will call
>> engage method of each every module connected to the current message.
> >
>> Most of the time, we guess this engage method will do nothing. But if
>> one needs to do some handler manipulation even after phase resolving,
>> here is the time.
>
> Hm. See above. (?)
>
> --G
>
>
Deepal
RE: [Axis2]Proposed Deployment changes
Posted by Jaliya Ekanayake <ja...@opensource.lk>.
Hi Glen,
The name "Pre-Dispatch" may not be correct, I will explain how we came up
with the above.
It is basically to find a solution to the following scenario.
Axis engine receives a SOAP message with the encrypted headers. (Even the
WSA headers are encrypted)
Just after the transport handlers the engine is about to execute the handler
chain and need to find out the service.
Engine need to run some decryption handler to even to look at the WSA
headers.
So the solution we thought was to introduce some global phase that will run
in all the cases, yet allow module writers to add some handlers to that
phase as well. E.g. Security module will have an encryption handler that
will go into this "global" phase.
Similarly the WSA handler will be there permanently in that phase. Those are
the two common cases that we could think of at that time.
So when a message passes the dispatch phase the engine will be able to
identify the service even by looking at the WSA Headers or any other way
(which in some case may come encrypted).
The name "pre-dispatch" may need to change if it doesn't go with the
semantics.
Thanks,
Jaliya
-----Original Message-----
From: Glen Daniels [mailto:glen@thoughtcraft.com]
Sent: Thursday, April 07, 2005 1:17 PM
To: axis-dev@ws.apache.org
Subject: Re: [Axis2]Proposed Deployment changes
Hi all:
Comments below.
Eran Chinthaka wrote:
> On Apr 7, 2005 10:07 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>>At the axis2 face to face we did number of changes to axis2 architecture,
>>had to get rid of EngineRegistry and introduce new set of contexts (
>>www.apache.org/~deepal/axis2f2f/axiscontext.jpg )
>>considering all those I will have to do some changes to the deployment
>>module too. This mail describes purpose changes to that, so please read
that
>>carefully and feels free to give your comments and any suggestions.
>>
>>
>>
>>Pre-dispatch phase:
>>
>>This is a system inbuilt phase and which is not going to specify in the
>>server.xml as available phase , and all the handlers in this phase run for
>>each service, i.e they act as global handlers. The main rationality
behind
>>introducing phase like this is to provide a way to add global handlers by
>>modules if they want.
>
>
> If I add something more to this : We wanted somethings to happen
> before any of the dispatch handlers run. For example, security, WSA,
> erc., The name is just another name for a phase, but unlike other
> phases this will be burnt in to the engine. All the other phases are
> mentioned in the server.xml, or somewhere else, but we thought its
> better even not to mention pre-dispatch phase in server.xml as if we
> do that, one can go and delete that entry. So we will just put a
> comment in the server.xml about this phase, but not an entry.
>
> This pre-dispatch phase can be considered as another global scoped
> phase, but these should before any of the dispatch handlers.
Um - guys? I don't recall talking about a "pre-dispatch" phase at all!
(?) Where did this come from?
IIRC, we just said that since you need to know the operation before
engaging operation-specific handlers/modules (which might actually
include security, etc), it's important to do this level of dispatch as
early as possible. So if an HTTP handler figures out the operation
based on the action parameter of the MIME type, then great! That just
means the operation specific (and by definition the service-specific
also) handlers can be merged onto the ExecutionChain by the
OperationDesc (or whatever we're calling the WOM Operation thing) really
early on.
We also discussed the idea that our "baked-in" phases might actually all
be immutable - there would probably only be a handful of these, such as
"decryption", "reliability", etc., but we'd fix the relative order of
those phases and make them always available even if nothing is in them,
regardless of configuration. I don't think we settled on that as a path
forward, but it came up in the same discussion.
>>Using its module.xml find the module name and then retrieve corresponding
>>"Module Context" form EC. If this is the first time server gets started
up,
>>EC gives an empty Module Context else it gives the previously saved (when
>>server shutdown) Module context corresponding to the module.
But it's up to the Module, not the engine, to figure out how to get the
context, right? I.e. the Module would be the one doing any recovery
from DB or disk and filling in the ModuleContext in the appropriate place.
>>While processing the module.xml if there are any handlers with the phase
>>property as "Pre-dispatch" phase then those handlers will be added to the
>>Pre-dispatch phase by DeploymentEngine.
Again, this doesn't match my recollection. I thought that we just had
all the regular phases, like reliability, security, etc... and the
Modules just got to deploy anywhere they wanted within those (or define
their own, which I believe we did decide to move forward with).
Oh, wait - maybe you were thinking of a "pre-dispatch ExecutionChain"?
In other words, there is a "global" set of Handlers which is going to
run by default. You know this chain before dispatch happens (it's the
handlers+modules in the engine.xml), and that set acts as a template for
each individual MessageContext's "real" ExecutionChain. So that set
would likely include, for instance, the WSA handler and the WSS handler
- but they'd still be deployed in whatever phases they wanted on the
chain... i.e. no actual phase called "Pre-dispatch" (unless you wanted
to custom build one, that is :)).
Does this match others' understanding?
> For example, the security module ot WSA module may add some handlers
> to pre-dispatch phase.
(see above)
>>Then using the above Module context and EC, it calls the init() method of
>>module implementation class , from that we give more flexibly for module
>>developers to change the order of handlers in Pre-dispatch phase , add new
>>handlers to that chain, if the module need to deploy a new service to do
>>that and etc..
>
> this init() will only be called once and for all, during the life time
> of the engine. Basically this will called during engine startup or the
> corresponding module deployment ONLY.
>
> If one needs to do some other stuff per message basis within the
> module, use the engage(...) method.
I'm wondering if Modules might need to do things like send messages
*after* all the other Modules are started, so that global policies get
correctly followed even during recovery. If so, we might need some kind
of work-queue that Modules could add themselves to during startup to get
pinged again after everyone's ready (i.e. register for the "engine is
up!" event...).
>>Next add that module to the EC.
>>Apply the same procedure for all the module.
>>Next check to see whether there are any module references in srever.xml if
>>so
>>
>>Gets the corresponding module (s) form EC and gets handlers of those
>>modules.
>>And add those handlers to the Post-dispatch phase , (those handlers are
not
>>going to be ordered at the deployment time)
>>Next if there are any service have been deployed (drop in to /service
>>directory) then load them one by one
>>
>>Read it service.xml and using service name retrieve the corresponding
>>"Service Context" and while processing the xml file fill the Service
>>context.
>>Next check to see whether there are any module references if so gets
>>handlers corresponds to those.
>>Next using above handler come from
>>
>> modules (module references)
>>service specific handlers (defined in service.xml)
>>all the handlers in the Post-dispatch phase
>>
>> Creates three kind of flows (or three kind of execution chains) called
>>
>>1. In-Flow
>>
>>2. Out-Flow
>>
>>3. Fault-Flow
>>
>>(Let's call those flows as serviceChain and those are also called pre
>>compute handler chains)
This was pretty confusing to read... :)
Didn't we talk about needing in/out/infault/outfault chains (potentially
at each level global/service/operation)? You might want to do something
very different for outgoing faults than for incoming ones....
>>Next using above service context invokes init method of the service
>>implementation class.
>> Finally it will be added the created service to the EC.
>>
>>
>>
>>. At the run time for each message arrive, it invokes
>>engage(serviceChain , EngineContext) method of each and every module ,
then
>>the depending on the WS-police module will decide what to do to the
>>serviceChain , 99% of the time it will do nothing. But if we consider
about
>>1% their module developer can use either Phase rule or any other mechanism
>>to change the handler chain.
I thought we decided it was engage(chain, context) where context is
simply the generic Context interface, so that Modules can be reused
easily at all levels (it might be OperationContext, ServiceContext,
EngineContext....)?
Also, I don't think engage() is getting called as often as you think it
does. That method gets called when a given Module learns that it should
be applied to a given chain. So for the
[engine/service/operation]-specific Modules (ones that are referenced in
service.xml, say), that happens at init time, once. If Modules are
*available* in the engine but not actually *engaged*, it's possible to
engage them at runtime via some Handler which is processing something
like policy metadata in an EPR.
But engage() shouldn't always be called on every module for every
message - should it? (it's late here, so maybe I'm misremembering, but
I didn't think we went there)
> Its like this. When engine asks for an execution chain for a service,
> or for an operation, the engine configuration will do the phase
> resolving as usual for all the handlers, irrespective of whether they
> are in a module or not. But even after that, the engine will call
> engage method of each every module connected to the current message.
>
> Most of the time, we guess this engage method will do nothing. But if
> one needs to do some handler manipulation even after phase resolving,
> here is the time.
Hm. See above. (?)
--G
Re: [Axis2]Proposed Deployment changes
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi all:
Comments below.
Eran Chinthaka wrote:
> On Apr 7, 2005 10:07 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>>At the axis2 face to face we did number of changes to axis2 architecture,
>>had to get rid of EngineRegistry and introduce new set of contexts (
>>www.apache.org/~deepal/axis2f2f/axiscontext.jpg )
>>considering all those I will have to do some changes to the deployment
>>module too. This mail describes purpose changes to that, so please read that
>>carefully and feels free to give your comments and any suggestions.
>>
>>
>>
>>Pre-dispatch phase:
>>
>>This is a system inbuilt phase and which is not going to specify in the
>>server.xml as available phase , and all the handlers in this phase run for
>>each service, i.e they act as global handlers. The main rationality behind
>>introducing phase like this is to provide a way to add global handlers by
>>modules if they want.
>
>
> If I add something more to this : We wanted somethings to happen
> before any of the dispatch handlers run. For example, security, WSA,
> erc., The name is just another name for a phase, but unlike other
> phases this will be burnt in to the engine. All the other phases are
> mentioned in the server.xml, or somewhere else, but we thought its
> better even not to mention pre-dispatch phase in server.xml as if we
> do that, one can go and delete that entry. So we will just put a
> comment in the server.xml about this phase, but not an entry.
>
> This pre-dispatch phase can be considered as another global scoped
> phase, but these should before any of the dispatch handlers.
Um - guys? I don't recall talking about a "pre-dispatch" phase at all!
(?) Where did this come from?
IIRC, we just said that since you need to know the operation before
engaging operation-specific handlers/modules (which might actually
include security, etc), it's important to do this level of dispatch as
early as possible. So if an HTTP handler figures out the operation
based on the action parameter of the MIME type, then great! That just
means the operation specific (and by definition the service-specific
also) handlers can be merged onto the ExecutionChain by the
OperationDesc (or whatever we're calling the WOM Operation thing) really
early on.
We also discussed the idea that our "baked-in" phases might actually all
be immutable - there would probably only be a handful of these, such as
"decryption", "reliability", etc., but we'd fix the relative order of
those phases and make them always available even if nothing is in them,
regardless of configuration. I don't think we settled on that as a path
forward, but it came up in the same discussion.
>>Using its module.xml find the module name and then retrieve corresponding
>>"Module Context" form EC. If this is the first time server gets started up,
>>EC gives an empty Module Context else it gives the previously saved (when
>>server shutdown) Module context corresponding to the module.
But it's up to the Module, not the engine, to figure out how to get the
context, right? I.e. the Module would be the one doing any recovery
from DB or disk and filling in the ModuleContext in the appropriate place.
>>While processing the module.xml if there are any handlers with the phase
>>property as "Pre-dispatch" phase then those handlers will be added to the
>>Pre-dispatch phase by DeploymentEngine.
Again, this doesn't match my recollection. I thought that we just had
all the regular phases, like reliability, security, etc... and the
Modules just got to deploy anywhere they wanted within those (or define
their own, which I believe we did decide to move forward with).
Oh, wait - maybe you were thinking of a "pre-dispatch ExecutionChain"?
In other words, there is a "global" set of Handlers which is going to
run by default. You know this chain before dispatch happens (it's the
handlers+modules in the engine.xml), and that set acts as a template for
each individual MessageContext's "real" ExecutionChain. So that set
would likely include, for instance, the WSA handler and the WSS handler
- but they'd still be deployed in whatever phases they wanted on the
chain... i.e. no actual phase called "Pre-dispatch" (unless you wanted
to custom build one, that is :)).
Does this match others' understanding?
> For example, the security module ot WSA module may add some handlers
> to pre-dispatch phase.
(see above)
>>Then using the above Module context and EC, it calls the init() method of
>>module implementation class , from that we give more flexibly for module
>>developers to change the order of handlers in Pre-dispatch phase , add new
>>handlers to that chain, if the module need to deploy a new service to do
>>that and etc..
>
> this init() will only be called once and for all, during the life time
> of the engine. Basically this will called during engine startup or the
> corresponding module deployment ONLY.
>
> If one needs to do some other stuff per message basis within the
> module, use the engage(...) method.
I'm wondering if Modules might need to do things like send messages
*after* all the other Modules are started, so that global policies get
correctly followed even during recovery. If so, we might need some kind
of work-queue that Modules could add themselves to during startup to get
pinged again after everyone's ready (i.e. register for the "engine is
up!" event...).
>>Next add that module to the EC.
>>Apply the same procedure for all the module.
>>Next check to see whether there are any module references in srever.xml if
>>so
>>
>>Gets the corresponding module (s) form EC and gets handlers of those
>>modules.
>>And add those handlers to the Post-dispatch phase , (those handlers are not
>>going to be ordered at the deployment time)
>>Next if there are any service have been deployed (drop in to /service
>>directory) then load them one by one
>>
>>Read it service.xml and using service name retrieve the corresponding
>>"Service Context" and while processing the xml file fill the Service
>>context.
>>Next check to see whether there are any module references if so gets
>>handlers corresponds to those.
>>Next using above handler come from
>>
>> modules (module references)
>>service specific handlers (defined in service.xml)
>>all the handlers in the Post-dispatch phase
>>
>> Creates three kind of flows (or three kind of execution chains) called
>>
>>1. In-Flow
>>
>>2. Out-Flow
>>
>>3. Fault-Flow
>>
>>(Let's call those flows as serviceChain and those are also called pre
>>compute handler chains)
This was pretty confusing to read... :)
Didn't we talk about needing in/out/infault/outfault chains (potentially
at each level global/service/operation)? You might want to do something
very different for outgoing faults than for incoming ones....
>>Next using above service context invokes init method of the service
>>implementation class.
>> Finally it will be added the created service to the EC.
>>
>>
>>
>>· At the run time for each message arrive, it invokes
>>engage(serviceChain , EngineContext) method of each and every module , then
>>the depending on the WS-police module will decide what to do to the
>>serviceChain , 99% of the time it will do nothing. But if we consider about
>>1% their module developer can use either Phase rule or any other mechanism
>>to change the handler chain.
I thought we decided it was engage(chain, context) where context is
simply the generic Context interface, so that Modules can be reused
easily at all levels (it might be OperationContext, ServiceContext,
EngineContext....)?
Also, I don't think engage() is getting called as often as you think it
does. That method gets called when a given Module learns that it should
be applied to a given chain. So for the
[engine/service/operation]-specific Modules (ones that are referenced in
service.xml, say), that happens at init time, once. If Modules are
*available* in the engine but not actually *engaged*, it's possible to
engage them at runtime via some Handler which is processing something
like policy metadata in an EPR.
But engage() shouldn't always be called on every module for every
message - should it? (it's late here, so maybe I'm misremembering, but
I didn't think we went there)
> Its like this. When engine asks for an execution chain for a service,
> or for an operation, the engine configuration will do the phase
> resolving as usual for all the handlers, irrespective of whether they
> are in a module or not. But even after that, the engine will call
> engage method of each every module connected to the current message.
>
> Most of the time, we guess this engage method will do nothing. But if
> one needs to do some handler manipulation even after phase resolving,
> here is the time.
Hm. See above. (?)
--G
Re: [Axis2]Proposed Deployment changes
Posted by Eran Chinthaka <ch...@gmail.com>.
Hi,
Let me add some more to this ;)
On Apr 7, 2005 10:07 AM, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> hi all,
>
> I am sorry the previous mail was with wrong subject so I am mailing it again
> with correct subject.
>
>
>
>
> At the axis2 face to face we did number of changes to axis2 architecture,
> had to get rid of EngineRegistry and introduce new set of contexts (
> www.apache.org/~deepal/axis2f2f/axiscontext.jpg )
> considering all those I will have to do some changes to the deployment
> module too. This mail describes purpose changes to that, so please read that
> carefully and feels free to give your comments and any suggestions.
>
>
>
> Pre-dispatch phase:
>
> This is a system inbuilt phase and which is not going to specify in the
> server.xml as available phase , and all the handlers in this phase run for
> each service, i.e they act as global handlers. The main rationality behind
> introducing phase like this is to provide a way to add global handlers by
> modules if they want.
If I add something more to this : We wanted somethings to happen
before any of the dispatch handlers run. For example, security, WSA,
erc., The name is just another name for a phase, but unlike other
phases this will be burnt in to the engine. All the other phases are
mentioned in the server.xml, or somewhere else, but we thought its
better even not to mention pre-dispatch phase in server.xml as if we
do that, one can go and delete that entry. So we will just put a
comment in the server.xml about this phase, but not an entry.
This pre-dispatch phase can be considered as another global scoped
phase, but these should before any of the dispatch handlers.
>
>
>
> How deployment work in new architecture (after face to face summit).
>
> Firstly it loads server.xml and using that creates EngineConfiguration (EC)
> object which is more like EngineRegistry in old architecture.
> Then if there are any module to be deploy then load them one by one
>
> Using its module.xml find the module name and then retrieve corresponding
> "Module Context" form EC. If this is the first time server gets started up,
> EC gives an empty Module Context else it gives the previously saved (when
> server shutdown) Module context corresponding to the module.
> While processing the module.xml if there are any handlers with the phase
> property as "Pre-dispatch" phase then those handlers will be added to the
> Pre-dispatch phase by DeploymentEngine.
For example, the security module ot WSA module may add some handlers
to pre-dispatch phase.
> Then using the above Module context and EC, it calls the init() method of
> module implementation class , from that we give more flexibly for module
> developers to change the order of handlers in Pre-dispatch phase , add new
> handlers to that chain, if the module need to deploy a new service to do
> that and etc..
this init() will only be called once and for all, during the life time
of the engine. Basically this will called during engine startup or the
corresponding module deployment ONLY.
If one needs to do some other stuff per message basis within the
module, use the engage(...) method.
> Next add that module to the EC.
> Apply the same procedure for all the module.
> Next check to see whether there are any module references in srever.xml if
> so
>
> Gets the corresponding module (s) form EC and gets handlers of those
> modules.
> And add those handlers to the Post-dispatch phase , (those handlers are not
> going to be ordered at the deployment time)
> Next if there are any service have been deployed (drop in to /service
> directory) then load them one by one
>
> Read it service.xml and using service name retrieve the corresponding
> "Service Context" and while processing the xml file fill the Service
> context.
> Next check to see whether there are any module references if so gets
> handlers corresponds to those.
> Next using above handler come from
>
>
>
> modules (module references)
> service specific handlers (defined in service.xml)
> all the handlers in the Post-dispatch phase
>
> Creates three kind of flows (or three kind of execution chains) called
>
> 1. In-Flow
>
> 2. Out-Flow
>
> 3. Fault-Flow
>
> (Let's call those flows as serviceChain and those are also called pre
> compute handler chains)
>
>
> Next using above service context invokes init method of the service
> implementation class.
> Finally it will be added the created service to the EC.
>
>
>
> · At the run time for each message arrive, it invokes
> engage(serviceChain , EngineContext) method of each and every module , then
> the depending on the WS-police module will decide what to do to the
> serviceChain , 99% of the time it will do nothing. But if we consider about
> 1% their module developer can use either Phase rule or any other mechanism
> to change the handler chain.
Its like this. When engine asks for an execution chain for a service,
or for an operation, the engine configuration will do the phase
resolving as usual for all the handlers, irrespective of whether they
are in a module or not. But even after that, the engine will call
engage method of each every module connected to the current message.
Most of the time, we guess this engage method will do nothing. But if
one needs to do some handler manipulation even after phase resolving,
here is the time.
Regards,
Eran Chinthaka
>
>
>
>
>
>
>
> Thanks
>
> Deepal
--
--------------------------------------------------------
Eran Chinthaka