Hi, Steve, I like the ideas behind smartfrog, and actually I read most of its documents early last year, as I remember. At that moment, I thought some features of smartfrog would be part of my project that was supposed to related to autonomic computing and management of dynamic environment somehow. An interesting story was that my supervisor did not like the name "Smart Framework for *Object* Groups" very much when I explained what smartfrog is for. He said we need services not objects. Its very funny.
I agree with you on the point that "WSRF is not a persistence of web service". I think WSRF as a way to wrap the resources using web services and get access to them through the web services. So if a WS-resouce is developed for a resource, then the resource endpoint is just a place to retrieve and change the states of the resource. A resource could have a number of such endpoints. In such a scenario, the state of the resource is maintained by the resource itself or other legacy systems in charge of the states. What the WS-Resouce endpoint does is just to link the ws messages with those states. Therefore, as you described, it does not imply that the resource fails when a resource endpoint fails, and the manager should be able to access the resource by another endpoint. The persistence module of axis2, as I understand, refers to the component developed for the persistence of the messages and the messaging contexts on an axis2 deployment. Reliable messaging takes care of the messaging process from an endpoint to the other. The persistence module takes care of the meta information of incoming and outgoing messages, and the correlation between the messages and corresponding service instances for an axis2 deployment. Without such a persistence module, it will be very hard to achieve many aspects of the management of services and service instances running on axis2. Cheers, Don On 1/6/06, Steve Loughran <[EMAIL PROTECTED]> wrote: > 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 >
