asap message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: updated ASAP document
- From: Keith Swenson <KSwenson@us.fujitsu.com>
- To: "John Fuller (E-mail)" <jfuller@wernervas.com>
- Date: Tue, 23 Nov 2004 16:03:05 -0800
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]