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

http://cluster-host-1/services/deployments?jobid=chamonix-1347

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

http://cluster-host-1/services/deployments?jobid=chamonix-1347
http://cluster-host-2/services/deployments?jobid=chamonix-1347

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 http://sourceforge.net/projects/smartfrog ; you need to get the stuff under core/components/deployapi and then look in org/smartfrog/services/deployapi/transport/

for a web view:
http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/components/deployapi/src/org/smartfrog/services/deployapi/transport/

-steve

Reply via email to