Composing SCA Solutions and SCA’s Approach to Policy and Bindings Presentations

Posted by Boris Lublinsky on Jun 17, 2008

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

SOA ,

Specifications ,

SOA Platforms ,

SOA Appliance

Tags

Service Component Architecture

SCA is a set of specifications initially developed by IBM and BEA and now maintained by Open Service Oriented Architecture collaboration (OSOA) and OASIS Open Composite Services Architecture (Open CSA). Despite of its growing popularity there is still lack of understanding of what SCA really is, and a range of its capabilities. Two new excellent presentations from IBM’s Mike Edwards’ Composing Business Solutions using SCA and SCA Approach to Policy and Bindings can help architects and developers to better understand both architecture behind SOA and its implementation details.

Mike’s presentation on composing business solutions starts with defining SCA as an executable model for building service-oriented applications as composed networks of service components and comprised of (from Mike’s presentation):

• Assembly Model
  • how to define structure of composite applications
• Client & Implementation specifications
  • how to write business services in particular languages
  • Java, C++, BPEL, PHP
• Binding specifications
  • how to use access methods
  • Web services, JMS, RMI-IIOP, REST
• Policy Framework
  • Security, Transactions, Reliable messaging

Mike defines advantages of SCA usage:

• Loose Coupling: components integrate without need to know how others are implemented
• Flexibility: components can easily be replaced by other components
• Services can be easily invoked either synchronously or asynchronously
• Composition of solutions: clearly described
• Productivity: easier to integrate components to form composite application
• Heterogeneity: multiple implementation languages, communication mechanisms
• Declarative application of infrastructure services
• Simplification for all developers, integrators and application deployers

He also defines scenarios where SCA usage is not applicable for:

• Does not model individual workflows
  • use BPEL or other workflow languages
• Is not Web services
  • SCA may use Web services, but can also build solutions without using Web services
• Is not tied to a specific runtime environment
  • distributed, heterogeneous, large, small
• Does not force use of specific programming languages and technologies
  • aims to encompass many languages, technologies

The presentation then goes into details on top down and bottom up composition approaches with SCA, implementation reuse through configuration and component implementation, binding and policies.

Mike provides further details on policies and binding in his Policy and Bindings presentation, which defines how SCA provides agility and flexibility through separation of bindings and policies from components implementations. The presentation describes SCA bindings model and later elaborates on details of each bindings type:

• Specific to particular:
  • Access Method/Protocol/Transport
  • Serialization
  • Framework
• Apply to services and references
  • Typically added during deployment
• Extensible - more bindings can be added

Mike also defines (and explains) SCA policy model, which abstracts out complexity with a declarative mode, supporting the following:

• no implementation code impact
• simplify usage via declarative policy intents
• simple to apply, modify
• complex details held in PolicySets

The main components of the Policy Model include

• SCA policy intent
  • each represents single abstract QoS requirement - eg. integrity
  • may be qualified - eg. integrity.message
  • effectively constrain binding/policy set combinations
• SCA policy sets
  • collection of concrete policies to realize abstract QoS intent
  • apply to specific binding types or implementation types
  • binding/implementation may provide policies intrinsically
• WS-Policy
  • syntax for concrete policies in policy sets
  • o other forms of syntax possible

The indications of the future directions of SCA can be found in Updated SCA Wish list. Some of the most interesting possible directions include:

• SCA "registry" - the ability to centrally store and manage configuration and wirings.
• Improve/introduce additional SCA binding, including RSS, ATOM, JSON-RPC, etc.
• Numerous enhancements in security, reliable messaging, transactionality, etc.

Be sure to check out Mike Edwards’ full powerpoints: Composing Business Solutions using SCA and SCA Approach to Policy and Bindings See also InfoQ SCA content.

• Older >