RE: [asap] Minimum requirements

[Jeffrey Ricker <ricker@izartech.com>]

On Mon, 2003-11-17 at 11:57, Keith Swenson wrote:
> Generally I like your proposal.  A couple comments.
> 
> (1)
> Could others on the list comment on the name 'factory', please?  It is
> common for people to be concerned of the concept of having to use a
> factory to create an instance.  Once the concept is understood, I
> generally have found the name factory to be clear.  I can go along
> with these new names, but before we change them, I want to be sure:
> does changing the name really make the approach more palatable, or was
> it just that you needed to come around to understanding the necessity
> of the pattern?

[Ricker] The trouble I see with the term "factory" is that developers
immediately think of a specific object when we actually mean a URI.
There may be one object for all asynchronous services, or one object may
handle the factory and all of its instances. There is no correlation
between an asynchronous service factory and an object factory other than
the _concept_ or the _pattern_.  ASAP is only concerned with the URI and
the XML posted to that URI. Whatever is behind that URI is irrelevant. 

> (2)
> Data should NOT be request data and response data.  Why?  The
> "response data" gets sent as part of a "request" to the observer. 
> Request and Response are concepts deeply enshrined in a particular
> interaction.  The concept of context and result is completely
> different, and it will be way too confusing.

[Ricker] The response gets sent as part of the request? What?!?

I see XML goes into a black box and XML comes out later on. The XML that
goes in is the request data. The XML that comes out is the response
data. How are context and result _completely_ different? 

> (3)
> I have always been concerned by the two structures: context and
> result.  Why not one structure?  Because while the structure can be
> specified using XML Schema, it is impossible to specify what parts of
> this structure flow in which direction:  what parts are IN, what parts
> are OUT, and what parts are IN/OUT.  Data fields need to play all
> three of these roles (as well as data that is local to the process and
> neither settable nor readable, but that is unimportant to the
> protocol.)  I see two options:
> 
> (3a)
> Use the context data as the IN data, and the result data as the OUT
> data.  Values that are both IN and OUT would appear in both structures
> at the same XPath position.  This is consistent with current
> documents.
> 
> (3b)
> Define a single structure with all data in it.  Then define a separate
> list of XPath expressions for all parts of the process which are
> settable, and another list of XPath expressions for all parts that are
> readable.
> 
> An example of (3a):
> 
> <ContextData>
>     <Name>John Jones</Name>
>     <SSN>123-456-7890</SSN>
>     <Zip>34567</Zip>
> </ContextData>
> <ResultData>
>     <Zip>34567</Zip>
>     <Approval>true</Approval>
> </ResultData>
> 
> In this case the name, SSN, and zip are input to the process instance,
> and might be able to set with a set properties command.  The purpose
> of the process is to get approval for something, to the result data is
> the Zip and the Approval value.  Zip can both be set and read because
> it appears in both structures at the same XPath.
> 
> An example of (3b):
> <Data>
>     <Name>John Jones</Name>
>     <SSN>123-456-7890</SSN>
>     <Zip>34567</Zip>
>     <Approval>true</Approval>
> </Data>
> <Writeable>
>     <Item xpath="Name"/>
>     <Item xpath="SSN"/>
>     <Item xpath="Zip"/>
> </Writeable>
> <Readable>
>     <Item xpath="Zip"/>
>     <Item xpath="Approval"/>
> </Readable>
> 
> One advantage of this is a single data structure, a single schema. 
> While the separate list of access control is more cumbersome, it does
> open the possibilities that the access control might change over
> time.  For example, the total value might be able to change until the
> first approval, after which it becomes non-writeable.  One might be
> able to include as part of the state the parts of the data which are
> *currently* editable.  It also opens the door for access control which
> is user-dependent.  Somehow this seems better than defining two
> structures which have overlapping parts.

[Ricker] What you are proposing is way, way, way too RPC. 

Webservices are much simpler. XML goes into a black box and XML comes
out. If by coincidence some elements are the same, so be it. We can see
by the schemas that the request data has some of the same elements as
the response data. Why complicate the matter? 

> (4)
> Currently GetProperties is defined to always get all properties.  This
> is a problem if the size of the data available is large.  There should
> be a way to request part of the data.  Again, I propose that a list of
> XPath expressions should be used
> 
> <GetPropertiesRq>
>     <Item xpath="Zip"/>
>     <Item xpath="Approval"/>
> </GetPropertiesRq>
> 
> (5)
> RequestId should be removed from the headers.  Instead, WS-Reliability
> specifies a message id tag that should be used.  It also specifies
> sequence ids to assure that the messages are processes in the correct
> order, and specifies semantics for ignoring messages that are sent
> twice.  We need not require the use of WS-Reliability, but suggest it
> be used if you want to sure of correct operation.
> 
> (6)
> Priority.  SetProperties can be used to set the priority, but
> GetPriorities is missing any way to read it.  If SetProperties can set
> the priority, then CreateInstance should also be able to.  I think
> these are just missing from the examples.
> 


> -Keith
> 
> 
> -----Original Message-----
> From: Jeffrey Ricker [mailto:jricker@izarinc.com] 
> Sent: Monday, November 10, 2003 9:18 AM
> To: ASAP
> Subject: [asap] Minimum requirements
> 
> 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.
>