Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 14219 invoked from network); 3 Dec 2004 12:04:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Dec 2004 12:04:26 -0000 Received: (qmail 89582 invoked by uid 500); 3 Dec 2004 12:04:13 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 89555 invoked by uid 500); 3 Dec 2004 12:04:12 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 89542 invoked by uid 99); 3 Dec 2004 12:04:12 -0000 X-ASF-Spam-Status: No, hits=0.8 required=10.0 tests=HTML_MESSAGE,INVALID_TZ_GMT X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from relay3.slt.lk (HELO relay3.slt.lk) (203.115.0.25) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 03 Dec 2004 04:04:11 -0800 Received: from deepal (localhost [127.0.0.1]) by relay3.slt.lk (8.12.10+Sun/8.12.10) with SMTP id iB3C0K4C007459 for ; Fri, 3 Dec 2004 18:00:24 +0600 (GMT) Message-ID: <050401c4d930$2e45cb00$0965a8c0@deepal> From: "Deepal Jayasinghe" To: References: <200412031136.iB3BZw4C005482@relay3.slt.lk> Subject: Re: [Axis2][Engine]Step by Step;Engine, Engine registry deployment and the Phase Resolver Date: Fri, 3 Dec 2004 18:03:59 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FF_01C4D962.76AFED80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------=_NextPart_000_04FF_01C4D962.76AFED80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi chathura ; I agree with you that phase revolver should be out side the = engineRegistry and one thing we should be known is that if any service = got changed then that is called "hot update" and that handle as = undeployment followed by deployment of same service. so do we really = need to keep phase rule information ? Deepal ----- Original Message -----=20 From: Chathura Herath=20 To: axis-dev@ws.apache.org=20 Sent: Friday, December 03, 2004 5:39 PM Subject: RE: [Axis2][Engine]Step by Step;Engine, Engine registry = deployment and the Phase Resolver Hi Deepal, Srinath, =20 I agree with Srinath, that we need to keep the phase rules somewhere.=20 =20 =20 My view is these phase rules should be kept with the relevant = component rather than in the registry. What I mean to say is that the = service phase rules should be in the service(preferably AXISWSDLService) = and the module phase rules should be in the module. Once the Deployment = has parsed the complete wsdd and build the service, module , etc that = are almost ready to be deployed, then the phase resolver can run on it = and set the inflow, outflow and the faultflow s. This will enable us to = decouple the phase resolver from the deployment. Further more if a new = module or handler gets deployed for a certain service then the = deployment will get that service from the registry add the handler along = with the phase rules and run the phase resolver again and you are done. =20 Btw if we are to support deployment configuration to be sterilized in = the future, we cannot afford to forget the phase rules. =20 =20 Regards Chathura =20 -----Original Message----- From: Deepal Jayasinghe [mailto:deepal@opensource.lk]=20 Sent: Friday, December 03, 2004 3:57 PM To: axis-dev@ws.apache.org Subject: Re: [Axis2][Engine]Step by Step;Engine, Engine registry = deployment and the Phase Resolver =20 =20 hi srinath; =20 1) Keeping the state at the deployment is *BAD* as then the resolver bind with deployment. And Axis assues all deployment done via one deployment module. =20 <<=20 can axis do deployment via do deployment modules ? =20 >>=20 =20 2) keeping a states will create a parellel object Hirachy deployed = service =20 <<=20 It is no need to keep them in the deployment module , what it dose = is using the available date resolve the phase and give an executable service object to engine = registry , after that it dose not keep any state or what ever , only thing it keep in the memory is = service name. >>=20 =20 =20 3) We know that the Handlers for the execution Chain comes in at different time. (e.g. Module comes in at deployment time .. Service might come at any time) how can we order the handlers if EngineRegistry forgets handler rules. So we need to remember the = rules in soe form at registry! =20 <<=20 The all the handlers belong to a service described in the service.xml = , and if it want to have modules then it includes reference to modules , then at the deployment time = loaded the module from EngineRegistry if it has deployed otherwise will throw = an exception. So execution chain will come only at the deployment time. since we do not provide hot deployment or hot undeployment for modules = , I don't think execution chain will be change at run time. so there is no need of keeping phase rule date inside the Engine = Registry. =20 >>=20 =20 4) It is OK that the resolving done at the *deployment time* my point = is resolver *MUST NOT* use the private states stored inside the Deployment which bind the resolver to deployment. resolving can be done by engine(resolve at the first time ..and store) or deployment. =20 e.g. What happen if somebody come via JMX and trun on/off handler, module, service ... =20 <<=20 I don't think that even if we keep the Phase resolving with engine = registry we can handle that, say there are two or three services that has reference to the handler = you are going to turn off, how can we handle that if we keep PR (phase resolve) inside or with engine registry ? =20 its a good use case but the understanding I have is not enough to = answer that =20 >>=20 =20 Deepal =20 =20 =20 ----- Original Message -----=20 From: "Srinath Perera" To: Sent: Friday, December 03, 2004 11:48 AM Subject: Re: [Axis2][Engine]Step by Step;Engine, Engine registry = deployment and the Phase Resolver =20 =20 > > > 1) Engine work with the Deployment just like it happens in Axis = 1.1. > > > Engine knows nothing about the deployment and what it need a > > > EngineRegistry. The all the deployment do is to generate a = Engine > > > Registry and keep it up to date via hot deployment. > > > > > > 2) Phase resolver MUST work on the engine registry and = deployment > > > should not keep private states regarding the deployment apart = from the > > > Engine Registry. > > > > > > In this case I have no idea how we are going to resolve phases. in = order to > > resolve phase rules that we > > > > should have mechanism of storing phase rules if we try to do it = inside > > engine registry. > > > > If we do it at the deployment time by the Deployment module then = that has > > all the > > > > data to resolve the phases, since the required information with = the > > service.xml. > > > > And my idea is engineregistry dose not want to know about the = phase rules, > > it should only know about phases. > 1) Keeping the state at the deployment is *BAD* as then the resolver > bind with deployment. And Axis assues all deployment done via one > deployment module. > 2) keeping a states will create a parellel object Hirachy deployed = service > 3) We know that the Handlers for the execution Chain comes in at > differant time. (e.g. Module comes in at deployment time .. Service > might come at any time) how can we order the handlers if > EngineRegistry forgets handler rules. So we need to remeber the = rules > in soe form at registry! >=20 >=20 > > What is the problem of resolving phases rule by the Deployment = module at the > > deployment time ? bocz I can't clearly understand why it should = be done by >EngineRegistry. > It is OK that the resolving done at the *deployment time* my point = is > resolver *MUST NOT* use the private states stored inside the > Deployment which bind the resolver to deployment. > resolving can be done by engine(resolve at the first time ..and = store) > or deployment. > e.g. What happen if somebody come via JMX and trun on/off handler, > module, service ... > Cheers > Srinath >=20 =20 =20 ------=_NextPart_000_04FF_01C4D962.76AFED80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi chathura ;
 
I agree with you that phase revolver = should be out=20 side the engineRegistry and one thing we should be known is that if any = service=20 got changed then that is called "hot update" and that handle = as=20 undeployment followed by  deployment of same service. so do we = really need=20 to keep phase rule information ?
 
 
Deepal
 
----- Original Message -----
From:=20 Chathura=20 Herath
Sent: Friday, December 03, 2004 = 5:39=20 PM
Subject: RE: = [Axis2][Engine]Step by=20 Step;Engine, Engine registry deployment and the Phase Resolver

Hi Deepal, = Srinath,

 

I agree with Srinath, that we need to keep = the phase=20 rules somewhere.

 

 

My view is these phase rules should be kept = with the=20 relevant component rather than in the registry. What I mean to say is = that the=20 service phase rules should be in the service(preferably AXISWSDLService) and the module phase rules = should be in=20 the module. Once the Deployment has parsed the complete wsdd and build the service, module , etc  that are almost ready to be = deployed,=20 then the phase resolver can run  on it and set the inflow, = outflow and=20 the faultflow s. This will enable us to = decouple the=20 phase resolver from the deployment. = Further more if=20 a new module or handler gets deployed =20 for a certain service then the deployment will get that service = from=20 the registry add the handler along with the phase rules and run the = phase=20 resolver again and you are=20 done.

 

Btw if we are to support deployment = configuration to=20 be sterilized in the future, we cannot afford to forget the phase=20 rules.

 

 

Regards

Chathura

 

-----Original = Message-----
From:=20 Deepal Jayasinghe [mailto:deepal@opensource.lk]=20
Sent: Friday, December 03, 2004 3:57 PM
To:=20 axis-dev@ws.apache.org
Subject: Re: [Axis2][Engine]Step by Step;Engine, Engine registry = deployment=20 and the Phase Resolver

 

 

hi = srinath;

 

1) Keeping the state at the = deployment is=20 *BAD* as then the resolver

bind with deployment. And = Axis assues all=20 deployment done via one

deployment=20 module.

 

<< 

can axis do deployment via do = deployment=20 modules ?

 

>> 

 

2) keeping a states will = create a=20 parellel object Hirachy deployed service

 

<< 

 =20 It is no need to keep them in the deployment module , what it = dose=20 is

using the available=20 date

 =20 resolve the phase and give an executable service object to = engine=20 registry

, after that it dose=20 not

 keep any state or what ever , = only=20 thing it keep in the memory is service

name.

>> 

 

 

3) We know that the Handlers = for the=20 execution Chain comes in at

different time. (e.g. Module = comes in at=20 deployment time .. Service

might come at any time) how = can we order=20 the handlers if

EngineRegistry forgets = handler=20 rules.  So we need to = remember the=20 rules

in soe form at=20 registry!

 

<< 

The all the handlers belong = to a service=20 described in the service.xml , and

if it want to have=20 modules

then it includes reference to = modules ,=20 then at the deployment time loaded

the module from = EngineRegistry if it has=20 deployed otherwise will throw an

exception. So execution chain = will come=20 only at the deployment time.

since we do not provide hot = deployment or=20 hot undeployment for modules , I

don't think=20 execution

chain will be change at run=20 time.

so there is no need of = keeping phase rule=20 date inside the Engine Registry.

 

>> 

 

4) It is OK that the = resolving done at=20 the *deployment time* my point is

resolver *MUST NOT* use the = private=20 states stored inside the

Deployment which bind the = resolver to=20 deployment.

resolving can be done by = engine(resolve=20 at the first time ..and store)

or=20 deployment.

 

e.g. What happen if somebody = come via JMX=20 and trun on/off handler,

module, service=20 ...

 

<< 

I don't think that even if we = keep the=20 Phase resolving with engine registry

we can handle=20 that,

say there are two or three = services that=20 has reference to the handler you

are going to turn off,=20 how

can we handle that if we keep = PR (phase=20 resolve) inside or with engine

registry = ?

 

its a good use case but the = understanding=20 I have is not enough to answer

that

 

>> 

 

Deepal

 

 

 

----- Original Message -----=20

From: "Srinath Perera"=20 <hemapani@gmail.com>

To:=20 <axis-dev@ws.apache.org>

Sent: Friday, December 03, = 2004 11:48=20 AM

Subject: Re: = [Axis2][Engine]Step by=20 Step;Engine, Engine registry deployment

and the Phase=20 Resolver

 

 

> > > 1) Engine work = with the=20 Deployment just like it happens in Axis = 1.1.

> > > Engine knows = nothing about=20 the deployment and what it need a

> > > = EngineRegistry. The all=20 the deployment do is to generate a Engine

> > > Registry and = keep it up to=20 date via hot deployment.

> >=20 >

> > > 2) Phase = resolver MUST=20 work on the engine registry and = deployment

> > > should not = keep private=20 states regarding the deployment apart from = the

> > > Engine=20 Registry.

> = >

> >=20 <Deepal>

> > In this case I have = no idea how=20 we are going to resolve phases. in order

to

> > resolve phase rules = that=20 we

> = >

> >  should have mechanism of = storing phase=20 rules if we try to do it inside

> > engine=20 registry.

> = >

> > If we do it at the = deployment=20 time by the Deployment module then that

has

> > all=20 the

> = >

> > data to resolve the = phases,=20 since the required information with the

> >=20 service.xml.

> = >

> > And my idea is = engineregistry=20 dose not want to know about the phase

rules,

> > it should only know = about=20 phases.

> 1) Keeping the state at = the=20 deployment is *BAD* as then the resolver

> bind with deployment. = And Axis=20 assues all deployment done via one

> deployment=20 module.

> 2) keeping a states will = create a=20 parellel object Hirachy deployed service

> 3) We know that the = Handlers for the=20 execution Chain comes in at

> differant time. (e.g. = Module comes=20 in at deployment time .. Service

> might come at any time) = how can we=20 order the handlers if

> EngineRegistry forgets = handler=20 rules.  So we need to = remeber the=20 rules

> in soe form at=20 registry!

> 

> 

> > What is the problem = of=20 resolving phases rule by the Deployment module = at

the

> > deployment time = ?  bocz I can't clearly = understand why it=20 should be done

by=20 >EngineRegistry.

> It is OK that the = resolving done at=20 the *deployment time* my point is

> resolver *MUST NOT* use = the private=20 states stored inside the

> Deployment which bind = the resolver=20 to deployment.

> resolving can be done by = engine(resolve at the first time ..and = store)

> or=20 deployment.

> e.g. What happen if = somebody come=20 via JMX and trun on/off handler,

> module, service=20 ...

> = Cheers

> = Srinath

> 

 

 

------=_NextPart_000_04FF_01C4D962.76AFED80--