Service Oriented Architecture

Introduction and Research Issues

2008.07.16
In-Gwon Song

ⓒ KAIST SE LAB 2008

 Contents

Introduction

Understanding service oriented architecture(SOA)
 Definitions
 Trends
 Distinct points of SOA with component based architecture
 Principles

Well-known SOA
 Web service based SOA
 OSGi

Research issues

My research framework

ⓒ KAIST SE LAB 2008 2

 Introduction(1/3)

Service Oriented Architecture(SOA)

Service
Discover Registry Register

Service Service
Requestor Service Provider
exchange
Service communication

Service

Service communication
A system built with SOA

ⓒ KAIST SE LAB 2008 3

 Introduction(2/3)

Service(Thomas Erl, Service Oriented Architecture: Concept, Technology, and Design)

 Unit of logics
• Autonomous
• Not isolated
• Evolving independently
• Commonality
• Standardized

Service oriented architecture

 Architecture built up with services

People generally use “SOA” as SOA style or SOA

pattern.

ⓒ KAIST SE LAB 2008 4

 Introduction(3/3)

What is differences with prior modular, object-oriented,

and component-based architecture?
 Thomas Erl and other people in Web Service area says
• A service is autonomous
• Services are loosely coupled
– Dynamic coupling
• A service has standardized interfaces
• A service can be discovered

ⓒ KAIST SE LAB 2008 5

 Definitions(1/3)

What is the Service Oriented Architecture?

 Service-Oriented Architecture (SOA) is an architectural style that
supports service orientation
(http://opengroup.org/projects/soa/doc.tpl?gdid=10632)

What is the Service?

 Service Science area
• Provider/client interaction that creates and captures value
• A change in condition or state of an economic entity (or thing) caused
by another
• Intangible and perishable… created and used simultaneously
• Deed, act, or performance
• All economic activity whose output is not physical product or
construction
(http://www.research.ibm.com/ssme/services.shtml)

ⓒ KAIST SE LAB 2008 6

 Definitions(2/3)

What is the Service?

 Computer Science area
• A mechanism to enable access to one or more capabilities, where the
access is provided using a prescribed interface and is exercised
consistent with constraints and policies as specified by the service
description
(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm)

• A service is an abstract resource that represents a capability of

performing tasks that represents a coherent functionality from the
point of view of provider entities and requester entities.
(http://www.w3.org/TR/ws-arch/#service)

ⓒ KAIST SE LAB 2008 7

 Definitions(3/3)

In my opinion
 Service is some activity between independent two players
• Independent two player: provider and consumer(adopter)
 Service should be loosely coupled
 Service should be autonomous
 Service can be discovered
• Activity: economicLoose
activity, interaction,
coupling and …
 Service should has internal logic
autonomy
 Service should has standardized
differentiate SOAinterfaces
from other arch.?
Separation of interface Dynamic
Internal logic and implementation binding Discoverability
Loose coupling
Standardized
Interact with unknown services Autonomy
interfaces

ⓒ KAIST SE LAB 2008 8

 Trends(1/2)

Emerging of service
 Focus of CEOs, of manufacturing companies, is moved from
reducing costs to earning more benefits
• Selling services, not only products

Needs of innovation
 Recently, innovation is essential to survive in any industry
• In service industry, service innovation is a key to earn more benefits
 Service innovation should involve innovation of Software
• Service is act, deed, or performance
• Recent service is mostly based on IT systems
– Many services involve some kind of knowledge
• Recent IT systems’ behavior is determined by Software

ⓒ KAIST SE LAB 2008 9

 Trends(2/2)

Needs of flexible software for changing business process

 Business effect for innovation
• Innovation for primitive business logics
– Very limited effect
• Innovation for business process
– Very effective
 Engineering cost with a system with old fashioned architecture
• Innovation for primitive business logics
– Low cost
• Innovation for business process
– High cost

EAI(Enterprise application Layered architecture,

Many SOA
integration) separate Composed service,
also adopt the
business process and Orchestration,
separation
business logics Choreography

ⓒ KAIST SE LAB 2008 10

 Distinct points of SOA with component based
architecture

In my opinion
 Loose couple
• Dynamic binding with service requestor/provider
 Autonomy
 Standardized interfaces
 Separation of composition layer(or service)

ⓒ KAIST SE LAB 2008 11

 Principles(1/2)

Guiding principles for building service oriented architecture

 Reuse
 Granularity
 Modularity
 Composability
 Interoperability
 Compliance to standards (both common and industry-specific)
 Services identification
 Categorization,
 Provisioning
 Delivery
 Monitoring
 Tracking
http://www-128.ibm.com/developerworks/webservices/library/ws-improvesoa/

ⓒ KAIST SE LAB 2008 12

 Principles(2/2)

Architectural principles for designing services

 Encapsulation
 Loose coupling
 Contract
 Abstraction
 Reusability
 Composability
 Autonomy
 Optimization
 Discoverability
(Thomas Erl, Service Oriented Architecture: Concept, Technology, and Design)

ⓒ KAIST SE LAB 2008 13

 Well-known SOA(1/2)

Defining standards
 Code level vs. protocol level

Service Service A Service B

Layer
Code level
Interface
Service Service Service
Container Container Container
Layer
Protocol level
Interface
Communication Communication
Channel layer Channel

ⓒ KAIST SE LAB 2008 14

 Well-known SOA(2/2)

Web service based SOA

 Scope of standard
• Define only communication protocols
– Using standard web service protocols

Service Component Architecture(SCA)

 Scope of standard
• Code-level interfaces

OSGi(Open Service Gateway Initiatives) framework
 Providing dynamic module management in embedded system
 Scope of standard
• Code-level interfaces: OSGi API
• Communication protocols: UPnP, Jini, …

ⓒ KAIST SE LAB 2008 15

 Web service based SOA(1/9)

Web service
 Remote procedure call or messaging standard based on XML and
HTTP protocol
• WSDL
• SOAP

 Extensions for supporting SOA

• WS-Coordination
• WS-BPEL (BPEL4WS)
• WS-Security
• WS-AtomicTransaction
• WS-Addressing
• ….
 Those extensions are called as WS-*

ⓒ KAIST SE LAB 2008 16

 Web service based SOA(2/9)

Composition hierarchy
 Message Exchange Pattern(MEP)
 Primitive activity
 Complex activity
• Coordination
– Atomic transaction
– Business activity
 Orchestration
 Choreography

ⓒ KAIST SE LAB 2008 17

 Web service based SOA(3/9)

Primitive activity

UDDI

Discover service Register service

WSDL

Service Service exchange Service

requestor SOAP provider

WSDL
MEP(Message Exchange Pattern)
SOAP skeleton

ⓒ KAIST SE LAB 2008 18

 Web service based SOA(4/9)

Complex service exchange

Simple service exchange
Service C

Service A Service B

Service D

Activity
 Service exchanges related to one request of client

ⓒ KAIST SE LAB 2008 19

 Web service based SOA(5/9)

Coordination
 For an activity, context information is given by coordinator
 WS-Coordinations

Activity A
Private Order
Log in
information view history view
service
service service

Using
Registering User ID Using
User ID User ID
Coordinator

ⓒ KAIST SE LAB 2008 20

 Web service based SOA(6/9)

Atomic transaction
 Using coordination, DB like transaction can be implemented
 Rollback or commit
 WS-AtomicTransaction
2. Successfully
processed 4. Fail to process
1. 3.
Service A Service B Service C

7. abort 5. abort
6. Rollback
processed matter

ⓒ KAIST SE LAB 2008 21

 Web service based SOA(7/9)

Business activity
 A kind of transaction for long-running, complex service activities
 Instead of rollback/commit, normal flow and alternative flows are
provided
 Building block of business process
 WS-BPEL

Plan A
Let’s try plan A. If Service B
that doesn’t work, Plan B
we’ll try plan B
Service A

Plan A
Service C
Plan B

ⓒ KAIST SE LAB 2008 22

 Web service based SOA(8/9)

Orchestration
 Composition of business activities
 WS-BPEL
• Contain and define business activities
• Define relation between business activities
• Can be drawn with OMG BPML(Business Process Modeling
Language)

An example drawn with BPML(Business Process Modeling Language)

ⓒ KAIST SE LAB 2008 23
 Web service based SOA(9/9)

Choreography
 Inter-organization composition of services
• While the orchestration is composition of services in a organization,
choreography is composition of services between two or more
organizations
• In a organization, many elements can be assumed or easily known

 A kind of contract
• By exchange of choreography description, the scope and
responsibility of providing services for each other are determined

 WS-CDL (Choreography Description Language)

Many researches are working on choreography

because of many constraints and its value

ⓒ KAIST SE LAB 2008 24

 OSGi framework(1/3)

Early OSGi framework

 Proposed as dynamic module(bundle) system for Java
• Install and run on demand
 Considered only for home network

Current OSGi framework
 SOA standard
• Bundle concept is very similar to the service
– Dynamic binding
– Existence of Registry
 Universal middleware for Java
• Wider participants
– Car maker BMW, Porche, …
– Equinox: plug-in lifecycle management in eclipse
– OSGi on server side

ⓒ KAIST SE LAB 2008 25

 OSGi framework(2/3)

Architecture

(from 월간 마이크로소프트 7월호)

ⓒ KAIST SE LAB 2008 26

 OSGi framework(3/3)

Bundles life cycle

If there is no bundle
for requested service

Request Bundle
a service retrieval

Bundle
otherwise Bundle
repository
install

User Provide Bundle

the service activation

Device or computer of user

ⓒ KAIST SE LAB 2008 27

Research issues: overview of SOA domains(1/3)

SOA domains

Domain Area Context Business Driver Problem space

Service Strategy Planning space

Engineering Business Operation

Cross-Cutting Concerns: Enabling Factors, Solution space
Governance, Adoption, Monitoring, Stakeholder
Management, Education, Legal, Social

Kostas Kontogiannis et al., The Landscape of Service-Oriented Systems: A Research Perspectives,

International Workshop on Systems Development in SOA Environments(SDSOA)

ⓒ KAIST SE LAB 2008 28

Research issues: overview of SOA domains(2/3)

Problem space
 Indentifying domain area, context, and business driver
 Elaborate business process

Planning space
 Establishing service strategy
• Determined with consideration for engineering, business and
operation factor
 Dealt in service science area

Solution space
 Providing solutions satisfying the service strategy
 Should be dealt in Software Engineering area

ⓒ KAIST SE LAB 2008 29

Research issues: overview of SOA domains(3/3)

Kostas Kontogiannis et al., The Landscape of Service-

Oriented Systems: A Research Perspectives,
International Workshop on Systems Development in SOA Environments(SDSOA)
 Classification of SOA domain
• Business domain
• Engineering domain
• Operation domain
• Cross cutting concerns
 23 detailed theme
 84 issues

In rest of this presentation,

several interesting issues will be covered, selectively

ⓒ KAIST SE LAB 2008 30

 Research issues: business domain(1/3)

Mapping between business process and services

 Similar to finding components in component based development

Use case Business process

Analysis modeling

Business process
Use cases
model

Finding Mapping
Components Services
components

Composition Composition

Component based development SOA

ⓒ KAIST SE LAB 2008 31

 Research issues: business domain(2/3)

Mapping between business process and services

 Distinct points
• Business process model vs. use case
• Standardized dictionary of services
– UDDI

 Issues in detail
• Service identification from business process model
• Methods for service evaluation, evaluate how well a given service fits
the business process model
• Service adaptation
– Changes of business process
– Addition of adaptation layer

ⓒ KAIST SE LAB 2008 32

 Research issues: business domain(3/3)

Management
 Distinct points w.r.t. management in component based
development
• Paid for service, not for software
• Traceability between business needs and service

 Issues in detail
• Investigation of models for contract pricing and negotiation
• Investigation of the relation between IT metrics and business metrics
• Methods, models and representations for assessing the effectiveness
of services

ⓒ KAIST SE LAB 2008 33

 Research issues: operations domain

Monitoring
 Distinct points
• Services are dynamically bound
• Loose couple
 Issues in detail
• Techniques for resource allocation and configuration management in
an SOA environment
– In most SOA system, deployment of services is hidden from client
» Automatic resource allocation is needed
» Configuration management is also needed
• Techniques and methods for self-healing feature

ⓒ KAIST SE LAB 2008 34

 Research issues: engineering domains(1/3)

Service selection
 Distinct points
• Selection criteria is relatively limited
– Reliability
– Performance
– Risk
 Detailed issues
• Identifying selection criteria for specific domain
• Service evaluation technique

ⓒ KAIST SE LAB 2008 35

 Research issues: engineering domains(2/3)

Service definition
 Distinct points
• Dynamic binding
• Standardized registry - UDDI
 Detailed issues
• Models for the syntactic and semantic description
– Standard for ontology notation

Architecture and design

 Detailed issues
• Design for run-time semantic-based discovery and composition
• Relationship between product lines and service oriented systems
• Design for personalization, context awareness and adaptation
• Communication and connectors – synchronous, asynchronous

ⓒ KAIST SE LAB 2008 36

 Research issues: engineering domains(3/3)

Implementation
 Issues in detail
• Model-driven approaches
– From BPEL, service-composition services are generated
• Transactional support, exception handling and compensation

Deployment
 Important for OSGi framework-like SOA
 Issues in detail
• Techniques for multi-platform support
• Techniques for context and location awareness support

ⓒ KAIST SE LAB 2008 37

 Research issues: other

General mechanism for supporting BPEL

 BPEL is mapped to service only for Web service
 SOA for embedded systems, like OSGi framework, also need to
reflect business process model

Techniques or method for elaboration of BPEL

 Business process model is not enough to make BPEL

Supporting various MEP(Message Exchange Pattern)

 Analysis techniques
 Consideration of MEP on selecting services

ⓒ KAIST SE LAB 2008 38

 My research framework: overview

Scenario elicitation

Finding adequate
services
Obtaining
Adaptation to
optimal
Until optimal
scenarios Elicitation of scenario
services
services found Estimation new specification for
development cost new development

Deriving scenarios
specification for
new developments

Deriving
Newly developed Found
composition Deriving
services services
specification
composition specification
from scenario specification
Composition

ⓒ KAIST SE LAB 2008 39

 My research framework: elicitation of scenario
specification for new development
Specifying Scenarios Assume all message exchange as synchronous

Implied scenario
detection/removal

Partitioning scenario Until appropriate cost

entities into services
UDDI WS-Policy Deriving scenarios
Finding appropriate specification for
Ontology services WS-Metadata new development

Inserting Substituting entities Substituting Derived scenarios

Derived service
coordination to services for messages for new
level scenarios
entities services found w.r.t. MEP development

Implied scenario
detection/removal

Deriving scenarios
for parts which would
be newly developed

New development
cost estimation MEP: Message Exchange Pattern

ⓒ KAIST SE LAB 2008 40

 My research framework: deriving composition
specification from scenario specification

Derived scenarios
Derived service
for new
level scenarios
development

Development Deriving
composition Foster’s work
specification
Testing

Newly developed
WS-BPEL WS-CDL
services

Found services

Services of our
Orchestration
company

Services of
Choreography
other company

ⓒ KAIST SE LAB 2008 41

 Summary

Distinct points of SOA

 Loose couple
• Dynamic binding
• Discoverability
 Autonomy
 Standardized interfaces
 Separation of composition layer(or service)

Research issues
 Very immature area
 Needs for adaptation of prior approaches
 Needs for consideration of service science

ⓒ KAIST SE LAB 2008 42