sc009
Purchase Order Service
2008/11/19
Published
This scenario illustrates how Web services can be used to solve the
problems of asynchronous interaction, request/response correlation,
status notification, with the ability to provide ongoing status on
the transaction. Use of long running web services provides an enterprise
the ability to expose legacy systems to the internet / intranet and
invoke interoperable services. The resultant value to the enterprise
is increased flexibility and responsiveness to addressing
business challenges.
It is expected that other scenarios will
build on this scenario to add things like QoS. This scenario defines a
service that allows customers to create, update, and cancel purchase
orders. Once created, the purchase orders are acted on, and if valid and
approved, proceed through various stages before completion. The PO submitter
can query the status of the PO at anytime. The PO submitter may also
elect to receive status updates as the PO goes through various stages.
To permit the timely implementation of this scenario, the application
logic and business rules have been highly simplified in relation to
real-world processes of this type. Nevertheless, this scenario
illustrates how web services can be used to solve the problems of
asynchronous interaction, request/response correlation, status
notification, etc.
It is often desirable to enable resources to be access in a variety of
ways to allow for the data to be reused for multiple purposes. For example,
in this scenarios while some of the interactions between the customer and
the supplier should require some level of Quality of Service (QoS) to ensure
proper delivery of messages (e.g. adding WS-ReliableMessaging for the
delivery of the CreatePO message), some interactions are less critical.
One example might be a dashboard type of webpage that is used to display
the status of outstanding purchase orders. For this purpose the use of a
REST style of interaction might be sufficient as the interactions are
less critical and are "read-only" in nature. This scenario includes an
optional variant that demonstrates how WS*/SOAP as well as REST/HTTP
interactions can be used in a complimentary manner - thus allowing the
customer the option of choosing the appropriate technology for their needs.
The tests in this scenario require the support for WSDL 1.1, and
WS-Addressing 1.0. To simplify implementation only one version of
SOAP, SOAP 1.1, is supported in this scenario. Clients in this
scenario must be addressable - or use a mechanism such as WS-MakeConnection
to allow asynchronous responses to be delivered.
A client that is capable of accepting connections on a network endpoint.
A SOAP message exchange in which a requester sends a SOAP message to a
service and receives a response message. "Asynchronous" in this context
refers to the manner in which the underlying transport protocol is used
to carry the request and response messages. The response message is
sent over a separate connection that is initiated by the service to
the client (a "callback").
An application SOAP message for which no application SOAP response is
expected.
An application SOAP message for which an application SOAP response is
expected.
An application SOAP message triggered by a Request Message.
A SOAP message exchange in which a requester sends a SOAP message to a
service and receives a response message. "Synchronous" in this context
refers to the way in which the underlying transport protocol used to
carry the request and response messages. The response message is
returned on the back channel of the request message.
In this scenario, the supplier offers the customer a purchase order (PO)
service. The interface to this service is a CRUD (create, retrieve, update
and delete) interface for POs. The customer's client uses this interface
to create a new PO or retrieve (get status), update, or delete (cancel)
an existing PO. When a new PO is submitted by a customer it is assigned
a new order number by the supplier, which is unique within the scope
of that supplier. The PO order number can be used to get the status of,
update or cancel the PO.
Once created, the PO goes through the following states:
Created (initial state)
Verified
Approved
Back Ordered (if not in stock)
Completed
The following figure shows a simplified state diagram of the PO process:
Figure 1 - Purchase Order State Diagram
Once created a PO must be verified against a set of business rules that
check such things as allowable purchase amounts, credit and payment
history, etc. This verification is done automatically by the suppliers
system. Once verified, the PO must be approved by a human being. Once
approved the PO either begins the shipping process or, if the ordered
items are not in stock, enters the "Back Ordered" state. When the
back-ordered items are received by the supplier, the order ships and
the process is complete.
A PO can be either updated (changed) or canceled while in any of the
"Verified", "Approved" or "Back Ordered" states. If updated the PO
returns to the "Created" state where it will be re-verified. If canceled,
the PO enters the "Completed" state.
Because the verification of a PO happens in an automated fashion, the
designers of this service have decided to encompass the first state
transition in a single Asynchronous Request-Reponse Message Exchange. The
client sends a CreatePORequest to the service, the service creates the PO
and verifies it, then communicates the results to the client in a
CreatePOResponse message. The benefit of doing this is that the client can
determine, from the CreatePOResponse message, if the PO was verified or not.
This simplifies the clients interaction with the PO state machine be
eliminating the need to perform another operation to determine whether or
not the PO passed verfication. However, for various reasons, the
verification process, although automated, takes 5 to 10 minutes to complete.
For this reason, the CreatePORequest/CreatePOResponse is asynchronous.
Clients that attempt to invoke the CreatePO operation in a synchronous
fashion will likely timeout awaiting the response. Similar logic applies to
the UpdatePORequest/UpdatePOResponse exchange. Because the effect of
updating a PO is to reset the state to "Created" and trigger a
re-verification, the UpdatePOResponse message must be sent to the client
in an asynchronous fashion to prevent the client from timing out. This means
that the CreatePO and UpdatePO request message must not use wsa:Anonymous
in their wsa:ReplyTo EPRs - however, if the clients are non-addressable
then they may choose to use a mechanism such as WS-MakeConnection.
Clients can keep up to date with the state of their POs through two
orthogonal mechanisms. The first is to pull the state of a PO through
the GetPOStatus operation. Because the state of a PO is readily available
and the client is presumed to require timely information, GetPOStatus is
modeled as a Synchronous Request-Response Message Exchange. The second
method is to register with the service for asynchronous notification of
PO state changes. Clients do this by supplying a value for the
optional /wstfpo:PurchaseOrder/wstfpo:StatusUpdateEPR. This value is
the EPR of a client-provided endpoint that implements the
wstfpo:NotifyPortType interface. The PO service will send NotifyPOStatus
messages to this endpoint whenever the PO changes from one state to
another. Clients that implement some form of mapping between their own
order IDs and those of the supplier are encouraged to encode these IDs
as WS-Addressing Reference Parameters in the notification EPR. In this
way, each NotifyPOStatus notification message for a given PO will be
accompanied by SOAP headers that carry the customers internal ID,
thus saving the overhead of a table lookup operation on every
notification.
If the supplier supports a REST-full interface to the PO then it may
include a "StatusURL" within the CreatePOResponse message. The client may
then choose to issue an HTTP GET to this URL to retrieve the latest
status of the PO.
Note that POs in the "Completed" state may still have their status
pulled via the GetPOStatus operation. The length of time that a supplier
must maintain information on completed POs is negotiated between the
customer and supplier via out-of-band agreements and is left
unspecified by this scenario.
One of the goals of this scenario is to test long-running, asynchronous
interactions between a service consumer and its provider. While some aspects
of these interactions can be simulated in a relative short time period, to
fully test the behavior of a particular web service stack under such
circumstances requires an interaction that does, in fact, run for a "long"
period of time. Each of the test cases in this scenario are described by a
timeline which specifies the time at which various steps, actions, and state
transitions occur in the scenario. To insure consitent comparisons between
implementations, implementers of this scenario (both client and server
sides) must adhere to the timelines specified in this section.
These tests exercise the simplest success path of a PO from Created to
Completed. The /sc009:POReq/sc009:OrderDetails/sc009:CustID for these
tests is "ProtoGee". The timeline for both of these tests is as follows:
| Time |
Expedite Time |
Action |
| 0 |
0 |
PO created by customer |
| 6 minutes |
15 seconds |
PO verified by supplier |
| 25 minutes |
30 seconds |
PO accepted by supplier |
| 385 minutes |
45 seconds |
PO shipped by supplier |
Note: An order may optionally include an Expedite value of 'true'
to indicate that the PO service should use the shorter timing
intervals. However, this should only be used for quick testing
purposes. The normal (longer) times should be used to ensure
proper, and full, testing of the more complex long-running nature
of a true PO service.
This test is initiated by the client sending the following message to the PO service:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soapenv:Header>
<wsa:MessageID>some message ID</wsa:MessageID>
<wsa:To>appropriate URI</wsa:To>
<wsa:Action>http://www.wstf.org/docs/scenarios/sc009/CreatePO</wsa:Action>
<wsa:From>
<wsa:Address>appropriate URI</wsa:Address>
</wsa:From>
<wsa:ReplyTo>
appropriate EPR
</wsa:ReplyTo>
<wsa:FaultTo>
appropriate EPR
</wsa:FaultTo>
</soapenv:Header>
<soapenv:Body>
<sc009:POReq>
<sc009:OrderDetails>
<sc009:CustID>ProtoGee</sc009:CustID>
<sc009:ShipTo/>
<sc009:BillTo/>
<sc009:UserContact/>
<sc009:LineItems>
<sc009:Item>
<sc009:LineNo>1</sc009:LineNo>
<sc009:ProductName>ATX5350 Micro ATX Tower Case</sc009:ProductName>
<sc009:ItemType>computer components</sc009:ItemType>
<sc009:Partnum>ATX5350PRO2B</sc009:Partnum>
<sc009:Price>45</sc009:Price>
<sc009:Quantity>20</sc009:Quantity>
</sc009:Item>
</sc009:LineItems>
</sc009:OrderDetails>
</sc009:POReq>
</soapenv:Body>
</soapenv:Envelope>
The following diagram shows the message flows for this test:
After 6 minutes the service should send a CreatePOResponse (a SOAP message
with a wsa:Action of
"http://www.wstf.org/docs/scenarios/sc009/CreatePOResponse" and
a sc009:OrderInfo element in the body) to the ReplyTo EPR.
For the remaining portion of the test (and for some unspecified period of time thereafter) the client may send GetPOStatusRequest messages to the service. The ReplyTo EPR for these requests may be either anonymous or non-anonymous. The service should respond with GetPOStatusResponse messages that indicate the appropriate state of the PO (depending upon the above timeline).
The information in the /sc009:POReq/sc009:OrderDetails/sc009:LineItems element is not significant. It is only necessary that the order should contain at least one line item.
This test is initiated by the client sending the following message to the PO service:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soapenv:Header>
<wsa:MessageID>some message ID</wsa:MessageID>
<wsa:To>appropriate URI</wsa:To>
<wsa:Action>http://www.wstf.org/docs/scenarios/sc009/CreatePO</wsa:Action>
<wsa:From>
<wsa:Address>appropriate URI</wsa:Address>
</wsa:From>
<wsa:ReplyTo>
appropriate EPR
</wsa:ReplyTo>
<wsa:FaultTo>
appropriate EPR
</wsa:FaultTo>
</soapenv:Header>
<soapenv:Body>
<sc009:POReq>
<sc009:OrderDetails>
<sc009:CustID>ProtoGee</sc009:CustID>
<sc009:ShipTo/>
<sc009:BillTo/>
<sc009:UserContact/>
<sc009:LineItems>
<sc009:Item>
<sc009:LineNo>1</sc009:LineNo>
<sc009:ProductName>ATX5350 Micro ATX Tower Case</sc009:ProductName>
<sc009:ItemType>computer components</sc009:ItemType>
<sc009:Partnum>ATX5350PRO2B</sc009:Partnum>
<sc009:Price>45</sc009:Price>
<sc009:Quantity>20</sc009:Quantity>
</sc009:Item>
</sc009:LineItems>
</sc009:OrderDetails>
<sc009:StatusUpdateEPR>
notification endpoint reference
</sc009:StatusUpdateEPR>
</sc009:POReq>
</soapenv:Body>
</soapenv:Envelope>
The following diagram shows the message flows for this test:
After 6 minutes the service should send a CreatePOResponse (a SOAP message
with a wsa:Action of
"http://www.wstf.org/docs/scenarios/sc009/CreatePOResponse"
and a sc009:OrderInfo element in the body) to the ReplyTo EPR. Subsequent to this the service should send a NotifyPOStatus (a SOAP message with a wsa:Action of "http://www.wstf.org/docs/scenarios/sc009/PONotify" and a sc009:OrderInfo element in the body) to the endpoint indicated by /sc009:POReq/sc009:StatusUpdateEPR for every change of state in the order (e.g. Verified -> Approved).
The initial state transition from "Created" to "Verified" results in two messages being sent from the service to the client. The first message is a CreatePOResponse. The second message is a NotifyPOStatus.
For the remaining portion of the test (and for some unspecified period of time thereafter) the client may send GetPOStatusRequest messages to the service. The ReplyTo EPR for these requests may be either anonymous or non-anonymous. The service should respond with GetPOStatusResponse messages that indicate the appropriate state of the PO (depending upon the above timeline).
The information in the /sc009:POReq/sc009:OrderDetails/sc009:LineItems element is not significant. It is only necessary that the order should contain at least one line item.
This test follows the same steps as 1.1, however, the service
includes a StatusURL element within the CreatePOResponse message.
The client will then using this URL to query the status of the PO.
Same as 1.1 with the addition that the client successful retrieves
the status of the PO using HTTP GET against the StatusURL returned
by the service.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soapenv:Header>
<wsa:MessageID>uuid:8e8af8c0c0a9010343fa43fa78e11a9b</wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action>http://www.wstf.org/docs/scenarios/sc009/CreatePO</wsa:Action>
<wsa:ReplyTo>
<wsa:Address> ... </wsa:Address>
</wsa:ReplyTo>
</soapenv:Header>
<soapenv:Body>
<sc009:POReq xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009">
<sc009:OrderDetails>
<sc009:CustID>ProtoGee</sc009:CustID>
<sc009:ShipTo/>
<sc009:BillTo/>
<sc009:UserContact/>
<sc009:LineItems>
<sc009:Item>
<sc009:LineNo>1</sc009:LineNo>
<sc009:ProductName>ATX5350 ATX Tower Case</sc009:ProductName>
<sc009:ItemType>computer components</sc009:ItemType>
<sc009:Partnum>ATX5350PRO2B</sc009:Partnum>
<sc009:Price>45</sc009:Price>
<sc009:Quantity>20</sc009:Quantity>
</sc009:Item>
</sc009:LineItems>
<sc009:Expedite>true</sc009:Expedite>
</sc009:OrderDetails>
<sc009:StatusUpdateEPR>
<wsa:Address> ... </wsa:Address>
</sc009:StatusUpdateEPR>
</sc009:POReq>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soapenv:Header>
<wsa:MessageID>uuid:8e8af8d4c0a9010343fa43fa43413423</wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action>http://www.wstf.org/docs/scenarios/sc009/CreatePOResponse</wsa:Action>
<wsa:RelatesTo>uuid:8e8af8c0c0a9010343fa43fa78e11a9b</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<sc009:OrderInfo xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009">
<sc009:OrderID>sc009-order-5</sc009:OrderID>
<sc009:OrderDate>2008-11-11T21:32:36.718-05:00</sc009:OrderDate>
<sc009:OrderPrice>100</sc009:OrderPrice>
<sc009:OrderStatus>Verified</sc009:OrderStatus>
<sc009:LastUpdate>2008-11-11T21:32:31.700-05:00</sc009:LastUpdate>
<sc009:StatusURL>http://.../orders/sc009-order-5</StatusURL>
</sc009:OrderInfo>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soapenv:Header>
<wsa:MessageID>uuid:8e8b0d54c0a9010343fa43fa50fe3f40</wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action>http://www.wstf.org/docs/scenarios/sc009/GetPOStatus</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<sc009:GetPOStatusReq xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009">
<sc009:OrderID>sc009-order-5</sc009:OrderID>
</sc009:GetPOStatusReq>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soapenv:Header>
<wsa:MessageID>uuid:8e8b0d5ec0a9010343fa43fad3610a7e</wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action>http://www.wstf.org/docs/scenarios/sc009/GetPOStatusResponse</wsa:Action>
<wsa:RelatesTo>uuid:8e8b0d54c0a9010343fa43fa50fe3f40</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<sc009:OrderInfo xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009">
<sc009:OrderID>sc009-order-5</sc009:OrderID>
<sc009:OrderDate>2008-11-11T21:32:36.718-05:00</sc009:OrderDate>
<sc009:OrderPrice>100</sc009:OrderPrice>
<sc009:OrderStatus>Verified</sc009:OrderStatus>
<sc009:LastUpdate>2008-11-11T21:32:31.700-05:00</sc009:LastUpdate>
<sc009:StatusURL>http://.../orders/sc009-order-5</StatusURL>
</sc009:OrderInfo>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soapenv:Header>
<wsa:MessageID>uuid:8e8b6e45c0a9010343fa43fa59ca00e5</wsa:MessageID>
<wsa:To> ... </wsa:To>
<wsa:Action>http://www.wstf.org/docs/scenarios/sc009/NotifyPOStatus</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<sc009:OrderInfo xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009">
<sc009:OrderID>sc009-order-5</sc009:OrderID>
<sc009:OrderDate>2008-11-11T21:32:36.718-05:00</sc009:OrderDate>
<sc009:OrderPrice>100</sc009:OrderPrice>
<sc009:OrderStatus>Approved</sc009:OrderStatus>
<sc009:LastUpdate>2008-11-11T21:33:01.765-05:00</sc009:LastUpdate>
<sc009:StatusURL>http://.../orders/sc009-order-5</StatusURL>
</sc009:OrderInfo>
</soapenv:Body>
</soapenv:Envelope>
GET orders/sc009-order-5 HTTP/1.1
<sc009:OrderInfo xmlns:sc009="http://www.wstf.org/docs/scenarios/sc009">
<sc009:OrderID>sc009-order-5</sc009:OrderID>
<sc009:OrderDate>2008-11-11T21:32:36.718-05:00</sc009:OrderDate>
<sc009:OrderPrice>100</sc009:OrderPrice>
<sc009:OrderStatus>Approved</sc009:OrderStatus>
<sc009:LastUpdate>2008-11-11T21:33:01.765-05:00</sc009:LastUpdate>
<sc009:StatusURL>http://.../orders/sc009-order-5</StatusURL>
</sc009:OrderInfo>
Section 3.1 of the WS-Addressing 1.0 Metadata
specification says the following about the wsam:Addressing policy assertion attachment point:
The wsam:Addressing policy assertion applies to the endpoint policy subject.
For WSDL 1.1, these assertions may be attached to wsdl11:port or wsdl11:binding. For WSDL 2.0, they may be attached to
wsdl20:endpoint or wsdl20:binding. A policy expression containing the wsam:Addressing policy assertion MUST NOT be attached to
a wsdl:portType or wsdl20:interface. The wsam:Addressing policy assertion specifies a concrete behavior whereas the
wsdl:portType or wsdl20:interface is an abstract construct.
This is a problem for the following reasons:
A WSDL portType is a description of a set of related operations that affect the state of one or more semantically coupled
resources.
The synchronous or asynchronous nature of an operation is largely orthogonal to the underlying semantics of that operation;
the semantics of an operation are essentially what the operation is doing, whereas the sync/async aspect of an
operation is about how it does it.
Given the above is is inevitable that there will exist portTypes (or bindings of portTypes if you prefer) in which some of
the operations must be implemented in a synchronous fashion while others require an asynchronous interaction style. This
scenario provides an example of such a situation.
The current state of the WS-Addressing Metadata specification forces one of the following undesirable solutions:
Split the portType into two separate portTypes, one of which contains the synchronous operations and the other which contains
the asynchronous operations. This both complicates the interface and acts as a multiplier on the number of WSDL components
and their related artifacts. If you had one portType that with two bindings and two endpoints, splitting it creates two
portTypes, four bindings, and four endpoints.
Force all of the operations in the portType to be asynchronous. This greatly increases the complexity of programming the
client.
Re-factor the asynchronous operations into one-way operations with a callback EPRs. This complicates the interface, increases
the complexity of the client, and undermines one of the primary reasons for using WS-Addressing.
When this issue was discussed in the WS-Addressing WG, it was thought that it would never be the case that an endpoint could
support WS-Addressing for one operation but not another. If an implementation was capable of supporting addressing for one
operation, it was argued, it should be able to support it for all operations. By itself, this argument makes sense. However,
when the previously independent, top-level wsam:AnonymousResponse and wsam:NonAnonymousResponse
assertions were moved under wsam:Addressing as nested assertions, this had the inadvertent side-effect of removing
the ability to attach these assertions at the operation level.
This scenario illustrates an important shortcoming in the JAX-WS server-side
programming model. JAX-WS server-side requests are modeled as a synchronous method invocation on an impelementation of the
service endpoint interface. The response to the client blocks on the return from this method. The fact that, in the
asynchronous case, the response is transmitted over a separate connection to the wsa:ReplyTo address is besides
the point; in both the synchronous and asynchronous cases, handling a request consumes a Java thread for the lifetime of the
request. For asynchronous interactions in which the response may not be available for hours, minutes, or days, this has obvious
drawbacks. For example, a JAX-WS implemention of this scenario, when handling the Test 1.1 CreatePO requestion (without the
"Expedite" flag) will consume one thread for 6 minutes. If you send such an implementation 10 such requests per minute you will
cause the service to consume around 60 threads in a steady state. This may not be enough to burden a real-world web services
stack, but the implications are obvious; increase the request/response delay and/or the number of requests per minute and the
result quickly exceeds the limitations of what most enterprises are willing to support.
As part of the testing it was noticed that some Java implementations used the
SimpleDateFormat class to format xs:dateTime values. In that class the letter 'Z'
can be used in the pattern string to generate the timezone value (e.g. -0800).
However, notice that this value does not match the format specified in
XML Schema section 3.2.7.3, which
states that the timezone is to be of the form: (('+' | '-') hh ':' mm) | 'Z'. Note
the colon(:). This difference can cause interoperability issues so care needs to
be taken when using this Java class.
Initial Draft
Updated to include details, message samples and to remove reliability and
security.
Re-wrote business logic, schema and WSDLs. Added asynchronous notify
operation (NotifyPOStatus). Removed sections about supporting
non-addressable clients with WS-MakeConnection.
Converted to XML.
Added test case 1.
Remove references to SOAP 1.1. Changed "expedite" timings for the
Simple Test.
Add stuff to the findings section - part 3.
Add some sample messages.
Add finding on mixed synch and asynch operations in the same
portType/binding.
Add finding on lack of JAX-WS support for true server-side asynchrony.
Add some flow diagrams for each test.
Minor tweaks/typos.
Allow mc:Anon in async MEPs.
Add REST interface.