SCA Overview

1 / 30
About This Presentation
Title:

SCA Overview

Description:

OpenCSA Member Section Service Component Architecture. 2 ... Configure its behavior (via setting props, refs) to match the current requirements ... – PowerPoint PPT presentation

Number of Views:17
Avg rating:3.0/5.0
Slides: 31
Provided by: mike344

less

Transcript and Presenter's Notes

Title: SCA Overview


1
SCA Overview
www.oasis-open.org
Sanjay Patil SAP Mike Edwards - IBM
2
Agenda
  • A little history
  • SCA and SOA
  • SCA scenarios
  • SCA specifications
  • OASIS SCA TCs
  • major challenges
  • Related future work

3
A little history
  • once upon a time, some programmers thought it
    would be good to have a programming model to
    support Service Oriented Architecture
  • That model is SCA
  • Industry collaboration grew from just 2 companies
    to 18 today
  • published 1.0 SCA specifications, March 2007
  • SCA specifications now ready for standardization
    in OASIS

4
(No Transcript)
5
Time Line Summary
Other Standards Bodies
1Q07
2007
2Q07
2Q06
4Q04
3Q05
Further complementary incubation
Finalization of further SCA Specs
SCA V0.95
SCA V1.0
SCA V0.9
SDO V1
SDO V2.01
SDO V2
SDO V2.1
Nov 2005
July 2006
Press Announcement of Project Launch
New Partners Announced
March 2007
SDO TC
Specs 1.0 Submission for Standardization
SCA TCs
System Vendors
Early Adopters
Adoption
ISVs Customer Value
6
Standardization
  • OASIS to guide the standardization of
    Specifications from the collaboration in the
    OpenCSA Member Section
  • Member Section Structure
  • 6 Technical Committees (TCs) to address one or
    more Specifications from the collaboration
  • SDO V2.1 for Java will be completed in the JCP as
    JSR235
  • Specification development to continue within OSOA
    collaboration for technologies not yet ready for
    standardization

7
Agenda
  • A little history
  • SCA and SOA
  • SCA scenarios
  • SCA specifications
  • OASIS SCA TCs
  • major challenges
  • Related future work

8
SOA Programming Model (1)
  • SOA Programming Model derives from the basic
    concept of a service
  • A service is an abstraction that encapsulates a
    software function.
  • Developers build services, use services and
    develop solutions that aggregate services.
  • Composition of services into integrated solutions
    is a key activity

9
SOA Programming Model (2)
  • Core Elements
  • Service Assembly
  • technology- and language- independent
    representation of composition of services
  • Service Components
  • technology- and language-independent
    representation of composable service
    implementation
  • Service Data Objects
  • technology- and language-Independent
    representation of service data entity

10
What are SCA and SDO?
  • Service Component Architecture
  • an executable model for building service-oriented
    applications as composed networks of service
    components
  • how to build composite service applications
  • Service Data Objects
  • a unified model for the handling of (service)
    data irrespective of its source or target
  • how to handle data in a services environment

11
Service Component Architecture (SCA) Simplified
Programming Model for SOA
  • model for
  • building service components
  • assembling components into applications
  • deploying to (distributed) runtime environments
  • Service components built from new or existing
    code using SOA principles
  • vendor-neutral supported across the industry
  • language-neutral components written using any
    language
  • technology-neutral use any communication
    protocols and infrastructure to link components

12
Key benefits of SCA
  • 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

13
SCA assembly
RMI/IIOP
AccountsComposite
External Banking Reference
Payments Component

Payment Service

OrderProcessing Component


Order Processing Service

Java EE

Accounts Ledger Component

BPEL
SOAP/HTTP
Multi-level composition
WarehouseComposite
External Warehouse Reference
Warehouse Broker Component

Mixed - technologies - app locations
Warehouse Component
Warehouse Service





JMS
Shipping Reference
C
14
Agenda
  • A little history
  • SCA and SOA
  • SCA scenarios
  • SCA specifications
  • OASIS SCA TCs
  • major challenges
  • Related future work

15
Bottom-up Composition
  • Select a set of existing component
    implementations for building the new composite
  • Configure the component properties

Composite
Draw internal wires
properties
properties
Wrap the components in a composite and configure
external services/references
Hand off the composite to Deployer
services
references
16
Top-down Composition
Properties
Composite
Ref
Start with gathering requirements for the
top-level composite
Service
Ref
Define the services/references and properties for
the composite
Break down the composite into individual
components and wires between them
Recursively break down each component
Hand off the individual component contracts to
developers for implementation
17
Heterogeneous Assembly
PHP
BPEL
Java
C
Legacy
Components in the same composite share a common
context for many aspects such as installation,
deployment, security settings, logging behavior,
etc.
18
Implementation Reuse By Configuration
Select an existing component implementation
Properties
Configure its behavior (via setting props, refs)
to match the current requirements E.g. Configure
multiple instances of product pricing component,
each with different currency, tax rate, discount
charts, etc.
Services


References
Component
Deploy the component implementation - Multiple
instances of the same implementation may be
running simultaneously
Implementation
- Java
- BPEL
- Composite
19
Deployment Flexibility
Deployer chooses and configures communication
mechanisms for services/references without having
to modify the component implementation
WS Clients
SOAP/HTTP WS Binding
Properties
References
Services
ERP Service
JMS Clients
JMS Binding
JCA Binding
20
Abstract policy decleration
Developer
Deployer
SCA Assembly
SCA Assembly
2
1
Policy Administrator
3
4
5
Repository
0
SCA Runtime
SCA policySets
Registry
0. Policy Administrator authors SCA policySets
with concrete policies 1. Developer specifies
intents on SCA assembly 2. Developer hands over
SCA assembly to Deployer 3. Deployer configures
SCA assembly by assigning SCA policySets (could
be automated) 4. Deployer deploys configured SCA
Assembly to SCA Runtime 5. Deployer updates
Registry
21
Agenda
  • A little history
  • SCA and SOA
  • SCA scenarios
  • SCA specifications
  • OASIS SCA TCs
  • major challenges
  • Related future work

22
SCA Technology
How do I define, use and administer policies for
non-functional aspects (QoS, etc)? ? SCA Policy
Framework Spec
How do I define, configure and assemble
components to create composites? ? SCA Assembly
Spec
Composite
SOAP/ HTTP
Component
JMS
JCA
How do I develop SCA components in BPEL? Or in
Java? Or C, PHP, ? SCA BPEL Client Impl
Spec,
How do I configure SCA services/references to use
SOAP/HTTP or JMS or JCA, ? SCA WS Binding Spec,

23
The SCA Specifications
Assembly
Implementation Languages
Policy Framework
Bindings
Java
JEE
Security
Web services
Spring
BPEL
RM
JMS
C
Transactions
JCA
24
Agenda
  • A little history
  • SCA and SOA
  • SCA scenarios
  • SCA specifications
  • OASIS SCA TCs
  • major challenges
  • Related future work

25
OASIS SCA Technical Committees
  • OpenSCA Member Section
  • SCA Assembly TC
  • SCA Bindings TC
  • SCA Policy TC
  • SCA J TC
  • SCA C-C TC
  • SCA BPEL

26
Work of the SCA TCs
  • Produce OASIS standard versions of SCA
    specifications
  • conformance statements
  • mandatory vs optional
  • portability, interoperability
  • Test suites
  • define test suites to check conformance

27
Challenges
  • What is a good test suite for SCA?
  • Coordination between TCs

28
Agenda
  • A little history
  • SCA and SOA
  • SCA scenarios
  • SCA specifications
  • OASIS SCA TCs
  • major challenges
  • Related future work

29
Possible Future work
  • C specification
  • COBOL specification
  • REST binding(s)
  • JSON, ATOM,

30
Related Work
  • OASIS SDD
  • Management
  • WSDM, SML,
  • WS- specifications
  • OASIS SOA RM
  • other RMs

31
Summary
  • OASIS SCA
  • an exciting challenge
  • major effort over the next year
  • aim to appeal to a very wide audience
  • 6 SCA TCs to run coordinate!

32
Useful links
  • OASIS Open CSA http//www.oasis-opencsa.org/
  • OASIS SCA Technical Committees
    http//www.oasis-opencsa.org/committees
  • Open SOA Collaboration http//osoa.org/display/M
    ain/Home
  • V1 level of SCA specs found herehttp//osoa.org/
    display/Main/ServiceComponentArchitectureSpecif
    ications
  • Useful papers and interesting SCA information
    http//osoa.org/display/Main/SCAResources
  • OASIS Webinar downloads http//www.oasis-open.o
    rg/events/webinars/
Write a Comment
User Comments (0)