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: updated ASAP document


Title: Message
 John Fuller,
 
Here are some notes on how the ASAP document should be updated  in response to discussion in the technical committee in the past few months.
 
1. UserInterface
There should be a new instance property defined like:
    <xsd:element name="UserInterface" type="xsd:uri" minoccurs="0"/>
Section 5.5 should have a paragraph on this, the description should be:
        UserInterface - This is the address of a web based user interface for the process, should one exist. The remote asynchronous service may have a way to display this service instance to the user(s) who are involved in the local service.  This URI can be used in the local service to make a link to the remote service that can be navigated by a user to see directly the state of the remote process.  An example of this might be a order process, which in turn schedules a shipment from a courier, and the courier provides a way to track the shipment, and so this URI would allow the user to the purchase process to access the tracking display directly.  This value is optional, and if not present then assumed that the remote service instance has no UI acceptable for the local users.
 
2. StateType
I remember having a discussion that expressing the state type as a restricted set of strings can not be extended in the way that state is defined to be extended.  Instead, the state should be a simple string, without any restriction in the xsd (lines 526-536 and possibly other places in the document).
 
3. SenderKey
There is an action item on the site specifying that SenderKey is optional for all requests, but for requests coming From the service instance (or service factory) to the Observer, the SenderKey is required.  The observer may need to use this for differentiating which service instance it is receiving the notification about, and to route the request properly.  There is no way to express this in xml schema, so instead the description has to be placed in the document in the section about the operations that can be invokved on the Observer.
 
4. Typos
line 586 two dots should be three
line 502, 510, 518: te formatting of the XML is odd and makes it hard to read.  I think the paragraph is set to "justified" which it really should not be for the XML samples. 
 
5. WS-Addressing
If you wish to tackle this, we need to update the document to conform to WS-Addressing, particularly the header fields that we propose (SenderKey, ReceiverKey) need to be changed to the WS-Addressing analogs. 
 
6. Make sure the WSDL file is included as an appendix, and the XSD file also.  Some people thought that ASAP was not a web service because it did not have WSDL descriptions.  The text should mention someplace up front that these are standard web services, described by WSDL, and using XML schema in the normal way.
 
Thank you for taking over this activity.
-Keith
 
 
 

Keith D Swenson, kswenson@us.fujitsu.com
Fujitsu Software Corporation
1250 E. Arques Avenue, Sunnyvale, CA 94085
(408) 746-6276 mobile: (408) 859-1005

 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]