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
