Re: [asap] Minimum requirements

[Jeffrey Ricker <jricker@izarinc.com>]

Each URI does not necessarily (or even usually) equate to a different
object. One servlet (or Axis bean) could handle the asynchronous service
and every instance of that service. Or one servlet could handle every
asynch service and every instance of those services. 

Suppose I had a servlet named 
http://izartech.com/orders

The servlet could be the asynch service. The following could be
instances of the asynch service
http://izartech.com/orders?no=1002
http://izartech.com/orders?no=1003
http://izartech.com/orders?no=1004

Or I could map such that Tomcat knows all URIs starting with "orders" go
to the orders servlet and that everything after "orders" is treated as a
argument

http://izartech.com/orders/1002
http://izartech.com/orders/1003

I also leave the door open for URNs. 

urn:universal:orders:565656:1002

--Ricker

On Tue, 2003-11-11 at 15:37, John Fuller wrote:
> 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.
> 
> 
> 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.
>