Service Oriented Architecture

1
Service Oriented Architecture

• Lecture 10 Composite Services Architecture (CSA)

Sources www.osoa.org SOA for the Business
Developer by Margolis Introducing SCA by
Chappell
2
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.

3
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 (_at_Remotable)
• C, BPEL, PHP, EJB and Spring for SCA

4
SCA Specifications (2)

• 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.

5
SCA Specifications (3)

• 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. 
5
Master of Information System Management
6
SCA Specifications (4)

• 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. 
6
Master of Information System Management
7
SCA Components (1)
properties
services
Implemented in BPEL, Java, C, etc. This may
also be a composite.
references
ltcomponentgt ltimplementationgt
ltservicegt ltbindinggt
ltpropertygt ltreferencegt
ltbindinggt lt/componentgt
8
SCA Components (2)
properties
services
Implemented in BPEL, Java, C, etc. This may
also be a composite.
references
ltcomponentgt has a name and
list of policy intents ltimplementationgt
has a name and an implementation type
ltservicegt has an interface and
a binding ltpropertygt
names and values to be passed in
ltreferencegt includes a
binding lt/componentgt
9
SCA Components (3)
Property values passed in at runtime.
Other services this client depends on.
services
Business logic Implementation
Operations available to clients.
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.
10
SCA Components (4)
ltcompositegt ltservicegt ltpropertygt
ltreferencegt ltwiregt ltcomponentgt
ltimplementationgt ltservicegt
ltpropertygt ltreferencegt
lt/componentgt ltmore components gt
lt/compositegt
A component is the atom of an SCA application.
It lives within a composite. A component is a
configured implementation. SCA is language
agnostic. SCDL defines how the
component interacts with the outside world. A
component might talk to other components within
its own domain or outside of its own domain. An
SCA runtime knows what to do with this.
11
SCA Components Quiz (1)
ltcomponent nameComponent1gt
ltimplementation.java classservices.examples.Calc
gt ltservice nameASgt
ltbinding.ws urihttp//www.myserve.com/service/gt
lt/servicegt ltproperty
nameinitValuegt0lt/propertygt
ltreference nameMonitorServicegt
ltbinding.ws urihttp//www.etc.com/service/gt
lt/referencegt lt/componentgt
What can we say about the component being defined?
12
SCA Components Quiz (2)
ltcomponent nameComponent2gt
ltimplementation.bpel processCalcProcessgt
ltservice nameASgt
ltbinding.ws urihttp//www.myserve.com/service/gt
lt/servicegt ltproperty
nameinitValuegt0lt/propertygt
ltreference nameMonitorServicegt
ltbinding.ws urihttp//www.etc.com/service/gt
lt/referencegt lt/componentgt
And this one?
Other bindings include binding.jms and
binding.ejb.
13
SCA Composites (1)
properties
services
wire
wire
references
14
SCA Composites (2)
properties
Components
services
wire
wire
references
15
SCA Composites (3)
properties
Perhaps implemented in BPEL.
Perhaps implemented in Java.
services
wire
wire
references
16
SCA Composites (4)
How this communication is done may be left up to
the SCA runtime.
properties
services
wire
wire
references
These may run on different machines.
17
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 meets the needs of that reference.
service
18
SCA Composites in Skiddle
A composite solves a business problem.
ltcompositegt ltservicegt ltpropertygt
ltreferencegt ltwiregt ltcomponentgt
ltimplementationgt ltservicegt
ltpropertygt ltreferencegt
lt/componentgt ltmore components gt
lt/compositegt
Contains binding information. Contains binding
information. A wire connects components. Component
s 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.
19
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.

20
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.

21
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.

22
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. 

23
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.

24
Service Data Objects (SDO)

• Typical data sources include
• JDBC
• Entity EJBs
• Web Services
• XML sources
• JMS messages
• Enterprise Information Systems
• through J2EE Connector Architecture

25
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.

26
SDO Architecture (1)

• Based on disconnected data graphs and optimistic
  concurrency (OC).

One DAS may work with RDBMS and another may work
with XML etc.
Data Access Service (DAS)
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.
The DAS creates the graph of data objects.
Data Source
27
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 Service (DAS)
client

• Xpath is used to dynamically
• select data objects from the
• data graph.

Data Source
28
SDO Architecture(3)

• Data Access Services come in various forms

Relational Data Access Service
client
EJB Data Access Service
XML Data Access Service
29
SCA and JBI

• See article by Mike Edwards (IBM)
• at http//www.osoa.org/display/Main/Relationsh
  ipofSCAandJBI
• 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.

30
SCA and JBI Bottom Line

• See article by Mike Edwards (IBM)
• at http//www.osoa.org/display/Main/Relationsh
  ipofSCAandJBI
• 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).