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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> Hi Paul,
> May be I'm wrong but what I had in mind as a persistent layer for Axis2 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED] > 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 to 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 that 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 security
> 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 < [EMAIL PROTECTED]> wrote:
> > > > Happy new year, folks.
> > > >
> > > > I am planning to develop a module for persistence the messages and
> > > > 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
> > [EMAIL PROTECTED]
> >
> > "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
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
