SCA and SDO

Service Oriented
Architecture
Lecture 10: Composite Services
Architecture (CSA)
Sources:
www.osoa.org
SOA for the Business Developer by Margolis
Introducing SCA by Chappell
95-843: Service Oriented Architecture
Master of Information System
Management
1!
Composite Services
Architecture (CSA)
In March 2007, Composite Services Architecture (CSA)
is passed on to OASIS by the Open Service Oriented
Architecture collaboration.
CSA is supported by BEA, IBM, Oracle, Sun, Tibco, Red
Hat and others.
CSA Consists of SCA (Service Component Architecture)
and SDO (Service Data Objects).
Implemented by IBM WebSphere, Oracle, Red Hat,
Tibco, and the open source Apache Tuscany.
Describes how to compose and deploy applications
supporting SOA.
Decouple business logic from details associated with the
call on that logic.
Introduces The Service Component Definition Language
(skiddle) to describe composites.
Management
2!
SCA Specifications (1)

Assembly model defining composites,
components, references and wires
Policy Framework allowing analysts to
define constraints, capabilities and
qualities of service expectations
Bindings allowing heterogeneous
transports (SOAP, JMS, IIOP,etc.)
Java annotations, APIs and component
implementation (@Remotable)
C++, BPEL, PHP, EJB and Spring for
SCA
Management
3!

The Assembly model defines
composites, components, references
and wires.
The assembly model defines how components are combined
into composites and are packaged and deployed as services.
We specify such details as encryption, authentication and
queuing outside of the business service.

Management
4!

The Policy Framework allows analysts to
define constraints, capabilities and
qualities of service expectations.
WSDL does not support the description of policies.
The SCA Policy Framework uses WS-Policy and
WS-PolicyFramework to describe policies for service
users.
From www.osoa.org:
Business value: The ability to define policies outside the
services themselves lets administrators set and change
the policies without changing code. It also means administrators
know their policies are implemented globally.
Management
5!

Bindings allow heterogeneous
transports (SOAP, JMS, IIOP,etc.) to be
used.
From www.osoa.org:
Bindings specify the mechanisms to access particular kinds
of components. Applications built with SCA can use Web
services, JMS, JCA and EJBs. (More bindings are on the way
from osoa.org.) As you would expect, the bindings can be
defined outside the code itself.
Business value: The bindings provided in SCA allow
developers to use a wide variety of services without
knowing the details of how those services are accessed.
With the bindings external to the code, the bindings can be
changed without changing the code.
Management
6!
SCA Components (1)

properties
services
Implemented in BPEL, Java,
C++, etc.
This may also be a composite.

Management
references
<component>
<implementation>
<service>
<binding>
<property>
<reference>
<binding>
</component>
7!
SCA Components (2)

properties
services
Implemented in BPEL, Java,
C++, etc.
This may also be a composite.
<component>
<implementation>
<service>
<property>
<reference>
</component>
references
has a name and list of policy intents

has a name and an implementation type
has an interface and a binding
names and values to be passed in
includes a binding

Management
8!
SCA Components (3)

Property values passed in at runtime.
services
Operations
available to
clients.
Business logic
Implementation
Other
services
this client
depends
on.
references
Dependency injection: The SCA runtime performs a lookup for the

reference. The business logic need not be concerned with how the
other service is accessed.
Nor is the business logic developer concerned with how this component
is accessed. That detail is specified as a binding - outside of the business
logic.
Management
9!
SCA Components (4)

<composite>
A component is the atom of an SCA

application. It lives within a composite.
<service>
<property>
A component is a configured
<reference>
implementation.
<wire>
<component>
SCA is language agnostic.
<implementation>
<service>
SCDL defines how the component
<property>
interacts with the outside world.
<reference>
</component>
A component might talk to other
components within its own domain or
<more components > outside of its own domain.
:
</composite>
An SCA runtime knows what to do with
this.
10!
Management
SCA Components Quiz (1)

<component name=Component1>
<implementation.java class=services.examples.Calc>
<service name=AS>
<binding.ws uri=http://www.myserve.com/service/>
</service>
<property name=initValue>0</property>
<reference name=MonitorService>
<binding.ws uri=http://www.etc.com/service/>
</reference>
</component>
What can we say about the component being
defined?

Management
11!
SCA Components Quiz (2)

<component name=Component2>
<implementation.bpel process=CalcProcess>
<service name=AS>
<binding.ws uri=http://www.myserve.com/service/>
</service>
<property name=initValue>0</property>
<reference name=MonitorService>
<binding.ws uri=http://www.etc.com/service/>
</reference>
</component>
And this one?
Other bindings include binding.jms and binding.ejb.
Management
12!
SCA Composites (1)

properties
services
wire
wire
references

Management
13!
SCA Composites (2)

Components
properties
services
wire
wire
references

Management
14!
SCA Composites (3)

Perhaps implemented
in BPEL.
properties
Perhaps implemented
in Java.
services
wire
wire
references

Management
15!
SCA Composites (4)

How this communication
is done may be left up to the
SCA runtime.
properties
services
wire
wire
references

Management
These may run on different

machines.
16!
SCA Composites (5)

reference
properties
services
wire
wire
references
service
A wire is an abstract representation

of the relationship between a
reference and some service that
meets the needs of that reference.

Management
17!
SCA Composites in Skiddle

A composite solves a business problem.
<composite>
<service>
<property>
<reference>
<wire>
<component>
<implementation>
<service>
<property>
<reference>
</component>
<more components >
:
</composite>
Contains binding information.

Contains binding information.
A wire connects components.
Components may live in different
processes or on different machines.
Components might be written in Java,
BPEL or some other language.
A composite may be used as a component
in a higher-level assembly.
A composite does not cross domain

boundaries.
18!
Management
SCA Domains
Contain one or more composites.
May cross machine and process
boundaries.
Are each managed by a single
group of people.
Run on a single vendors SCA
runtime.
Place no restrictions on how
internal communication is done.
Management
19!
SCA Bindings
Bindings specify how one component
communicates with another.
A single component may have multiple
bindings.
The use of bindings separate what a
component does from how we
communicate with it.

Management
20!
SCA Services, References

& Properties
Components expose one or more services.
How the services are described depends on
the technology.
Descriptions for clients in other domains
would typically use interoperable WSDL.
A service provides some number of
operations.
If a component uses other services then
these are described with references.
Properties are values taken from the SCDL
and describe the world to the component.
Management
21!
SCA Summary
From www.osoa.org:
As your SOA becomes more complex, you'll need the
simplicity and flexibility of SCA. The Service Component
Architecture helps you:
Save time and money - A simpler API means a shorter
learning curve with fewer errors.
Enable and encourage reuse - Developers can create
composites that perform useful functions. SCA makes it easy
to use and reuse them.
Manage your system - Because policies can be defined outside
the code that performs the service, you can change the
policies without changing the code.

Management
22!
Service Data Objects

(SDO)
A specification to unify data programming
across heterogeneous data sources.
May be used by SCA to interact with data
sources.
Several competing approaches exist in the
Java persistence API space.
SDO is more mature and general than
Javas Persistence API (JPA).
SDO is not Java specific, e.g., has support in
PHP.

Management
23!
Service Data Objects

(SDO)
Typical data sources include:
JDBC
Entity EJBs
Web Services
XML sources
JMS messages
Enterprise Information Systems
through J2EE Connector Architecture

Management
24!
Goals of SDO
To simplify the life of the application
developer.
To provide new opportunities for tools
and frameworks to work with a wide
variety of data sources.
Thus, we see support for both static
(account.getBalance()) and dynamic
(resultSet.getFloat(BALANCE)) data
APIs. One for programmers the other
for tools.
Management
25!
SDO Architecture (1)
Based on disconnected data

graphs and optimistic concurrency
(OC).
One DAS may
client
OC: If any change occurs on the
backend while the client is making
changes, a subsequent attempt to
update must be rejected. The client
would then need to take appropriate
action. Pessimistic concurrency locks
resources. OC is preferred if concurrent
access is rare.
Management
Data Access work with

Service (DAS) RDBMS and
another may
work with
XML etc.
Data Source
The DAS
creates the
graph of
data
objects.
26!
SDO Architecture(2)
Data Objects hold the data and metadata.
Data Objects have rich relationship support.
The Data Graph logs every change to the data.
client
Data Access
Service (DAS)
Xpath is used to dynamically

select data objects from the
data graph.
Management
Data Source
27!
SDO Architecture(3)
Data Access Services come in various forms:
Relational
Data
Access
Service
client
EJB Data
Access
Service
XML Data
Access
Service
Management
28!
SCA and JBI

See article by Mike Edwards (IBM)
at http://www.osoa.org/display/Main/Relationship+of+SCA+and+JBI
How does SCA differ from JBI?
JBI stands for Java Business Integration
JBI defines a set of of Service Provider Interfaces for
middleware providers to implement if they want to
install new service engines (SCA implementation types)
or binding components (SCA bindings).
SCA is for developers, assemblers and deployers of
business services. SCA says nothing about how new
implementation types or new bindings might be
introduced.
JBI is for middleware vendors. SCA is for business
developers.
Management
29!
SCA and JBI Bottom Line

See article by Mike Edwards (IBM)
at http://www.osoa.org/display/Main/Relationship+of+SCA+and+JBI
JBI should be considered a Java technology that
potentially helps middleware vendors to implement
SCA. JBI and SCA do not compete or conflict with each
other.
SCA, on the other hand, allows multiple technologies
to be used to implement services( e.g. Java, BPEL, C+
+) and multiple bindings to communicate with services
(e.g. web services, JMS).
Management
30!

SCA and SDO

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SCA and SDO

Загружено:

Авторское право:

Доступные форматы

Service Oriented

SCA Specifications (1)

SCA Specifications (2)

95-843: Service Oriented Architecture

SCA Specifications (3)

SCA Specifications (4)

SCA Components (1)

95-843: Service Oriented Architecture

SCA Components (2)

has a name and list of policy intents

95-843: Service Oriented Architecture

SCA Components (3)

Dependency injection: The SCA runtime performs a lookup for the

SCA Components (4)

A component is the atom of an SCA

SCA Components Quiz (1)

95-843: Service Oriented Architecture

SCA Components Quiz (2)

SCA Composites (1)

95-843: Service Oriented Architecture

SCA Composites (2)

95-843: Service Oriented Architecture

SCA Composites (3)

95-843: Service Oriented Architecture

SCA Composites (4)

95-843: Service Oriented Architecture

These may run on different

SCA Composites (5)

A wire is an abstract representation

95-843: Service Oriented Architecture

SCA Composites in Skiddle

Contains binding information.

A composite does not cross domain

95-843: Service Oriented Architecture

SCA Services, References

95-843: Service Oriented Architecture

Service Data Objects

95-843: Service Oriented Architecture

Service Data Objects

95-843: Service Oriented Architecture

SDO Architecture (1)

Based on disconnected data

Data Access work with

Xpath is used to dynamically

SCA and JBI

SCA and JBI Bottom Line

Вам также может понравиться