IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Advanced development topics > Assuring Quality of Service > Setting qualifiers and transactions

Quality of service: Qualifiers for business services

Quality of service (QoS) qualifiers define how much management must be provided for a component at run time. These qualifiers propagate transactions and control the quality and timing of message delivery.

The assembly editor tries to anticipate your needs by generating quality of service qualifiers when you add interfaces and partner references and when you generate an implementation or synchronize from an implementation. You can also add your own qualifiers to the module.

Service Components Architecture (SCA) allows quality of service qualifiers, such as transactions, security, and reliable asynchronous invocation, to be applied to components without requiring programming or a change to the service implementation code. IBM Integration Designer gives you the tools to quickly and easily compose an integrated business application that wires together components in modules that can be deployed to the IBM BPM. When wiring the components, you can specify qualifiers to provide extended quality of service to the components, as well as to the clients accessing the service. Sometimes, implementations require that qualifiers are set in particular ways; see the explanation of the join transaction qualifier for one example.

Usually, you apply QoS qualifiers when you are ready to consider solution deployment. However, be aware that you do not need to explicitly set qualifiers for them to be present. The assembly editor sets qualifiers when you create interfaces, references, or implementations.

For example, when you create a short-running BPEL process (a microflow), you also receive the following transactions and settings:

The topic Transactions provides an overview of how QoS settings influence transactions. You can also find individual reference topics with details about each qualifier.


Qualities of service qualifiers

Qualifiers are QoS specifications that define a set of communication characteristics required by an application for transmission priority, level of route reliability, transaction management, and security level. This topic introduces the qualifiers that are specified in these components:

At run time, these specifications determine how the clients interact with the target components. Depending on the qualifiers specified, the runtime environment supplies any required additional processing.


Qualifiers in the Properties view

The Properties view of the assembly editor provides information about where and how qualifiers are set in the module. It is the place to see and edit quality of service settings and to add new ones.

The Details page shows qualifiers that have been set on an element in the assembly diagram.

The Qualifiers page in the Properties view shows all the qualifiers for the module. White cells in the table show where you can change settings.


Qualifiers for implementation

Qualifiers for implementation identify the service's authority and express its requirements for a transactional environment. These are the qualifiers that are set on an implementation:

Activity session

This qualifier determines if the component's processing will be run under an activity session, which provides an alternate unit-of-work scope to the one provided by global transaction contexts. An activity session context can be longer lived than a global transaction context and can encapsulate global transactions. They are used for microflows when it is not possible to use a global transaction – for example, when the microflow uses more than one resource that only supports one-phase-commit. Activity sessions provide a solution by coordinating the one-phase commit process. If an activity session rolls back, changes are undone.

Microflows run on one physical thread from start to end without interruptions. As the name suggests, microflows are small in footprint and fast in execution. A microflow requires a transaction, but that can be a global transaction or a local one inside an activity session.

Transaction

The transaction qualifier determines the logical unit of work that the component's processing runs. For a logical unit of work, all of the data modifications to resources (not to be confused with changes to the values in a business object) made during a transaction are either committed together as a unit or rolled back as a unit.

Security identity

The security identity qualifier is a privilege specification that you can use to provide a logical name for the identity under which the implementation runs at run time. An implementation has to be created in order for this qualifier to be specified. If this qualifier is not specified, then the implementation runs under the identity of its caller, or under the hosting container's identity if no caller identity is present. Roles are associated with the identity and the roles dictate if the implementation is authorized to invoke other components.


Qualifiers for interfaces

Interface qualifiers are used to advertise the qualifiers supported by a target service, and therefore represent a contract with a client of the service. Qualifiers establish the preferred interaction style for the interfaces. These are the qualifiers that can be set for interfaces:

You can only apply event sequencing qualifiers to interface operations. Other interface qualifiers can be applied at three levels of a component or import:

When you add an interface to a component, a join transaction qualifier and a preferred interaction style are automatically added and set.

A deployment error occurs when the component's interface qualifier conflicts with its export interface's qualifier.

The qualifier of the operation overrides the qualifier of the interface; the qualifier of the interface overrides the qualifiers of all the interfaces for a component or import. Inherited qualifiers listed in the Properties view are gray and the assigned ones are in black.

Data validation

A data validation qualifier on a WSDL interface confirms that the data passed in to an operation matches the XSD types of the operation's inputs. When you add the qualifier to a Java™ interface, only the business objects (passed in as data objects) are validated.

Event sequencing

The event sequencing qualifier places a control on the order in which the runtime environment processes events. You specify a group of one or more operations and a key. When two or more events are received that invoke any of those operations that have the same key, the event sequencing qualifier ensures that they are processed in the order they are received. Without such a qualifier, the multithread run time environment does not necessarily process events in the order that they are received.

Event sequencing is supported only for components that are invoked using the SCA asynchronous invocation style. Invocations have parameters, which are business objects or simple types. The key is a combination of one or more business object attributes. You can set the event sequencing qualifier after you develop the business logic; it is independent of the implementation. See the related tasks at the end of this topic for a link to information about using event sequencing.

Join activity session

The join activity session qualifier determines whether the target service is capable of joining a client propagated activity session. Asynchronous component implementations should not expose Join activity session = True on any of its asynchronous interfaces.

Join transaction

The join transaction qualifier determines whether the target service is capable of joining a client-propagated transaction.

You can only apply the join transaction qualifier to synchronous invocations.

If the client invokes the component asynchronously, this qualifier is ignored. A component implemented with a long-running BPEL process or a business state machine cannot join a client transaction, because these implementations are invoked asynchronously.

Security permission qualifier for interfaces

Use the security permission qualifier to specify a role, which is a semantic grouping of permissions that a given type of users must have to use an operation in an interface. The identity of the caller must have this role in order to be permitted to call the interface or operation. If no security permission is specified, no permissions are checked and all callers are permitted to call the interface or operation.


Qualifiers for references

References qualifiers specify the reliability for asynchronous invocations and whether a target component's methods should be federated as part of any client transaction.

These are the reference qualifiers:

You can specify reference qualifiers that would apply to all the references of a service component or the stand-alone references. If required, you can also specify these qualifiers for each individual reference, in which case they would override the overall qualifiers. Inherited qualifiers listed in the Properties view are gray and the assigned ones are in black.

Asynchronous invocation

This qualifier determines if asynchronous invocations should occur as part of any client transaction. A service that is invoked asynchronously can have an implementation qualifier "transaction" set to global, local, or any. Where possible, you should use the global setting to achieve the highest level of integrity and robustness in your application, especially when the service needs to make outbound asynchronous invocations. The outbound asynchronous invocation puts a request messages onto an outbound queue. To ensure system integrity, putting the message on the queue should be done in the same unit of work as the work done by the component. To achieve this goal, the setting of the service's transaction qualifier should be set to global and the setting of the asynchronous invocation qualifier at the reference should be set to commit rather than to call.

If the qualifier is set to "call", the message is immediately placed on an outbound message queue. That placement means that the message is sent regardless of whether or not the caller's global transaction commits or rolls back. That method of invocation might break the integrity of the application; for example, it might debit a customer account in spite of the fact that something causes a purchase order to fail before it has completed.

This weakness is most obvious when the transaction includes a long-running process. The asynchronous invocation qualifier controls whether a component sends a request message in a transaction with a commit requirement or as a call that does not require a response. You only need to worry about the nature of the invocation if the completion of a transaction involves human approval or some other response that might delay completion.

If the caller is in a global transaction and the message requires a response in order to complete, that condition causes a problem if the call is made to a long-running process at commit time. A deadlock occurs; the message is sent when the global transaction commits, but the caller waits until the reply is returned before continuing its processing and eventually performing the commit.

There are some considerations that should be made when setting this qualifier to Commit. If the caller runs in a global transaction and makes the asynchronous call with a deferred response, a transaction timeout will result because the message is not sent to the target until the transaction completes; however, the caller waits for the response before committing the transaction. If this situation occurs, the following message is issued in the server console: 

CWSCA2010W: SCA Component \"{0}\" has attempted to make an asynchronous invocation using the deferred response invocation style against reference \"{1}\". This reference has the qualifier ''deliverAsyncAt'' = \"Commit\". This is a conflict that will cause the invocation to fail. Change the “deliverAsyncAt” qualifier on \"{2}\" to \"Call\".
For more information about this potential failure, see SCA thread hangs on a two-way asynchronous invocation and for additional information about asynchronous invocation, see the resources linked from Asynchronous invocation qualifier

Asynchronous reliability

To support asynchronous invocation of components, you can specify three asynchronous reliability qualifiers for the reference. They only take effect when asynchronous programming calls are used by the client to invoke the service. These are the reliability qualifier specifications:


  • Reliability

    The reliability qualifier determines the quality of the delivery of an asynchronous message. In general, better performance usually means less reliable message delivery. With an Assured (persistent) specification, the client application cannot tolerate the loss of a request or response message. With a Best effort (nonpersistent) specification, the client application can tolerate the possible loss of the request or response message. In this context, persistent means saved to disk, so the request is recoverable if the server goes down before the target service is invoked, and nonpersistent means not saved to disk, so the request is lost if the server goes down before the target service is invoked.


  • Request expiration (milliseconds)

    Request expiration is the length of time after which an asynchronous request will be discarded if it has not been delivered, beginning from the time when the request is issued. A zero (0) denotes an indefinite expiration.


  • Response expiration (milliseconds)

    Response expiration is the length of time that the runtime environment must retain an asynchronous response or must provide a callback, beginning from the time when the request is issued. A zero (0) denotes an indefinite expiration.

Suspend transaction

The suspend transaction qualifier applies when the implementation is running in a global transaction and makes a synchronous invocation. It determines if that global transaction is to be propagated to the target component. A transaction cannot propagate to the target if the implementation is running in a local transaction or if the invocation is done asynchronously. Under those conditions, this qualifier is ignored.

If the implementation is running in a global transaction, that transaction is propagated on all synchronous invocations to the target components by default. If those target components can join the global transaction and you do not want this to happen, add this qualifier and set its value to "true". However, when suspend transaction is set to true, the target component's effective transaction environment is either a new global transaction or a local transaction.

Suspend activity session

When the invocation is synchronous, the suspend activity session qualifier determines whether the client will propagate the activity session to the referenced component. If the client does not want a target component to federate with the client's activity session, further qualification of the reference is required using the Suspend activity session qualifier.

This reference qualifier is ignored if the invocation occurs using any of the asynchronous interaction styles. The client activity session is not propagated if the client uses any asynchronous interaction styles. This reference qualifier is also ignored if the invocation occurs outside the scope of an activity session.

This qualifier does not affect the activity session environment of the target component. That is, the target component's hosting container is still entirely responsible for providing the activity session environment that is required by the implementation.

Setting qualifiers and transactions


Related information:
Quality of service qualifier reference