Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 25875 invoked from network); 5 Jan 2006 09:24:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Jan 2006 09:24:59 -0000 Received: (qmail 29214 invoked by uid 500); 5 Jan 2006 09:24:54 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 29063 invoked by uid 500); 5 Jan 2006 09:24:52 -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: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 29052 invoked by uid 99); 5 Jan 2006 09:24:52 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2006 01:24:52 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of pzfreo@gmail.com designates 64.233.184.194 as permitted sender) Received: from [64.233.184.194] (HELO wproxy.gmail.com) (64.233.184.194) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2006 01:24:50 -0800 Received: by wproxy.gmail.com with SMTP id 69so2649168wri for ; Thu, 05 Jan 2006 01:24:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=b+2MtNCduw1D1pNdXTBybMiXmC/wNYBSB7l5vOR/OjTutYeeVmOA1e4ZcZbJcQMSLl5hixc7j78xXl/hwAR6kLssK/f3Fpywbnd9M+om3UxrKIhCXnwRe4PZ3R5t0i3KSbKskw8XMhx9y1aN4lg9tXB8l1M8BFL80vqRmiw9Lu4= Received: by 10.54.158.16 with SMTP id g16mr3033467wre; Thu, 05 Jan 2006 01:24:22 -0800 (PST) Received: by 10.54.135.14 with HTTP; Thu, 5 Jan 2006 01:24:40 -0800 (PST) Message-ID: <88f5d710601050124k5de45f1yfdcda6b01bf6070a@mail.gmail.com> Date: Thu, 5 Jan 2006 09:24:40 +0000 From: Paul Fremantle To: axis-dev@ws.apache.org Subject: Re: [Axis2] A persistence module for Axis2 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43764_15336286.1136453080065" References: <004801c610e6$b313f570$c0039f95@ads.iu.edu> <88f5d710601040217x74ba084dw9e4be2d24c909208@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_43764_15336286.1136453080065 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Don Interesting ideas. I would like some more discussion of this. The original WSRM implementation worked by serialising the internal state of Axis2. I have to say I was not a fan of this model. I think that middleware like Axis2 should fundamentally be stateless for clustering and performance reasons. If you need to stop processing a SOAP message (e.g. to deliver it later inorder) then there is a great serialisation - the SOAP XML. WSRM needs a specific set of extra information and that seems to me to be specific to the RM implementation - not the general Axis framework. On the other hand I see huge value in having a general framework for building persistent stateful services using EPRs and Reference Parameters. I also agree that the persistence layer should be independent from specific databases and persistence frameworks. Paul On 1/4/06, Dong Liu wrote: > > Hi, folks, > > I agree with Ajith's opinion about this persistence module for axis2. > I think the persistence module should not be restrict to certain > databases or frameworks. According to Paul's question, I would select > the first choice, and maybe a little beyond that. My current work is > related to the manageability of web services. The most relevant > specification and framework is Management of Web Services (MOWS, a > part of WSDM) in OASIS. However, I feel the specification and its > implementation by IBM and HP are not what I expected. WS Resource > Framework is the basis of WSDM, but it focuses on the management of > resources *using* web services, not web service itself. > > The persistence module, in my mind, should be: > > 1. By the principle of separation of concerns, the module just takes > care of maintaining states of messages (or more specifically, the meta > information of messages, like the ID) and messaging contexts. It > supplies interfaces to databases. The specific way to store the states > depends on the developers. The handlers of the model take action > according to the designed priorities compared with other handlers in > each phase. > > 2. The correlation of an in-message, the service instance it triggers, > other messages and their contexts generated by this service instance > can be retrieved by the persistence module. > > Here is a scenario for this module. The manager cancels a service > instance triggered by a message whose ID or other properties are > known. > > Maybe we can discuss detailed scenarios about this persistence module, > and get a complete list of that. > > Thanks, > > Don > > > On 1/4/06, Ajith Ranabahu wrote: > > Hi Paul, > > May be I'm wrong but what I had in mind as a persistent layer for Axis= 2 > is > > a generic mechanism that allows to do all these things that you > mentioned. > > It can be used to persist either the Axis2 contexts or the WSRF > sessions. It > > may implement a database underneath or be just a file storage. > > We tried to do something like this before but it was not detailed > enough to > > be used by Sandesha. > > > > Ajith > > > > > > > > On 1/4/06, Paul Fremantle wrote: > > > Folks > > > > > > Can we be clear about what we mean by a persistence layer for Axis2?? > > > > > > I can think of at least two things that means: > > > > > > 1) A persistent state for the Axis2 contexts > > > 2) An implementation of a Data service backed by a database > > > 3) An implementation of WSRF or persistent sessions. > > > > > > Which is it you are planning Don? > > > > > > Paul > > > > > > > > > > > > On 1/4/06, Jaliya Ekanayake < jnekanayake@gmail.com> wrote: > > > > > > > > > > > > > > > > Hi Don, > > > > > > > > > > > > > > > > It would be very nice if we can have generic persistency layer for > axis2 > > so that other modules can utilize it. > > > > However IMHO if we try to persist a message once the entire content > > hierarchy is completed then we may end up with lot of unnecessary work. > What > > I also feel is if we can save the messages as an when they are arrive > then > > we only need to save the SOAP content and the transport specific > properties. > > We used this approach when we develop the initial version of Sandesha. > > However when we have the security in place we should let the security t= o > run > > first and then we can save the messages after that.In this case we may > need > > to save some security related properties as well. > > > > > > > > I would also like to give some help as well. > > > > > > > > Thanks, > > > > > > > > Jaliya > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: Chamikara Jayalath > > > > To: axis-dev@ws.apache.org ; sandesha-dev@ws.apache.org > > > > Sent: Tuesday, January 03, 2006 9:30 PM > > > > Subject: Re: [Axis2] A persistence module for Axis2 > > > > > > > > Hi Don, > > > > > > > > This is nice. We were planning to develop a similar functionality > for > > the RM Module. If you develop this module we can certainly use it. > > > > > > > > Some points, > > > > > > > > Axis2 has a context hierarchy. So messages coming in and going out > of > > the system will have some properties saved in those as well. So you may > have > > to persist some information in other contexts as well (to make sure tha= t > the > > message could be affectively reused later). But initially we can start > by > > saving only the message context. > > > > > > > > When security module is engaged, it will be the first to eccept > incoming > > requests and verify them. So make sure that the persistent handlers of > your > > module are placed after that. If you try to persist before the securit= y > > handlers , that may pave the way for a DOS attack. > > > > > > > > My personal view is that this functionality should be a part of the > core > > axis2 distribution. So that not only RM, but other modules also will be > able > > to use that (e.g. Transaction). So I believe a persistent module should > come > > with Axis2 (like addressing). (But may not be engaged by default.) > > > > > > > > Thanks, > > > > Chamikara > > > > > > > > > > > > > > > > On 1/3/06, Dong Liu wrote: > > > > > Happy new year, folks. > > > > > > > > > > I am planning to develop a module for persistence the messages an= d > > > > > messaging contexts in and out axis2. I wonder if there is already > such > > > > > efforts that have been made, or some good reference that I can > turn > > > > > to. Or any suggestions? > > > > > > > > > > Thank you, > > > > > > > > > > Don > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Paul Fremantle > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > > > http://bloglines.com/blog/paulfremantle > > > paul@wso2.com > > > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > > > > > > > > -- > > Ajith Ranabahu > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle paul@wso2.com "Oxygenating the Web Service Platform", www.wso2.com ------=_Part_43764_15336286.1136453080065 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Don

Interesting ideas. I would like some more discussion of this. Th= e original WSRM implementation worked by serialising the internal state of = Axis2. I have to say I was not a fan of this model. I think that middleware= like Axis2 should fundamentally be stateless for clustering and performanc= e reasons. If you need to stop processing a SOAP message ( e.g. to deliver it later inorder) then there is a great serialisation - the= SOAP XML. WSRM needs a specific set of extra information and that seems to= me to be specific to the RM implementation - not the general Axis framewor= k.

On the other hand I see huge value in having a general framework fo= r building persistent stateful services using EPRs and Reference Parameters= .

I also agree that the persistence layer should be independent fro= m specific databases and persistence frameworks.

Paul

On 1/4/06, Dong Liu <e= dongliu@gmail.com> wrote:
Hi, folks,

I agree with Ajith's opinion about this persistence modul= e for axis2.
I think the persistence module should not be restrict to ce= rtain
databases or frameworks. According to Paul's question, I would sel= ect
the first choice, and maybe a little beyond that. My current work isrelated to the manageability of web services. The most relevant
specifi= cation and framework is Management of Web Services (MOWS, a
part of WSDM= ) in OASIS. However, I feel the specification and its
implementation by IBM and HP are not what I expected. WS Resource
Fr= amework is the basis of WSDM, but it focuses on the management of
resour= ces *using* web services, not web service itself.

The persistence mo= dule, in my mind, should be:

1. By the principle of separation of concerns, the module just take= s
care of maintaining states of messages (or more specifically, the meta=
information of messages, like the ID) and messaging contexts. It
supplies interfaces to databases. The specific way to store the states
d= epends on the developers. The handlers of the model take action
accordin= g to the designed priorities compared with other handlers in
each phase.

2. The correlation of an in-message, the service instance it trigge= rs,
other messages and their contexts generated by this service instance=
can be retrieved by the persistence module.

Here is a scenario f= or this module. The manager cancels a service
instance triggered by a message whose ID or other properties are
kno= wn.

Maybe we can discuss detailed scenarios about this persistence m= odule,
and get a complete list of that.

Thanks,

Don


On 1/4/06, Ajith Ranabahu <ajith.ranabahu@gmail.com> wrote:
> Hi Paul,
>&nbs= p; May be I'm wrong but what I had in mind as a persistent layer for A= xis2 is
> a generic mechanism that allows to do all these things that you mentio= ned.
> It can be used to persist either the Axis2 contexts or the WSR= F sessions. It
> may implement a database underneath or be just a fil= e storage.
>  We tried to do something like this before but it was no= t detailed enough to
> be used by Sandesha.
>
> &nbs= p;Ajith
>
>
>
> On 1/4/06, Paul Fremantle < pzfreo@gmail.com> wrote:
> > Folks
> >
> >= ; Can we be clear about what we mean by a persistence layer for Axis2??
= > >
> > I can think of at least two things that means:
> >
> > 1)  A persistent state for the Axis2 conte= xts
> > 2) An implementation of a Data service backed by a databas= e
> > 3) An implementation of WSRF or persistent sessions.
>= >
> > Which is it you are planning Don?
> >
> > Paul<= br>> >
> >
> >
> > On 1/4/06, Jaliya Ekana= yake < jnekanayake@gmail.com > wrote:
> > >
> > >
> > >
> &= gt; > Hi Don,
> > >
> > >
> > >
&= gt; > > It would be very nice if we can have generic persistency laye= r for axis2
> so that other modules can utilize it.
> > > However IM= HO if we try to persist a message once the entire content
> hierarchy= is completed then we may end up with lot of unnecessary work. What
> I also feel is if we can save the messages as an when they are arrive = then
> we only need to save the SOAP content and the transport specif= ic properties.
> We used this approach when we develop the initial ve= rsion of Sandesha.
> However when we have the security in place we should let the secur= ity to run
> first and then we can save the messages after that.In th= is case we may need
> to save  some security related proper= ties as well.
> > >
> > > I would also like to give some help as= well.
> > >
> > > Thanks,
> > >
>= ; > > Jaliya
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Cha= mikara Jayalath
> > > To: axis-dev@ws.apache.org ; sandesha-dev@ws.apache.org
> > > Sent: Tuesday, January 03,= 2006 9:30 PM
> > > Subject: Re: [Axis2] A persistence module f= or Axis2
> > >
> > > Hi Don,
> > >
> > > This is nice. We were planning to develop a similar function= ality for
> the RM Module. If you develop this module we can certainl= y use it.
> > >
> > > Some points,
> > >= ;
> > > Axis2 has a context hierarchy. So messages coming in and= going out of
> the system will have some properties saved in those a= s well. So you may have
> to persist some information in other contex= ts as well (to make sure that the
> message could be affectively reused later). But initially we can s= tart by
> saving only the message context.
> > >
> = > > When security module is engaged, it will be the first to eccept i= ncoming
> requests and verify them. So make sure that the persistent handler= s of your
> module are placed after that. If you try to  pe= rsist before the security
> handlers , that may pave the way for a DO= S attack.
> > >
> > > My personal view is that this function= ality should be a part of the core
> axis2 distribution. So that not = only RM, but other modules also will be able
> to use that (e.g. Tran= saction). So I believe a persistent module should come
> with Axis2 (like addressing). (But may not be engaged by default.)=
> > >
> > > Thanks,
> > > Chamikara> > >
> > >
> > >
> > > On 1/= 3/06, Dong Liu < edongliu@gmail.com> wrote:
= > > > > Happy new year, folks.
> > > >
> &= gt; > > I am planning to develop a module for persistence the message= s and
> > > > messaging contexts in and out axis2. I wonder if th= ere is already such
> > > > efforts that have been made, or = some good reference that I can turn
> > > > to.  O= r any suggestions?
> > > >
> > > > Thank you,
> > >= >
> > > > Don
> > > >
> > >> > >
> >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-= RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> >= =20 paul@wso2.com
> >
> >= ; "Oxygenating the Web Service Platform", www.wso2.com
> >
>
>
>
> -- > Ajith Ranabahu



--
= Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog= /paulfremantle
paul@wso2.com

"Oxy= genating the Web Service Platform", ww= w.wso2.com
------=_Part_43764_15336286.1136453080065--