Chapter 8. Managing and Monitoring a Dynamic BPM and SOA Environment

Anticipate the difficult by managing the easy.

Loz

Managing and Monitoring Flexible Processes and SOA

Implementing dynamic BPM and SOA does not relieve the enterprise from employing a holistic management and monitoring approach on the business and IT levels. In previous chapters, we looked at using variability techniques to add damping in the causal chain, which removes the strong correlation between consumer and provider. This damping may be seen as an inhibitor to an end-to-end management and monitoring process; however, it is still necessary to manage the business services facing the customer as a complete stack to anticipate and correct problems that arise. Borrowing a line from a well-known rhyme, “for the want of a nail... the battle was lost,” let’s look at some of the nails, horses, and riders that help win the SOA and BPM battle.

The SOA and BPM management space is broad and has several dimensions. Figure 8-1 shows the relationships between these dimensions and/or elements.

Figure 8-1 SOA and BPM management elements

In this chapter, we do not address the full SOA governance, which is well covered in existing literature, but we look specifically at the life cycle and management aspects. SOA management includes planning and organizing, program management control, development of processes and services as well as the operations of processes and services across these management domains.

• Business processes and services life cycle—The policies, rules, and processes that define how the BPM and SOA environment functions consistently across the enterprise.

• Business management of processes and business services—The mechanism for defining, implementing, and delivering the status of business operations as well as providing accurate, real-time information about the state of the business delivering this management information with the appropriate aggregated Key Performance Indicators (KPIs).

• IT processes and service management—A consolidated set of practices and operations that are applied to all levels of IT management (process, service, application, and technology infrastructure) that provide a mechanism for the execution of management and control policies of the technology layers.

For the SOA and BPM space, management and control policies specifically include

• Process choreography and services component management, or the application of IT services management processes specifically for the process automation control as well as service component management, including design, development, and runtime infrastructure.

• Management of the applications that provide the services business logic.

• Management of the middleware and hardware technology infrastructure that serves as the base to operate the application, services, and business processes.

• Cross layer business service management, or analyzing the impact of lower layers on the delivered services and processes. This management attempts to answer the questions which and how many business services and processes are affected if a particular device or middleware instance fails. Am I able to deliver the expected quality of service?

• Security—Addresses the design and deployment of a common security model and consolidated security mechanisms across all aspects of the processes, software services application, and technology environment. I’m addressing security separately because it is so pervasive; it impacts all the other domains and requires specific attention.

All these domains use a metadata repository to provide a “logical” focal point for all metadata that relates to the design, build, and run phases of a BPM and SOA deployment. Even though this repository appears as a single point, it can federate other specific domain repositories and enables a global consolidation of the various policies. Having a logical focal point provides a place to perform impact analysis when changes occur in any of the layers. The registry should provide support for questions such as

• Which services and processes are affected by a change in the data sharing model used for integration?

• Which processes are affected by a service operation interface change?

Business Processes and Services Life Cycle Management

The three main artifact domains involved in a business process and business services dynamic approach require specific life cycle management. These domains, as described in Chapter 3, “Implementing Dynamic Enterprise Information,” Chapter 4, “Implementing Variable Services,” and Chapter 5, “Implementing Dynamic Business Processes,” are the service information model and policies, the business services operations, and the business processes.

Service Information Model Life Cycle Management

This domain includes the management of changes in the information model and consists of four steps:

1. Import and integrate model changes.

2. Model comparison.

3. Impact analysis.

4. Change action selection.

Import and Integrate Models

The changes in the information definition can come to the IT in various formats: XML schemas, UML models, or database Data Definition Language (DDL) files. A common service information model must be defined. As explained in Chapter 3, this model should describe the semantics of the information and messages exposed by services; it can be UML with appropriate stereotypes, XML schemas, or any other standardized representation, but a unique metadata format should serve as a reference for the information model.

For example, the TeleManagement Forum defines three standards that include information models: the SID model in UML, the MTOSI standard for XML schemas in XSD, and Operations Support System for Java (OSS/J) interfaces and classes. If all three sources are used, it would be appropriate to select XML, XSD, or Java for the data format presentation, although UML is probably the most versatile in this case because it allows the modeling of both Java and XML and consolidation of all models in UML. UML platforms usually provide XSD or Java import features.

Since we want to consolidate the diverse sources and model formats that constitute an enterprise model, we need the appropriate transformation capabilities. Rational Software Architect (RSA) provides support for developing any custom transformation between models. One enterprise may tune these transformations to standardize and automate the initial model load and transformation to the common metadata representation.

Figure 8-2 is an example of the consolidation of XML schemas to UML, using import in RSA. This import of an XSD in a UML model uses a plug-in provided by the WebSphere Fabric Tool Pack.

Figure 8-2 XML schema import RSA add-on in the WebSphere Fabric Tool Pack¹

An XML format of the models has to be produced from the common model because the service registries available on the market usually only support XML schemas to represent information models.²

At each iteration change of the information model, possibly resulting from new releases of standards, new business information needed, and any information source change, a new consolidated model will be versioned. Once the models have been loaded and consolidated for that version, we can move on to the model comparison step to identify changes from a previous version of the model if one existed.

Model Comparison

The model comparison highlights the differences between the new version of an information model and a previous version of the model. In our case, we are mostly looking at version differences between the consolidated models. As shown in Figure 8-3, any additions, changes, or deletions are examined.

Figure 8-3 Sample model comparison

Once the model comparison is reviewed and information changes are accepted or the new version of the consolidated model adjusted, we can move on to the model adjustment process. In this process, we apply all the variability techniques described in Chapter 3 to avoid propagating to interface changes that could be absorbed by information variability. We’re interested in propagating only fundamental structural changes of the information model used for integrations and services.

Impact Analysis

The goal of an impact analysis is to determine the global effect of a change to a particular artifact, in our case, starting from the information model. An impact analysis identifies the specific artifact to be modified, and then traces back through any relationships that indicate a dependency on that artifact. Normally with a variability approach, the impact analysis should show a limited number of WSDL, BPELs, or other components.

This process generates a complete graph, starting at the selected artifact and finishing with artifacts on which nothing else depends. Each artifact in the graph could therefore be affected by the change to the selected artifact. The artifact content types that can be affected by information model changes include XML schemas, Web Service descriptions, and any mapping mediation that uses the schema.

Figure 8-4 is a specific plug-in that my team developed to perform such analysis in RSA and identify the specific elements of a Web Services model that are impacted by an information change.

Figure 8-4 Example of a RSA plug-in developed to perform impact analysis

Figure 8-5 is an example of the impact analysis available out of the box from WebSphere Registry and Repository.

Figure 8-5 WebSphere Registry and Repository impact analysis

In the registry, this impact analysis usually results in notifications to stakeholders. After all actors in the governance model have decided on either accepting or rejecting the impact of the information model changes, different actions can be taken depending on how the change is to be deployed.

Change Action Selection

If we accept the changes, this step may imply changing and testing many interfaces and processes.

In a dynamic approach, we want to limit the impact of a change from the provider side on consumers of services, and vice versa. So, the change action can be to provide an adaptation for the existing consumers from the model they are using to the model as it evolves. The automatic generation of mapping mediations or mapping services is one that can be particularly useful in making the impact of changes smoother and providing variability.

The examples in Figure 8-6 show a business object data transformation generated from the impact analysis step.

Figure 8-6 Business object mapping generation from an impact analysis

Instead of a data mapping in mediation, the wrappering in a service of the adaptation of different information model object mapping provides additional reusability.

A service that does this adaptation is as follows:

newInformationModel serviceVersionMap(oldInformationModel)

Business Service Life Cycle Management

Flexibility is the goal of the approach discussed throughout this book, allowing the services interfaces flexible limits to accommodate the need for change. Still, we have to manage the services life cycle with the appropriate versioning approach. Neither the Web Services nor Service Component Architecture standards, discussed in Chapter 4, define anything specific to service versioning. The granularity of the descriptors defined by these two standards is at the service component level not at the operation level.

The identification elements for services provided by these two standards are name and namespace. The implication here is that a version strategy that relies solely on public domain elements can only be based on name and namespace combinations. The namespace content ends up being the natural carrier for public version information because the composition of service names is usually purely linked to the semantic of the business service.

Including major version numbers in the namespace is common. For example, Web Services Reliable Messaging defines these rules.³ Listing 8-1 speaks to best practices for versioning.

Listing 8-1 Defining Best Practices for Versioning

Other common approaches put major versions in the namespace and reserve minor versions for the nonbackward compatible services definition, such as deletion of elements in the information model or of operations. Modifications that do not generate backward compatibility issues, do not impact the namespaces.

The Web Services Business Activity standard states:

“Under this policy, these are examples of backwards compatible changes that would not result in assignment of a new namespace URI:

• Addition of new global element, attribute, complexType and simpleType definitions.

• Addition of new operations within a WSDL portType or binding (along with the corresponding schema, message and part definitions).

• Addition of new elements or attributes in locations covered by a previously specified wildcard.

• Modifications to the pattern facet of a type definition for which the value-space of the previous definition remains valid or for which the value-space of the preponderance of instance would remain valid.

• Modifications to the cardinality of elements for which the value-space of possible instance documents conformant to the previous revision of the schema would still be valid with regards to the revised cardinality rule.”⁴

An alternate solution resolves services endpoints using a services registry.⁵ Then the registry description can include a version attribute in addition to the name and the namespace. With a services registry, the version attribute can be defined at the operation level. This operation level of version control, however, implies an additional management effort, and it should be carefully evaluated based on requirements and the benefits to the cost of service operation changes.

Open SOA aligned registries include APIs to select SCA, WSDL, XML schemas, or any other document. Listing 8-2 is an example of code to retrieve a specific Web Service description from the registry.

Listing 8-2 Example Code to Retrieve Web Service Description from Registry

Enterprise Services Buses now provide registry endpoint lookup mediations that simplify such queries. Figure 8-7 is an example of mediation as provided by the WebSphere Enterprise Service Bus.

Figure 8-7 Endpoint lookup mediation configuration

The policy determines the number of endpoints that will be added to the message if one or more matches are retrieved. These are the possible scenarios:

• Return all matching endpoints—Updates the message with the service information of all the retrieved endpoints. You then need to use another mediation primitive to select a service.

• Return first matching endpoint and set routing target—Retrieves the service information of one of the matched endpoints, based on the values of the classification and user properties. The message is routed to the retrieved endpoint, if the Use Dynamic check box is enabled on the callout node or service invoke primitive.

• Return all matching endpoints and set alternate routing targets—Sets the target as the first retrieved endpoint and uses the remaining matches to set the alternate targets.

You can use the Return All Matching Endpoints policy to choose a specific service in the mediation flow. Then, select the service by using another mediation primitive.

Business Process Life Cycle Management

The evolving business conditions require an enterprise to adapt its operating modes resulting in the enterprise’s business abstract processes constantly evolving. In Chapter 5, you saw how the modularization can reduce the impact of changes, but there will still be instances of a business process that may last a considerable duration (in some cases, months or even years), and changes made to the definition of a business process might be required to be applied to already existing process instances as well as to instances newly created against that definition. We had such cases of existing processes that needed to be changed on-the-fly, in governmental projects where the law changed and had to be applied to existing instance processes so that the next steps would follow the new law.

Such business processes have a set of steps that execute on the runtime environment when they are active and a set of intermediate stages when they are awaiting an external stimulus, such as a human user processing a manual step. As described in previous chapters, these processes are composed of chains of private processes that collectively have an implicit state that requires synchronization in case of evolution. The likelihood of a change to the process definition impacting existing long-running abstract or private process (as defined in Chapter 1) instances depends on the duration of such instances and is relative to the particular domain.

Process definitions are generally formalized using flows, such as described by BPMN, choreographies (BPEL), state machines (UML), or ad-hoc sequencing models. Generally, these formalisms deal with two basic concepts: nodes, which can be services, activities, or actions; and flow of control, which are the connectors between nodes. In any running process instance, an implied state is associated with where that particular instance is within the overall process definition. Any changes in the specification of the nature of the nodes or in the semantics of the flow of control expressed by connections between nodes imply a process definition change, which we want to limit as much as possible in a variability approach. By experience, the system test on a process definition change can take a long validation cycle and imply a high cost, which is why we want to limit changes.

The following patterns are meant for handling changes in the process definition, which go beyond changes that can be immediately applied to existing process instances:

• Abstract processes dynamic binding approach—This approach, described in Chapter 4, is sometimes referred to as implicit process definition. Multiple services (or processes) are interconnected via dynamic binding resolved at runtime using contract-, content-, or context-based policies. The overall abstract process definition can be changed by either changing the policies or replacing, changing, or adding any of the chained process definitions. This is the approach that allows the most dynamicity.

• Module decomposition with a late binding approach—This approach is used in the case of a single private process definition coordinating lower level subprocesses. Each subprocess is called using a late binding approach, meaning that the definition used is the subprocess definition in use at the time the parent process makes the subprocess calls with the appropriate service interface. The subprocess definition can change without having to change the top-level process in case the input and output parameters to this subprocess are not affected. This approach offers less dynamicity for the overall process flow than the first modular approach.

• Blind replay navigation approach—We can model a BPEL process definition so that a process instance of a new version can navigate “blindly” from one activity to another without actually executing anything based on some external properties that resolve preexisting instance completion state. This allows for effectively skipping over the activities the instance running against the old definition had already completed. Once the process instance has been navigated to reach the desired state, it can then continue executing the respective steps against the changed definition. This approach is a tactical approach used in migrations of existing processes. However, it implies that the processes versions are close enough to perform a blind replay approach.

• Refactoring: Changing the name of the process definition—If there is a requirement to run multiple concurrent versions of a process definition to be available at runtime the only way to achieve this is by literally creating a new process definition (versus a new version) by copying the old process definition and applying a new name. This approach is only valid from a business aspect to let the current process instances complete with their current logic.

One way to implement the blind replay listed previously is to use process engine APIs to programmatically interact with the process instances. You should note that the WS-BPEL standard does not yet formalize a way of externalizing state of processes in terms of what current activities are being performed. However, specific implementation does provide APIs, such as IBM WebSphere Process Server (WPS) “com.ibm.bpe.api” interfaces, to manage and query processes. This process server engine exposes getAllWorkItems()⁶ and claimAndComplete() interfaces that can be used to retrieve the pending work items for a particular process instance and make them progress.

The Workflow Management Coalition standards body in its interface 2 document does standardize the API WMOpenActivityInstancesList that enables querying all completed activities within a specific workflow that then use WMGetWorkItem and WMCompleteWorkItem to handle the items’ progress.

Operational Management

Operational management domain addresses the support elements that maintain performance and availability of business processes, services, applications, and supporting IT infrastructure. It looks at protecting and maximizing the usage and availability of these assets.

It provides the support to visualize the health of business processes and services and service level agreements. Using these tools the IT management team can then isolate, diagnose, and fix the highest-priority transaction performance problems, and target IT resources and actions to quickly resolve the most critical and costly issues to deliver the greatest impact to the business.

As shown in Figure 8-8, operational management looks at managing the following layers:

• Technology infrastructure including hardware, operating systems, and middleware.

• Applications and application components, either Common Off The Shelf (COTS) applications, such as SAP, Siebel, and Oracle, or J2EE or .Net applications.

• Services and services components that are the services oriented enablement of applications and application components.

• Business process instances, specifically the operational status of choreographies of private processes. The business monitoring is addressed in the next section.

Figure 8-8 Operational management layers

Information is pervasive and managed as required on each layer.

The operational management also looks at correlating the layers into a dependency tree that help anticipating problems on higher layers that would derive from problems occurring in the supporting layers. Of course, the end user also has management as the consumer of the stack, shown in Figure 8-8.

Operational management requires the deployment of appropriate agents for specific management purposes and usually looks at reusing all existing logs and management interfaces, such as application or infrastructure events logs, but also Simple Network Management Protocol (SNMP) events or Java Management Extensions (JMX) interfaces.

Technology Management Layer

This management layer manages resources, supporting middleware, and transaction performance.

Resource management consists of collecting and analyzing resource data such as CPU utilization, network latency, I/O throughput, operating system status. The typical problems that can be detected at this level are network or hardware device queues filling up or timing out, disk failures, and hardware or network failures.

The supporting middleware management consists of understanding the health of the application servers, transactional servers, and database and integration infrastructure that support the services and then correlating problems in the services to infrastructure issues such as a messaging middleware queue filling up or a an exhausted thread pool.

Application Management Layer

This management layer manages application components and provides contextual resource monitoring across application resources. It looks at providing a consistent view of performance and availability metrics across multiple application resources. Applications can have memory leaks, performance issues, traps, or exceptions. Examples of application monitoring are mySAP memory and performance monitoring reported by mySAP service; Siebel eBusiness resources, databases, transactions, users, applications, subapplications, or programs; and application server component data coming from EJBs, servlets, JCAs, and JDBCs. It also provides support across the monitoring layers to establish the relationship between service requests and the application implementation artifacts such as COTS applications, but also J2EE beans and JDBC requests.

Service Management Layer

This management layer address services management, which looks first at collecting services data such as service headers, payload (SOAP/XML), caller origin, service destination, and service characteristics. It specifically looks at detecting SLA violations, invalid services requests, and dependency or relationship mismatch. It highlights Web Service response times, particularly the ones that exceed thresholds and some messages that are exceptionally long. Figure 8-9 is an example screen capture of the service management tool that shows the response time of services calls.

Figure 8-9 Service management in IBM Tivoli^® Composite Application Management for SOA

It should track to meet service level commitments by alerting problems before these levels are violated and have support for quickly isolating problems to minimize outages.

Through the use of correlation elements in the service message payloads, it can control the message flow in the service environment. In addition, the tooling and monitoring provides understanding of the performance of a service as decomposition information transactions composed of individual requests.

Figure 8-10 is an example of control flow management using such agents that show dependency and sequence diagrams built from the agent correlation information.

Figure 8-10 Web Services Navigator

As shown in Figure 8-11, the management infrastructure also supports the understanding of how services relate to each other and to the IT infrastructure.

Figure 8-11 Services to underlying layers dependency tree

Maintaining these dependencies is essential to anticipating service problems that arise from application, middleware, or hardware problems.

Business Processes Operational Management

The business process management focuses on business process flow health, detecting and alerting on anomalous conditions that could affect the business processes. It also provides the correlation between individual service health and the health of processes that are using such services.

This management involves two aspects: the ability to list and act on running processes and the management of impact of underlying operational layer status. The first type of management interface is provided out of the box by the process engines, which have API and default visualization management interfaces not requiring any additional management software, such as the Choreography Explorer (see Figure 8-12) shipped with WebSphere Process Server.

Figure 8-12 Default Choreography Explorer interface

In addition to this process instance view a dependency view can be provided linking processes, services, and the infrastructure. Figure 8-13 is the process detailed view from Tivoli ITCAM for SOA that helps manage all the SOA artifacts that a business process requires.⁷

Figure 8-13 Process detailed dependency management view

Dynamic Business Process Management

There are two aspects to management of business processes: The first part is specific business process instances tracking, and the second part is global business monitoring with reports or scorecards on KPIs. Both aspects require that events be collected to allow the real-time monitoring and management at the appropriate business decomposition levels. It is then important to include the design of the event capture in the technology architecture and to evaluate the message volume impact that these events generate. Our experience shows that, in many cases, the event capture strategy is not selective enough and causes performance problems, because the appropriate decomposition level approach has not been performed to select essential events.

Managing Business Monitoring Levels

This is a different monitoring process, separate from the operational monitoring discussed previously, because here we are looking not only at the choreographed processes (private processes). We are also examining the end-to-end process realized from the cascade of explicit processes in process engines and implicit processes delivered by the business logic running in packaged applications or legacy applications.

As described in previous chapters, in a dynamic business process approach the chain of private process modules realizing the end-to-end business process may result from a dynamic composition. The monitoring models that represent the explicit or implicit processes at various decomposition levels are a key part of monitoring. Following the same decomposition principles described in Chapter 1 and in Chapter 5, we use a hierarchical monitoring approach, with different monitoring levels showing different levels of processes.

Figure 8-14 shows a simplified example of an order provisioning, where the entry starts in a portal. When the customer decides to buy a product, the process switches to a CRM package. Then the order is decomposed into services for which configuration and provisioning are controlled by a set of BPEL choreographies using services that expose the telco service configuration and activation delivered by packaged applications and the resource provisioning business logic running in legacy applications.

Figure 8-14 Typical end-to-end process decomposition

The business management usually requires the monitoring of the high-level view of the end-to-end process, which is realized in different systems and applications in Figure 8-14 and represented by the events numbered 1 to 7. In a dynamic approach, there is no overarching process but a chain of applications and process components lined by business services. This implies that the monitoring applications can define and incorporate monitoring models that are not the representation of a concrete choreography in one given engine, but an implicit representation of the sequence of the appropriate level of end-to-end process by providing essential events happening in the different applications.

Each application or BPEL linked in the end-to-end chain has its own low-level monitoring. It is important not to mix these low levels in the high level end-to-end monitoring, but rather allow the drill down from the high level to lower levels. This dynamic linking of monitoring levels allows the lower levels to have variations that do not impact the higher levels and thus limits the impact of changes in specific lower levels of processing.

Variations from lower levels can still be shown in higher level process monitoring by using colors or specific labeling as shown in Figure 8-15, where variations monitored are the provision URI context for PC (in red) or for Mobile phone (in green) and the billing system variations per location.

Figure 8-15 Two instances of end-to-end monitoring with shading showing variations

By selecting actions on the specific boxes, a linkage may be provided to the specific lower level monitoring, which can be application specific and provided by the specific application software vendor.

By using this decomposition approach, fewer events get to be propagated at the enterprise level and performance maintained, while deeper levels of monitoring are still available by relying on specific domain features.

Implementing Business Dashboards

Because a manageable monitoring event strategy requires fewer capture points, the KPIs should also be structured so that a single event can carry a tree of indicator measures. It should be noted that the same KPI may appear at different business domain decomposition levels.

In Figure 8-16, we see insurance policies and claims. The Financial and Operating KPIs are aggregated at the enterprise level but also at the specific domain level, such as premiums revenue evaluation. The events carrying the information must then carry enough categorization to enable the monitoring dashboards to locate the appropriate information and build the corresponding measures.

Figure 8-16 Sample structure of insurance policies and claim KPIs

Such monitoring event structures may become variable and complex. This is why the monitoring engines support user-defined functions to perform such analysis and create the appropriate measures for the dashboards. WebSphere Business Monitor provides user-defined XPath functions (UDXF), which extend the basic monitoring capability to any required type of metrics support.⁸

Securing a Dynamic Process and Services Environment

Managing security is a topic that can fill an entire book by itself. This book takes a complementary approach to the existing literature, so this section only addresses some of the high-level elements to provide initial guidance and recommendation concerning the security of a flexible processes and services environment. This section addresses only the specific elements that concern services and processes and not behavioral security, which is a more general IT security management approach.

Overall Context of Services Security

As always, in a security approach, the protection responses must be in relation to the expected threats. The new threat exposures that a services and business process approach introduce are the unauthorized used of services, including denial of service, or inappropriate use of processes or services, such as bypassing audit controls, process control validations, or authorization levels. It is particularly important to understand that services often link the user to the application logic and that a significant level of security handling must occur at that level. Using a representation similar to the Open Systems Interconnection (OSI) seven-layer model, we can represent the various security interactions that occur. As it can be seen in Figure 8-17, Web Services security occurs at layer 6, even though an HTTP authentication may require additional security to authorize the specific service operation. In addition, specific encryption and signatures may be required to prevent unauthorized eyes from looking at the services payload and to validate that the service interaction content has not been tampered with before reaching the target application providing the service. Figure 8-17 shows a layered service security model for reference.

Figure 8-17 OSI-like layered service security model

Looking at the left part of in Figure 8-17, when enterprises expose services publicly, they are open ports on the Internet. These become potential entry points for hackers that try to use those services. Thus these newly opened entries need to be protected, and now XML gateways include XML security level validation that chokes undesired payloads before they reach application servers. Given the potential amount of requests, such as between enterprises interacting with partners providing content or services, these gateways are now often appliances dedicated to such functions. IBM provides the DataPower appliances that specifically perform such SOAP and XML level filtering, authentication, and validation.⁹

Another implication of sharing services with partners is that one enterprise cannot expect to manage the direct identification and authentication of all potential consumers of a service. This is why federated identity models have been developed for the use of services. These models promote the use of trustees on each partner side, providing certification of the service consumer. Several standards are being used in the field, specifically WS-Federation¹⁰ and Liberty Alliance Federation Framework (ID-FF)¹¹ with a consolidation of all federated security models in Security Assertion Markup Language (SAML) 2.0 standard.¹² The federation protocols also provide support for internal single sign-on in the enterprise and managing the appropriate tokens.

The team managing the security then also has to manage the life cycle of users or trustees and of all related security tokens and certificates. This life cycle includes the initial workflow for verification and validation of credentials that occurs for any new authorized user. The impact of this workflow should not be underestimated as it requires multiple eyes in the enterprise for high value services and thus generates delays and cost.

A reasonable approach to lower security management cost is to precisely evaluate threats and risks and revert to lower layer security features, such as SSL or IPsec where sufficient. This evaluation is part of the security governance of the enterprise that defines the security policies and the compliances to these policies.

For further details, I recommend reading the free downloadable IBM Redbook^® “Understanding SOA Security Design and Implementation,” which gives a detailed technical description of the security.¹³

Overall Context of Processes Security

Interestingly, none of the standards looking at business process modeling, management, workflow, or choreography addresses process security. The specific choreography engine implementations, however, do look at integrating security. In end-to-end process chains, as discussed previously, the process engines or applications often interact with multiple actors, and these components by default run using middleware level credentials such as the database connection pools that open with credentials that have nothing to do with the future users of the connection.

So the security questions that process designers have to answer include

• Is the initiator of any process entitled to do so and how can I control that entitlement?

• Given who initiated the process or any of the involved actors, are the next actors entitled to interact with the process?

• Is there a need deriving from a legal policy or enterprise policy to capture an audit trail of all the actors that have been interacting in a given process module or end-to-end abstract process?

Propagating the Credentials of the Initiator of a BPEL Process

If the inbound protocol that instantiates the BPEL process supports security credentials, WS-*, or Java enterprise credentials, then they are propagated by the most popular BPEL engines.¹⁴

If the protocol carrying the process instantiation request cannot carry the security information such as pure JMS (as opposed to SOA or JMS), then of course, the BPEL engine will run under its static security credential definitions.

Propagating the Credentials of the Initiator of an End-to-End Heterogeneous Process

In that case, all the applications and process engines linked in the chain of the process and business logic must be able to carry the credentials to the next module.

If one application in the chain cannot carry the security credentials, then a mediation in the Enterprise Service Bus can be used to correlate requests and reinsert credentials, but this may end up being complex and is used only in the specific cases that require such a security level.

Ensuring that the Involved Actors Are Entitled to Interact with the Process

In an enterprise security approach, all human actors are authenticated, so the process implementers must ensure that the process engines are able to define roles, groups, or users that can act on specific human tasks required by the processes. The commonly used security granularity at the process level is group level, usually getting that information from a Lightweight Directory Access Protocol (LDAP)–based directory infrastructure.

Managing an Audit Trail

It is a common practice for engines that involve human interaction to provide an audit trail.¹⁵ However, if the process is a combination of packaged or proprietary applications, process flows, and legacy applications, there will be a need for defining additional audit capture points and a global audit management strategy to integrate the various audit trails into a consolidated one. Volumes can become important; for example, the financial transactions retention requirements can span several years and lead to terabytes of audit trail.

Payload Level Services Security Performance Implications

The security architecture must take into account the impact on performance of message level encryption and signatures and limit the use of these features to the subset that really requires such a high level of security.

Encryption is known to be a lengthy process and hardware assist functions exist. However, in a SOAP XML payload not all of the message will be encrypted, so an additional parsing process is needed to delimit the boundaries of the encrypted data.

Similarly, the signature of an XML payload requires first the XML Canonicalization and SOAP normalization of the messages to ensure that serialization processes do not add to the message extra spaces or line breaks that have no meaning. This XML Canonicalization process ends up parsing the full XML message before attempting to compute a signature.

The impact on the processing time of a message can be up to one order of magnitude in the worst cases.

Similarly, the signature itself can be disproportionate compared with the signed information as the headers have to include information on the selected Canonicalization method, tokens (such as X509) used for the signature, and the signature itself.

It is common to have 3,000 bytes of signature headers with tokens, certificate, and signature added to the message where the payload is only 100 bytes of information containing an account and amounts.¹⁶

Summary

We saw in this chapter that the life cycle management and runtime monitoring are flexible and dynamic processes, and that the services and application environment requires global and specific layer management operations. It should be noted, however, that the end-to-end business application process monitoring can be implemented without any explicit corresponding choreography, given that the correct event strategy has been applied across the various application and process domains. This monitoring is in the end what enables the enterprise to take the appropriate decisions that are essential in today’s volatile economy.

Ad-hoc, event-driven, nondeterministic process management and monitoring is still a problem, as no monitoring model can be built due to the nondeterministic nature of the process. Correlation elements from the information model and time stamps can be a way to create on-the-fly monitoring models.

We have now reached the end of the book, and while I am conscious that more detail can always be provided, I hope that I’ve shared enough of my experience here that as you close this chapter, you are able to deliver more flexible and dynamic SOA and BPM implementations and control their life cycles.