This document discusses the thoughts on the technical preview of the Overlord Process Governance work.

1) Target Platform

The target platform for the Technical Preview (TP) is JBossESB 5, running on JBossAS 5.

Action: Need to understand how JBossESB 5 is difference from version 4.5. Depending on the outcome of this investigation, we may need to update:

a) service validators

b) jbossesb generator and conformance checking

c) update 'ESB conversation aware' runtime actions

It is likely that only the stateless ESB actions will be required - and possibly the stateful jbossesb4.5 actions should also be removed.

2) Runtime Service Validation

The current approach uses service validators effectively co-located with the services being monitored.

The main benefit of this is that detection of a 'behavioural' problem can be used to block a message from being delivered to the target service, thus potentially preventing the incorrect message corrupting the business state managed by that service.

However, in a production environment, it would be necessary for each service validator to persist the conversation state for each business transaction being monitored, in case of recovery. This could make management of sessions more complicated.

Although being able to block invalid messages may be useful, we need to consider the implications of such a mechanism. If the target service is stateful (i.e. a BPEL process), then an incorrectly sequenced message will not be processed anyway. So the problem only occurs if the service is stateless. If the service validation mechanism detects the problem quickly, and reports it in such a way that SAM can be configured to either notify the relevant people, or actually take appropriate remedial action, then the potential damage of processing the invalid message can be reduced.

The current service validation mechanism can only be used to determine if a message is out of sequence, and possibly if it is invalid in terms of the message schema. However there may be more validation that we wish to perform on the service interactions, perhaps using higher level business rules (i.e. policies), to determine the validity of an interaction - e.g. does it conform to an SLA. The current architecture would require these validations to be performed in different places, and would not enable the business rule style validaton to block delivery of a message.

So the other approach would be to report relevant service activity to a more central monitoring capability, which will be required anyway to provide an audit trail of service activity and errors, and then perform the runtime conformance checks centrally. Using this approach, potentially only the raw service activity information needs to be persisted, instead of the conversation session state being used to validate the service behaviour - so we have greater flexibility in how this is implemented. It also means that other 'non-behaviour' related validations can be performed on the same information.

This mechanism should work with SAM as much as possible, as the CEP part of SAM could be used to provide the higher level business validation of the service activity. SAM will also require an event stream for observing service activity - so we should leverage this - as well as any general reporting capability/console that SAM would provide.

In terms of the TP, we need to understand the plans for SAM, and how we can either help contribute to this work (to achieve the TP timescales), or atleast be able to migrate across to it at later stage when available.

So for the TP, I think we need:

1) Simple service activity recorders - assuming we all agree that the benefit of being able to block invalid messages does not outway the other benefits outlined above, of using the central validation approach.

2) A 'standard', but extensible event model, for reporting the various types of service activity we are interested in.

3) Repository for reporting activity information

4) Centrally managed behavioural validation, subscribing to the event stream - and potentially retrieving history information from the repository when necessary

5) Console for inspecting activity information, providing a correlated view of the global conversation and displaying detected errors

6) Optionally provide error notification to JON

So, although being able to do localised validation may have some benefits, I think longer term it is better to build on the SAM approach and validate event streams representing the activity - this will be easier to administer and use.

NOTE: If it is not possible to do all of this in the TP timeframe, then the existing service validator approach could be used wth the above changes being made before Process Governance becomes part of a product. In this case, the only additional features required would be (2), (3), (5) and optionally (6).

Longer term we should also aim to obtain the models to be used in validation from Guvnor, rather than configured within each JBoss server. This is not a requirement for the TP, but a further indication that the Process Governance component should build upon the other components of Overlord (i.e. SAM and Guvnor) where appropriate.

Before the TP is productised, we also need to move from the pi4soa based service validators to using a Scribble based validator. The pi4soa service validator can only validate against WS-CDL, however the Scribble validator would be able to validate any model that can be transformed into the core Scribble conversation model - as Scribble is used for the inter-model conformance checking, this will accomodate all source representations we are interested in - e.g. eventually BPEL, WS-CDL, BPMN2, jPDL, etc.

3) Design Time Generation and Conformance Checking

The two current implementation targets should be supported (JBossESB and BPEL).

In general there is work required to complete and fully test the conformance checking mechanism, This will be on-going work that will also benefit from the range of examples that will be developed to support the following two target platforms. So an important task for the TP will be to develop a range of choreographies that can be generated (hopefully) to both JBossESB and BPEL - and provide runnable implementations of the services in each language.

3.1) Conversation Aware ESB Actions

Need to build a wide range of examples to demonstrate and test different architectures that may be built. Depending on the extent of changes in JBossESB 5, we may need to support a different set of actions (or whatever the mechanism is).

3.2) BPEL

Need to complete the BPEL generation, along with the associated artifacts (e.g. WSDL), and commence the work on BPEL conformance checking.

4) Runtime Support

This relates to the runtime mechanism used in support of the generated artifacts.

For the TP, we only need to provide runtime support for the Conversation Aware ESB Actions - possible for both JBossESB 4.5 and 5.

This area will also benefit from a wider range of examples.