axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: [Axis2] A persistence module for Axis2
Date Fri, 06 Jan 2006 10:34:01 GMT
Dong Liu wrote:
> Hi, Steve,
> I would like to see what you have done and refer to them. What I am
> doing now is about manageability of BPEL processes which is related to
> normal web services, and the WS-Resources as well. I am so glad that
> so many guys here are interested in the persistence of web services.

I dont view WSRF as persistence of web services.

WSRF says "you can have an address that maps to an entity which may have 
a manageable life". Its not a web service at that point, it is a 
persistent resource/object that just happens to have a web service 
interface as a side effect.

Since what I am describing is deployments, the lifespan of a deployed 
thing is its deployment; if you undeploy something then it ceases to be. 
The WS interface itself is relatively stateless, part of the address is 
a uuid mapping to the particular deployment instance: how I do that 
mapping is my own implementation detail.

The point here is that there is no need for persistence in the Axis2 
stack. It can run in its own process, crash and be restarted and the 
address will still be valid, because the deployment is still there.

As an aside, I dont like WSRF for high-availability/long-term 
persistence because it mandates that the WS-A address is the reference 
to the resource, the OOID to use Corba terminology. but if you dont host 
the resource on the machine that is providing the web service, (i.e. it 
is on another box or on a database with failover), then if the WS host 
goes down, you have no way of addressing the resource because its 
address is no longer valid.

i.e, I have a deployment chamonix-1347, WS-A address


If cluster-host-1 becomes unreachable the fact that i can use 
http://cluster-host-2/services/deployments?jobid=chamonix-1347 as a URL 
is moot, because the address of the resource that I held is now invalid. 
I need to talk to some other endpoint to look for a job by ID to find 
the new address. Then, I now have two EPRs to the same thing


I cant assume that the first one is no longer valid; it may be a network 
partition rather than a host outage. How do I manage the lifecycle here? 
If I <Destroy> the second URL, does that destroy the app underneath, or 
only a view of it?

WS-RF has some interesting features (like explicit notion of resources 
as opposed to everything is an operation), but some of it just confuses me.

All my stuff is in CVS under ; 
you need to get the stuff under core/components/deployapi and then look 
in org/smartfrog/services/deployapi/transport/

for a web view:


View raw message