Submitted by: Alistair P. Barros, DSTC/CITEC.
Ref: XXX
Regulation authority (e.g. a government department responsible for land tenure management).
Internal administrators (e.g. various administrative services which support land tenure management - internal to the government department).
External Stakeholders (e.g. local government, telecommunications, environment, transport etc. authorities having an interest in land tenure management - mostly external to the government department).
This use case considers multi-cast interactions between agencies where business decisions depend on information requested by several external stakeholders. Several cycles of request-response may be required in order to arrive at a decision, and responses from all stakeholders may not be guaranteed. Administrative services internal to the regulation authority's organization are used to detect exceptional situations in business applications which lead to new versions of proposals and a repeated cycle of the request-responses. Note, the use case describes a multi-casting situation apparent in different sorts of regulatory processes, e.g. government land tenure, insurance claims processing, property conveyancing, "life events" (like change of address). The description is independent of specific domains.
The primary business process lies with a regulation authority responsible for processing business applications warranting the business decisions as well as implementing the decisions. In order to make the decision, the business application is pre-processed and a business proposal (request) is sent to the set of external stakeholders. Stakeholders are required to acknowledge receipt of the request but may not necessarily provide a reaction to a proposal (response). They use their own business processes in order to record and process requests (and some processing may cascade to outside agencies).
The regulation authority requires all supplied responses for consideration of the next step - synchronization of incoming responses relies on timeouts of acknowledged requests from the external stakeholders. A search is run for specific parts of the collective information yielded, using the services of internal administrators. Each search is run in parallel and essentially determines whether a problem exists. Each set of searches verifies the same aspect of a problem (e.g. address validation) but from the view of different administrators. An exceptional situation is decreed to occur if a threshold number of problem results occurs in a search set. The occurrence of the first exceptional situation needs to be reported to external stakeholders. This signals to an external stakeholder that a new version of a business proposal will be issued. In an exceptional state, external stakeholders may query the regulation authority for further information.
Once all searches are complete, a new version of the business proposal will be generated as a result of an exceptional situation. The versioning of a proposal is serial, i.e. multiple versions should not exist at the same time. Responses for previous versions from stakeholders will not be accepted by the regulation authority once it collects supplied responses for processing. Moreover, instances of administrative searches cannot cross versions - they run in their version only. Overall, the multi-cast request-response cycle may repeat until such time that the regulation authority makes a decision.
Relevant points to consider:
The boundary and comparative layering of choreography and orchestration in a process architecture is explored with respect to complex, cross-agency "synchronizations." Two "synchronizations" are apparent in the above description, namely sync-merge (for responses from external stakeholders) and n-out-m join/discriminator (for the exception searches). In the use case, "synchronizations" are considered part of orchestration with choreography focussing on a global view of message exchanges and a global state changes which guards these. (Note, the "synchronizations" in this use case are described in a reference set of workflow patterns. Note further, BPEL has direct support for the sync-merge and no support for n-out-m join/discriminator).
The mapping between events at the orchestration and the choreography levels is not discussed.
The mapping between global choreography model and parts of choreography that pertain to the peers (ala the Burnett ML proposal) is not discussed. Choreography is conceptualisation for the purposes of this use case as a global state model.
A dependency is assumed between the choreography and underlying workflow activity which doesn't cause deadlock at either level. For example, incoming messages should not be blocked if they are required for "synchronization" in an underlying workflow. Once the global state, previous synchronization, in this example, would have been resolved. Therefore, choreography can messages associated with that synchronization.
The global (shared) nature of states reflected in a choreography, as required by this use case, raises issues about a "peer-to-peer" implementation of choreography.
This use case doesn't consider all situations of multi-cast messaging. For example, although not immediately apparent through the case study, the need to delineate internal and external services explicitly (the internal and external system boundary ala classical systems analysis), or scopes of services more generally, through choreography should be canvassed. Multi-cast messaging could then apply to particular scopes - e.g. send a message to all internal or external services . On the other hand, the use case does illuminate that, in this case at any rate, providing such a feature would violate the encapsulation of an underlying workflow.
(Caveat to editors: The author is not completely familiar with all requirements and issues, and their statuses thereof, discussed in the WS Choreography group since the July F2F).
Each actor in this use case has either a workflow or application behind a WSDL defined in order to collaborate with another actor or view. Exchanges through the services should not result in deadlock.
The arrival of a business application triggers an instance of the choreography and the business process of the regulation authority to start. The sending of the first version of the business proposal from the regulation authority to the external stakeholder causes each of their underlying services to start (but not stop). The message exchange between the regulation authority and the internal administrators sees a completed instance of their underlying services.
The flow described below captures the canvassing of a business proposal stage only. It does not describe the prior processing associated with the arriving business application nor the subsequent decision making and implementation stages.
The regulation authority develops a business proposal based on the initial state of the business application and canvasses this among the external stakeholders:
The regulation authority starts its business process once it receives the first business proposal:
|
Editorial note |
|
|
Submitted by: |
|