Policies and Support for Conversations


SCA provides a way for a company to specify policies, which are identifiers that define a quality of service. For example, an interaction policy such as confidentiality specifies a requirement that a service makes on a requester or specifies a capability that a requester can offer. An implementation policy such as logging specifies another kind of runtime option - specifically, an option controlled by the technology that runs an implementation.

A more important distinction is that SCA divides policy specification into two major levels of detail. An intent is a high-level, general identifier such as confidentiality. A policy set is a lower-level description that makes one or more intents meaningful to a runtime technology.

SCA allows you as the developer to specify intents and to leave the policy sets for the deployer to assign. This division of labor has two benefits. First, it relieves you of a technical burden so you can focus on the business issues; second, it permits maximum flexibility because policy sets are assigned later, allowing for reuse of your component and composite definitions.

You may have reason to specify policy sets at development or assembly time. You might have a detailed understanding of runtime platforms, for example, or might need to use a particular runtime configuration. Nevertheless, we discourage the use of policy sets before deployment time and recommend that you communicate with your SCA deployer instead of creating restrictions in your SCA definitions, however appropriate those restrictions are. We'll say no more about policy sets except to direct the interested reader to the OSOA documents SCA Policy Framework and the SCA Assembly Model Specification.

Although every SCA installation will support a number of core intents, your company can add to them and is likely to name a policy administrator to handle the special issues involved.

A core intent of particular interest is conversational. By specifying that intent, you indicate that each operation in a given service is not separate from the rest but is part of a conversation, as described in Chapter 2. When the requester invokes the second or later operation in a sequence, the SCA runtime selects the appropriate conversation.

In most cases, a BPEL developer won't specify the conversational intent because the correlation-set mechanism is more powerful. Correlation sets maintain data integrity while the BPEL process is interacting with one or more partner services. When the focus is on data exchange with one partner service, however, the conversational intent has the following benefit regardless of the implementation language: you can avoid writing code to store and retrieve the data that helps maintain a conversation. SCA even provides an extension to WSDL so you can embed the conversational intent in a WSDL portType or interface.




SOA for the Business Developer. Concepts, BPEL, and SCA
SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)
ISBN: 1583470654
EAN: 2147483647
Year: 2004
Pages: 157
Authors: Ben Margolis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net