OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

[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  
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]