SCA and SDO PDF

Service Oriented
Architecture
Lecture 10: Composite Services
Sources: Architecture (CSA)
www.osoa.org
SOA for the Business Developer by Margolis
Introducing SCA by Chappell
95-843: Service Oriented Architecture
Master of Information System 1!
Management
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
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
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
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
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
SCA Components (1)
properties
services
Implemented in BPEL, Java,

C++, etc.
This may also be a composite.
references
<component>
<implementation>
<service>
<binding>
<property>
<reference>
<binding> 7!
Master of Information System
Management </component>
SCA Components (2)
properties
services
Implemented in BPEL, Java,

C++, etc.
This may also be a composite.
references
<component> has a name and list of policy intents

<implementation> has a name and an implementation type
<service> has an interface and a binding
<property> names and values to be passed in
<reference> includes a binding
</component>
Management
SCA Components (3)
Property values passed in at runtime.
services Other
services
Operations Business logic this client
available to Implementation depends
clients. 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
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.
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
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
SCA Composites (1)
properties
services
wire wire
references

Management
SCA Composites (2)
properties
Components
services
wire wire
references

Management
SCA Composites (3)
Perhaps implemented properties Perhaps implemented
in BPEL. in Java.
services
wire wire
references

Management
SCA Composites (4)
How this communication
properties is done may be left up to the
SCA runtime.
services
wire wire
references
These may run on different

Master of Information System
machines. 16!
Management
SCA Composites (5)
reference
properties
services
wire wire
references
A wire is an abstract representation

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

Management
SCA Composites in Skiddle
A composite solves a business problem.
<composite>
<service> Contains binding information.

<property>
<reference> Contains binding information.
<wire> A wire connects components.
<component> Components may live in different
<implementation> processes or on different machines.
<service>
<property>
Components might be written in Java,
<reference> BPEL or some other language.
</component>
A composite may be used as a component
<more components >
in a higher-level assembly.
:
</composite> A composite does not cross domain
boundaries.
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
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
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
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
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
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
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
SDO Architecture (1)
Based on disconnected data
graphs and optimistic concurrency
(OC). One DAS may
Data Access work with
client Service (DAS) RDBMS and
another may
work with
OC: If any change occurs on the XML etc.
backend while the client is making
changes, a subsequent attempt to
update must be rejected. The client The DAS
would then need to take appropriate Data Source creates the
action. Pessimistic concurrency locks graph of
resources. OC is preferred if concurrent data
access is rare. objects.
Management
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.
Data Access
client Service (DAS)
Xpath is used to dynamically

select data objects from the Data Source
data graph.

Management
SDO Architecture(3)
Data Access Services come in various forms:
Relational
Data
Access
Service
client
EJB Data
Access
Service
XML Data
Access
Service
Management
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
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

SCA and SDO PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SCA and SDO PDF

Caricato da

Copyright:

Formati disponibili

Service Oriented

The assembly model defines how components are combined

We specify such details as encryption, authentication and

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

Implemented in BPEL, Java,

Implemented in BPEL, Java,

<component> has a name and list of policy intents

Dependency injection: The SCA runtime performs a lookup for the

What can we say about the component being

95-843: Service Oriented Architecture

And this one?

Other bindings include binding.jms and binding.ejb.

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

These may run on different

A wire is an abstract representation

95-843: Service Oriented Architecture

<service> Contains binding information.

95-843: Service Oriented Architecture

As your SOA becomes more complex, you'll need the

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

95-843: Service Oriented Architecture

Xpath is used to dynamically

95-843: Service Oriented Architecture

JBI should be considered a Java technology that

SCA, on the other hand, allows multiple technologies

95-843: Service Oriented Architecture

Potrebbero piacerti anche