seminar on service oriented architecture n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Seminar on Service Oriented Architecture PowerPoint Presentation
Download Presentation
Seminar on Service Oriented Architecture

Loading in 2 Seconds...

play fullscreen
1 / 30

Seminar on Service Oriented Architecture - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

Seminar on Service Oriented Architecture. Composite Services Architecture (CSA). Sources: www.osoa.org “SOA for the Business Developer” by Margolis “Introducing SCA” by Chappell. Composite Services Architecture (CSA).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Seminar on Service Oriented Architecture' - nelia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
seminar on service oriented architecture

Seminar on Service Oriented Architecture

Composite Services Architecture (CSA)

Sources:

www.osoa.org

“SOA for the Business Developer” by Margolis

“Introducing SCA” by Chappell

SOA Seminar

composite services architecture csa
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.

SOA Seminar

sca specifications 1
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, API’s and component implementation (@Remotable)
  • C++, BPEL, PHP, EJB and Spring for SCA

SOA Seminar

sca specifications 2
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.

SOA Seminar

sca specifications 3
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

SOA Seminar

Master of Information System Management

sca specifications 4
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

SOA Seminar

Master of Information System Management

sca components 1
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>…

</component>

SOA Seminar

sca components 2
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>

SOA Seminar

sca components 3
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.

SOA Seminar

slide10

SCA Components (4)

<composite>

<service>

<property>

<reference>

<wire>

<component>

<implementation>

<service>

<property>

<reference>

</component>

<more components >

:

</composite>

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.

SOA Seminar

slide11

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?

SOA Seminar

slide12

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.

SOA Seminar

sca composites 1
SCA Composites (1)

properties

services

wire

wire

references

SOA Seminar

sca composites 2
SCA Composites (2)

properties

Components

services

wire

wire

references

SOA Seminar

slide15

SCA Composites (3)

properties

Perhaps implemented

in BPEL.

Perhaps implemented

in Java.

services

wire

wire

references

SOA Seminar

sca composites 4
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.

SOA Seminar

sca composites 5
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

SOA Seminar

sca composites in skiddle
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.

SOA Seminar

sca domains
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 vendor’s SCA runtime.
  • Place no restrictions on how internal communication is done.

SOA Seminar

sca bindings
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.

SOA Seminar

sca services references properties
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.

SOA Seminar

sca summary
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. 

SOA Seminar

service data objects sdo
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 Java’s Persistence API (JPA).
  • SDO is not Java specific, e.g., has support in PHP.

SOA Seminar

service data objects sdo1
Service Data Objects (SDO)
  • Typical data sources include:

JDBC

Entity EJB’s

Web Services

XML sources

JMS messages

Enterprise Information Systems

through J2EE Connector Architecture

SOA Seminar

goals of sdo
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 API’s. One for programmers the other for tools.

SOA Seminar

sdo architecture 1
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

SOA Seminar

sdo architecture 2
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

SOA Seminar

sdo architecture 3
SDO Architecture(3)
  • Data Access Services come in various forms:

Relational

Data

Access

Service

client

EJB Data

Access

Service

XML Data

Access

Service

SOA Seminar

sca and jbi
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.

SOA Seminar

sca and jbi bottom line
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).”

SOA Seminar