This page contains design discussions related to the Process Governance capability within Project Overlord.

Stateless Conversation Aware Actions

M1 release of the Overlord-CDL capability includes a 'conversation aware' ESB actions mechanism. This mechanism has a design time component, to ensure that a service described using these 'conversation aware' ESB actions conforms to a specified choreography, and a runtime component to enforce the behaviour while the service is executing.

There are two issues with this approach:

1) The jboss-esb.xml definition of a service becomes very complex, due to the need to describe the stateful behaviour of the service.

2) To ensure we can detect errors at runtime, such as messages being sent or received out of order, it is necessary to maintain runtime state information.

For these reasons we are exploring a more 'stateless' approach, which could have the following benefits:

1) Conformance checks would still be possible, although may not be as complete as with the 'stateful' approach

2) The Service Validation mechanism can be used to ensure that the service conforms to the full required behaviour at runtime. This achieves the same benefit of the current 'stateful' runtime mechanism, but reuses an existing capability (i.e. does not re-invent the wheel), and has the added benefit of not having to maintain additional state information for the service.

The next step is to determine whether this 'stateless' conversation aware ESB action notation is going to provide the information required (for conformance checking), while at the same time not being a significant burden to developers.

An example of the current notation, associated with the Broker role in the brokerage example bundled with the M1 release, is provided in the list of attached files (jboss-esb-stateless-v?.xml).

To briefly explain this example:

The broker is receiving an 'enquiry' message, which then results in an unbounded loop sending 'requestForQuote' messages to a list of suppliers (concurrently). When all of the suppliers have returned their 'quote' responses, then a 'quoteList' is returned back to the buyer. In the choreography this delay, awaiting the async responses from multiple suppliers, is represented by a 'when' activity. Once the condition has been met (i.e. the quotes have all been received), then the response is returned back to the buyer.

The buyer can then either cancel the enquiry, or continue to complete the transaction. (Version 1 only defines the 'cancel' behaviour). Completing the transaction involves the buyer sending a 'buy' message to the broker, the broker then performing a credit check. If a 'credit ok' is returned, the broker will then confirm the order with the selected supplier, and confirm the purchase with the buyer. If a 'credit fail' is returned from the credit check, then the purchase failure response will be returned back to the buyer.

Various aspects of this configuration will be discussed on the Overlord dev forum.

Note: You will probably notice some empty service descriptors - these are placeholders for actions resulting from exiting the loop (i.e. the loop associated with sending the request for quote to multiple suppliers). There is also another point that you may notice, the first 'SwitchAction' which routes the inbound events has a path with no associated message type. This is because this path is triggered by a different type of event - in this case where all of the quote responses have been received from the suppliers, we then want to return the quote list back to the buyer. Both of these points will be the subject of dev forum posts in the near future.

[Jeff Yu] Yeah, I think with the 'empty message type' in 'SwitchAction' will be a little bit confused, it seems to me like the default branch for 'SwitchAction'.

[GB] Version 4 of the example now includes an '<event description="..." /> element for top level SwitchAction paths that are triggered by an event as opposed to a received message.

Discussion points:

1) Version 3 of the stateless example (attached) now includes the 'responseServiceCategory/Name' properties on the SendMessageAction, which will be used to supply a replyTo EPR to the called service. At present, the service category/name used is the main service descriptor with the SwitchAction. However this means that all requests and responses are being routed through the one SwitchAction.

[Jeff Yu] I am concerned about if it is all going through one 'SwitchAction', would it this action become too big?

It should be possible to specify other service descriptors in the responseServiceCategory/Name field. However more than one message type could be returned in a response (i.e. normal response and zero or more fault responses). Therefore the target service descriptor for the response needs to potentially have a SwitchAction to differentiate between the various response types.

[GB] Have now implemented the approach in the above paragraph - so responses are directed to a specific service descriptor, and if multiple responses could be received for a single request, then these will be directed to a new service descriptor with a SwitchAction (see Version 5).

2) If the replyTo EPR is sent with the request message, it will be the responsibility of the service implementation to store this information, in situations where it won't be responding immediately - i.e. if it needs to perform an async request/response with another service, before returning the response.

In a real application this may be persisted - but for the purpose of samples, we need a simple way to achieve this.

[Jeff Yu] I would prefer use memory for test, but use the filesystem in production.