[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [asap] Minimum requirements
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?
(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.
(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.
(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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]