This chapter is from the book
This chapter is from the book
This chapter is from the book
4.4 SOA Technical Governance
With SOA, you can expect that business process cycles will be different from vendor product cycles. As a result, it is inevitable that, in the case of long-running or long-lived processes, you will need to support scenarios in which different versions of a business process exist concurrently on a changing infrastructure. Managing this challenge has implications throughout the project development lifecycle, not just for the runtime but also for the tools and methods used to define business processes within an enterprise.
You can manage the challenge of the dichotomy between business process cycles and product cycle by doing the following:
- Reducing the impact of changes by modularization
- Achieving middleware independence by defining the explicit process state
- Monitoring and handling business exceptions
Each of these topics is discussed in the following sections.
4.4.1 Reducing Impact by Modularization
Just as services can have different levels of granularity and permutations in the enterprise, processes also can have such granularity. This granularity appears when processes are designed as a composition of individual process modules. Each module offers a service interface and manages its own particular state internally. It then becomes much easier to change parts of the processes by developing new process modules that are selected from existing services using policies.
4.4.2 Achieving Middleware Independence with Explicit Process State
Current business process middleware engines maintain their process state internally. This dependency ties the process instances to the particular middleware engine, sometimes even to a particular version of the middleware. To avoid this, business process designers should elevate the explicit state beyond the engine level at each process step that leads to a waiting state until an external event arrives.
Thus, there is a need to be able to maintain and communicate state as distributed across the SOA. One particular programming model support for capturing these state descriptions is the set of specifications included in the WS-Resource Framework (as published on IBM developerWorks). These specifications allow the programmer to declare and implement the association between a Web service (a process module) and one or more identified, datatyped state components called WS-Resources.
4.4.3 Business Exceptions Monitoring and Handling
Even if the enterprise has spent a significant amount of time and effort to understand and model its business processes, undoubtedly unplanned business exceptions can still occur. A fully automated, services-oriented infrastructure that is capable of supporting any such exceptions to the business processes is unrealistic. This means that all business processes and their supporting infrastructure should be designed to allow manual recovery and control. Furthermore, for each business or technical domain, the organization should identify individuals that can handle such exceptions and act on the infrastructure. In most process and services identification modeling activities, the focus is on delivering mainstream models and a few variations. The business analysts must look at making the processes more granular so that unexpected variations and exceptions will be easier to handle in the operational environment.