Skip to Content

SCA Specifications (v1.0) are released to the public along with the announcement of intent to work on the standardization of the specifications at OASIS

I have actively participated at the SCA Policy working group and it is a pleasure to see the results of the work being finally public. It took a long time to get here, lots of debate and alignment. There is, of course, more work to be done.

Just as the industry is trying to digest the results of WS-Policy, a casual observer may wonder, why yet another framework for policy. SCA Policy framework is not targeted to nullify the existing approaches, however. Therefore, it would be good to bring some clarification to the approach and illustrate that the specifications and the concepts are not necessarily competing for our attention and there is a synergy between the two.

Platforms and specifications mainly target two specific goals.

  • Portability

  • Interoperability

SCA Specifications target heterogeneous development landscapes for composing applications and services that may be layered on top of existing platforms. In doing so, a primary goal for SCA specifications in general is tool ability and simplicity for composition. With this motivation, SCA Policy proposes abstraction and layering of policy vocabulary to existing concrete policy technologies targeted for a particular platform or stack.

I am not going to cover the SCA Policy in detail. There is quite good introductory material on the OSOA website already and you can read the specification for details. What I want to talk about is the primary motivation for the SCA Policy framework.

Currently, the framework targets two primary use cases:

  • The primary use case for SCA policy is to enable a developer to work with an abstract vocabulary by simplifying the level of understanding required to express concrete policies at service composition. This abstract vocabulary is called intents. For example, a developer composing a composite application or composing assemblies with services, it should be possible to designate intentions with simple, but qualifiable, vocabulary such as “confidentiality” or “reliability” or “umits-SOA-Profile”, where the latter may be comprised of other set of abstract level intents. The developer can use this vocabulary to express requirements or create relationships between references and services for composition. It is assumed that the developer knows the semantics of these intents or composition of profiles from these intents, but not necessarily what it takes to make them real.

    This approach allows tooling of compositions and frees the developer from learning complicated expressions of policy. For example, a transport level confidentialy may be expressed in reality with a nested complex WS-Policy policy expression but the intent abstraction and encapsulation allows the developer to work at a high level during composition with a single keyword “confidentiality.transport”. Anyone who is familiar with WS-SecurityPolicy should be aware that this shorthand is rather handy.

    In this use case, the deployment step takes care of the mapping between this abstract vocabulary and the concrete materialization of policy, which may be expressed in WS-Policy expressions, your favorite deployment descriptor, etc.

  • The second use case is for users who are aware of their target deployment environment. When there are already profiles or expressions of concrete policy expressions within the composition environment, the developer chooses to work with them directly rather than abstract keywords. For example, it is possible to name and designate a set of WS-Policy expressions to designate a particular capability. SCA Policy provides a formulation of concrete policies via a construct called policySet. A policySet in essence is a mapping between an abstract and a concrete representation of the abstract vocabulary. The content of a policySet could be a set of WS-Policy expressions.

    In the second use case, it is assumed that the environment that a developer composes services would be aware of these concrete contracts which are close to the implementation or binding of the components, services. Thus, the developer is more close to the metal in the composition process and assumed to be aware of the target deployment environment to materialize these policies, such as web services using WS-Policy.

Note that for both use cases, the rubber meets the road by utilization of policySets, either during development or solely at deployment. In the end, the deployment uses the alignment of the policySets and the target policy framework for linking services and references, realizing the concrete policies deferring to the underlying framework, WS-Policy. For example, SCA Policy does not prescribe how wiring is handled between services and references, it delegates to the underlying architecture. A consumer-provider intersection of concrete policies are deferred to WS-Policy framework instead. .

In SCA Model, it is possible to create profiles by composition of abstract vocabularies or by composition of concrete policySets together as the framework provides rules for composition at both levels. This is a powerful concept and should be approached with one of the particular use cases in mind as the framework itself accomodates both of them.

Note that for both use cases, the rubber meets the road by utilization of policySets. In the end, the deployment uses the alignment of the policySets and the target policy framework for linking services and references, realizing the concrete policies deferring to the underlying framework, WS-Policy. In addition, SCA actually synergizes with WS-Policy via composition, layering and mapping if desired. SCA Policy just like SCA itself is a layered architecture where WS-Policy is one of the possible expression of the concrete policy language. It all depends on whether the concrete bindings for the composition is targeted to the WS-* stack.

SCA abstraction also simplifies generating and composing policy profiles. The referencing mechanisms in the WS-Policy also allows profile composition purely in WS-Policy as well, but that is subject to a different discussion as SCA targets heterogeneous landscapes with different bindings, implementations, etc.

As SCA Policy goes to standardization, I wish that certain aspects of the SCA policy framework gets more attention during standardization. Here is my wish list:

  • Please do not forget about interoperability. Currently, the abstract vocabulary is defined with keywords, such as “confidentiality” and their semantics are in the specification. Toolability and simplicity do co-exist with interoperability if the standardization effort chooses to publish standardized mappings between the abstract vocabularies and their concrete counterparts. I do wish OASIS ends up publishing policySets that are concrete and would target a set of bindings, such as WS which would promote interoperability not only vague keywords. Otherwise, no one can determine via tools what “confidentiality” encompasses in different vendors tools and platforms. The standardization of concrete mappings is a must.

  • Please do not forget the original goal of simplicity. A big debate during the development of the specification was about the use of XPath and how attachment (as in WS-Policy) and applicability (as in SCA Policy) are different. Currently, a policySet author has to be the master of the concrete mapping, the target concrete policy language as well as the details of the tree-walking-algorithm utilizing XPath for determining where the policySet applies. It ain’t that simple.You need an individual who can wear both hats. I am visualizing that clever development environments targeting SCA UI will probably create these XPath expressions for policySet authors along with a portfolio of concrete policy expressions and I hope to see them. I can hear my colleagues to make the argument that policySets are typically created by administrators in an organization thus it is ok to expect them to be this skilled, but there is a value of simplicity at many levels of the architecture. I do hope OASIS standardization could entertain the idea of creating a guideline document targeted to SCA Policy Set authors at minimum, just like we have created a guidelines for assertion authors document in W3C in WS-Policy. We just scratched the surface in the SCA Policy Framework specification.

Have fun reading the SCA Policy spec. I hope this blog is helpful in illustrating the synergies between the two worlds.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply