[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [asap] Minimum requirements
In the original draft a client asks to create an instance and the Observer receives a URI for the new instance. On the first read I had taken away that the factory would live at one endpoint and the new instance may/should be another. I had gathered that status requests would be made directly of the instances somehow. The factory knows how to create instances and how many of them there are, but it seems the instances themselves need to be resolvable from a URI. As an implementer, I've been toying with different ways of doing this for standalone and apache cases (ex: do I do something clever with fragment or query or when I generate the id? Do I use a simple db lookup for a guid? If the instances are actually threads and not just stored records do I use session style type/realm/identifier/thread/count etc? do I let threads listen on different ports? (These two aren't incredibly scalable: it would be nice to not need more endpoints than necessary to represent resources) ) In the OSGA the factory operation (like our createInstanceRq) creates the service instance but returns a service locator rather than just a handle: the handle alone isn't necessarily enough to find the instance without using an intermediary operation to resolve the handle. I guess a question is, how do we resolve the instance URI? Like with Factory introduce a new intermediary (vertically or otherwise) to do Resolution? On Nov 10, 2003, at 11:18 AM, Jeffrey Ricker wrote: > I have spent a long time thinking about this (perhaps too long.) I have > gone back and reviewed the stuff that Swenson and Shenfield have > written. > > First, I believe using the term "factory" has had tragic results. I > would like to propose the following terminology: > > Asynchronous Service: A resource that accepts requests for > asynchronous response. Actual results (response) of the request > are managed by an asynchronous service instance. > > Asynchronous Service Instance: This is the resource implemented > by the asynchronous service that is actually performing the > requested work. These resources allow for the actual monitoring > and controlling of the work. > > Observer: Any resource that receives notification events from > the an asynchronous service instance. > > Request data: The XML data sent to initiate the service. > > Response data: The XML data created by the successful > completion > of the service. > > > I believe that this is the minimum requirement to make ASAP work. > > 1. A service MUST accept a CreateInstanceRq > > 2. The service MUST accept an observer to be set in the > CreateInstanceRq > > 3. The service MUST respond to a CreateInstanceRq with a > CreateInstanceRs that contains the URI of an asynchronous > service instance > > 4. The service instance MAY accept SubscribeRq and UnsubscribeRq > > 5. An observer MUST accept CompletedRq and StateChangedRq. The > service instance will communicate any state other than > completed > in a StateChangedRq. > > 6. A service instance MUST accept GetPropertiesRq so that > observers > can query (poll) the state of the request. > > Everything else is a MAY. > > See attached Word document for further details. > <rework-20031110.doc>To unsubscribe from this mailing list (and be > removed from the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/asap/members/ > leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]