ServiceOriented Computing: Where does it come from a software engineering perspective

1
Service-Oriented Computing Where does it come
from?a software engineering perspective

• Carlo Ghezzi
• DEIPolitecnico di Milano
• carlo.ghezzi_at_polimi.it

2
Outline

• Historical evolution of software
  composition/structuring
• Product-level
• Process and business-level
• from monolithic to highly decentralized
• from static to highly dynamic
• Challenges to quality
• Some research directions
• Conclusions

Looking backwards
Looking forward
3
Software composition

• Giving a structure to applications and their
  development

4
The conceptual framework

• Component
• A part or element of a larger structure

• Composition
• The way in which a whole is made up, the action
  of putting things together

• Structure
• The arrangement of and relation between the parts
  or elements of something complex
• from Latin "struere", to build

• Architecture
• The complex or carefully designed structure of
  something
• The conceptual structure and logical organization
  of a computer-based system

5
The case of software

• Architecting software requires composing its
  constituents, providing structure, defining
  relations among its elements
• Relations define the logical/physical structure
• Binding is the establishment of a relation

6
Binding a key concept

• Binding occurs at all levels
• programming level
• a variable refers to its type, value, scope
• a subclass refers to its parent class
• component level
• a component refers to other components through a
  use relationship

the focus here is on binding as a the gluing
mechanism among components
7
Binding time and persistence

• When is the binding established?
• typical distinction between run-time and "pre"
  run-time
• How stable is the established binding?
• can it change?
• static vs. dynamic
• how does it change?
• explicit vs. automatic

8
Evolution thread

• Continuous evolution to accommodate increasing
  degrees of
• dynamism of bindings and compositions
• decentralization of components
• to achieve flexibility
• Concurrent evolution at the business/organizationa
  l/process level

9
Early days

• Monolythic organizations
• The closed, fixed, static , centralized world
  assumption
• Requirements are there, they are stable
• just elicit them right
• No attention to evolution
• Changes should be avoided
• they disrupt "normal" flow
• causing schedule and cost problems

10
Early day solutions

• Process level
• The sequential (waterfall) process model
• Refinement, from clearly and fully specified
  requirements down to code
• Top-down development ? formal deductive
  approaches
• Product level
• Programming languages and methods producing
  static verifiable architectures
• static and centralized system compositions,
  frozen at design time

11
Early lessons learned

• Requirements cannot be fully gathered upfront
• Requirements cannot be frozen
• Requirements intrinsically decentralized,
  complete control and pre-plan illusory
• When changed, impact whole product/process
• Evolution is intrinsic to software
• it is NOT a post-delivery nuisance

The source of change is in the world
12
Towards more flexibility

• Software structure evolution
• From monolithic
• Changes implied complete re-compilation
  re-deployment
• To separately compiled parts
• Partial re-compilations re-deployment
• Interface separated from implementation
• From FORTRAN to Ada to achieve type safety

13
Static architecture
interface
component (module)
14
Towards more flexibility

• Evolutionary process models
• Spiral, prototyping-based
• Design for change
• Information hiding
• Careful distinction between
• specification implementation
• interface body
• Object-oriented design and languages
• Accommodate limited anticipated product changes
• Towards an open world
• Aspect-oriented design and languages
• Cross-cutting concerns

15
Design for change
visible to clients
interface
stable
body encapsulates modifiable design choices
volatile
16
OO design
Polymorphism
interface
Fax
body
Fax f
Dynamic binding
f.sendFax()
17
Open world and type safety

• New subclasses (and new objects) defined as the
  system is running ? methods invoked may become
  known at run time
• If changes are anticipated and changes can be
  cast in the subclass mechanism, dynamic evolution
  and dynamic binding can co-exist with static
  checking (and type safety)

18
Binding may cross network boundaries
server
client
RMI
code base
19
Conceptual tools

• Distinguish between logical structure and
  physical structure
• modularity vs. allocation
• The goal of a seamless transition from
  centralized to decentralized deployment

20
The "components" scenario

• Systems not developed from scratch, but rather
  out of existing parts
• Decentralized developments
• Bottom-up integration vs. top-down decomposition
• Component-based development
• No control over evolution of components

21
Gluing software becoming dominant

• Distinction between components and connectors
• Wrappers for components
• Middleware provides binding mechanisms
• Middleware as a decoupling layer
• separation of concerns
• separate component logic from intricacies of
  communication/cooperation

22
Middleware
23
Mobile scenarios

• With physical mobility the structure may evolve
  dynamically
• physical nodes may appear and disappear
• ad-hoc scenarios possible where network topology
  changes dynamically
• Logical mobility also possible (i.e.,
  software/agents migrate)
• Thus physical and logical topology may change
  dynamically

24
Context changes

• Mobility generates the issue of context awareness
• Dynamic compositions needed to deal with dynamic
  context changes
• invocation of a print service binds to a printer
  based on proximity

25
Towards binding mechanisms for the open world
26
Discovery-based binding

• Possible targets register their availability
• Binding based on discovery of the target
• Registration and discovery may occur at run-time

27
(Implicit) binding via a global coordination space

• Logically global coordination space acts as a
  mediator for composition
• Components remain decoupled
• no explicit naming of target (i.e., no direct
  binding)
• The global tuple space model
• The publish-subscribe model

28
Where are we? decentralization levels
29
Where are we?

• From software developed by a single organization
  (or by collaborating organizations)
• To components developed by independent
  organizations with different degrees of
  contractual obligations

30
Where are we?

• We have been reasonably successful at taming
  change
• process level controlled evolution
• design for change
• strongly typed OO languages supporting
  polymorphism and dynamic binding
• without compromising reliability (quality) of
  computer systems

31
Achievements
The old world
Summing up

• Product
• monolithic
• centralized
• unmodifiable
• static, closed
• Process
• single authority
• pre-planned, 1 end
• monolithic

• modular
• distributed
• predefined change
• controlled dynamic changes
• hierarchical responsibilities
• "maintenance", incr. delivery
• spiral

32
Where are moving?

• Unprecedented levels of change
• business level
• process level
• product level
• Requirements for unanticipated change

New challenges for sw engineering!
33
Where are the sources of change?
(1)

• Changes originate in the business world
• agile networked organizations
• fast organizational responses to rapidly changing
  requirements
• intra and extra organization changes require
  continuous changes in the information system
• modernizing legacy systems

34
The "SoC approach"

• Service-oriented business, process and product
  architecture to support
• dynamic, goal-oriented, opportunistic federations
  of organizations
• rapidly adapting to changing requirements

35
Networked organizations
Interacting applications belong to multiple
administrative domains
Web based interactions based on standard protocols
DEI
X Inc.
Many potential providers can be found for each
required function

Foo Inc.
ICSOC
Internal applications exposed for external use
36
Where are the sources of change?
(2)

• Changes originate in the interaction with the
  physical environment
• Implied by pervasive/ubiquitous computing
  requirements
• mobility and context awareness
• ambient intelligence and disappearing computer
• external world changes unpredictably
• because context changes
• because new active objects are encountered

37
The "SoC approach"

• Support active objects providing service, such as
• taggable objects (RFID)
• sensors and sensor networks
• Ability to deal with context changes and
  unanticipated events and changes
• self-adapting, self-organizing behaviors

38
Service-Oriented Computing

• Viewed as a set of concepts and technologies
  targeting these problems

Where are the new challenges?
39
Services
specified
monitored
published
delivered
discovered
composed
negotiated
40
Challenge 1 Specification

• Services should be specified by the contract they
  will fulfill for their clients
• contract must state QoS
• not just a syntactic interface
• not just functional behavior
• Specifications must be publishable and
  discoverable

41
Challenge 2 Composition

• Services should be composable, and (in turn)
  composite services should be composable
• how is the contract of a composite service
  derived from its constituents?
• Compositions may require negotiation
• Different binding regimes should be possible,
  from static and pre-runtime to latedynamic

42
Challenge 3 Trust, verification

• Services are developed and run in their own
  domains
• no control over them, no access to the internals
• how can we trust a service contract?
• They may change without notice
• does the change affect us?
• how can trusted services be provided out of
  untrusted components?

43
Challenge 3 Trust, verification (cont.)

• Late binding adds flexibility at the expense of
  reduced safety
• We are moving from the safety of pre run-time
  structuringverification to the complete freedom
  of dynamic composition, while we are providing
  service
• we need to go beyond traditional pre run-time
  testing and validation!

44
Challenge 4 Evolution

• Compositions change to support evolution
• How can evolution be supported dynamically?
• result of detected deviation from expected QoS
• result of environment/unanticipated change
• Continuous evolution to achieve QoS
  optimizations?
• Towards self-organizing behaviors?

45
Composition dimensions
time (binding regime)
run-time
deploy-time
compile-time
change req.mts
no change
anticipated change
unanticipated change self-organization
46
Zoom-in 1

• Exploring dynamic self-checking and self-adapting
  orchestration

47
Our approach in 4 bullets

• Orchestrated composition specifies external
  services (currently by pre- and post-conditions)
• Binding to concrete services can be dynamic
• External monitors check the assertions during
  process execution
• Run-time monitoring consists of
• Collecting data
• Checking rules at run-time

48
Our prototype

• Design the process with any (visual) tool
• Import the process into the Visual Annotation
  Tool and create the Monitoring Definition File
• Assertions in WSCoL, a lightweight version of JML
• Create the instrumented version of the process
  using the BPEL2 pre-processor
• The process interacts with the Monitoring Manager
  every time monitoring is required

49
Dynamic monitoring

• Monitoring parameters associated with the process
  in execution may be changed dynamically
• To tune the trade-off between performance and
  timeliness
• Even though our weaving is done at
  deployment-time, the level of monitoring is
  modifiable at run-time

50
Self-adapting reactions

• Retry
• transient faults
• Rebind
• find a suitable replacement for previous service
• Restructure (local reconfiguration)
• find a collection of services that satisfies
  request, or merge given collection into one

51
Restructure

• BPEL process seen as a graph
• Graph transformation rules express possible local
  changes
• At this stage we consider
• split a node into a sequence
• parallel node composition
• branch composition

52
Zoom-in 2

• Exploring decentralized dynamic compositions

53
P/S decoupled composition
notification
subscription
54
The publish/subscribe paradigm

• Coordination via eventsbroker
• Strong decoupling
• no explicit naming of target (no direct binding)
• Asynchrony
• send and forget
• Location/identity abstraction
• destination determined by receiver, not sender
• Loose coupling
• actors added without reconfiguration
• multiple binding schemes
• one-to-many, many-to-one, many-to-many

55
How can design be supported?

• Main problem hard to reason about global
  behaviors and complex interactions
• does the request for a floor eventually lead the
  elevator to visit the floor?
• Required solution
• specify components and the coordination policy
• describe desirable global properties
• prove that properties hold

56
Our approach

• We cast our proposal in the UML framework
• Components as statecharts
• transitions describe how they react to incoming
  events
• Dispatcher is a predefined parametric component
• Properties described by Live Sequence Charts
• cold/hot scenarios
• must be verified by at least one/all evolutions
• Verification via model checking

57
Open issues

• Design-time analysis is not enough
• How can verification be supported dynamically?
  incrementally?

58
Zoom-in 3

• Hybrid coordination
• styles

59
Motivation

• Different coordination paradigms needed for
  different parts of a system
• Interoperability among different coordination
  middlewares needed

60
Hybrid case study

• Automotive scenario
• P/S used intra-car, discovery-based used
  extra-car and inter-car
• synchronous (Jini), asynchronous (JXTA)
• Goals
• understand hybrid systems
• support heterogeneous design-time analysis
• automatically provide bridges (adapters)

61
Conclusions what we know today is inadequate

• Open problems range from business strategies to
  software processes and service technology

62
Main (SE) challenges (1)

• Business level
• Understand the requirements of networked
  enterprises
• What is core and proprietary vs. what needs to be
  exposed integrated in dynamically evolving
  business strategies

63
Main SE challenges (2)

• Process level
• Agile methods supporting distributed workgroups
  contributing to
• the virtual information system of the networked
  enterprise
• the global marketplace of services
• no single authority is in charge

64
Main SE challenges (3)

• Product level
• Dynamic composition of components/services
  self-organizing (autonomic) behaviors
• based on QoS specification
• self-healing
• Centralized support vs. fully decentralized
  (peer-to-peer) architectures

65
Open questions become even harder (1)

• How can process be tailored to the business
  organization and to the target product?
• How can it react to changes in real time?
• How can its quality be measured?

66
Open questions become even harder (2)

• How can (un)anticipated changes be supported /
  automated?
• What mechanisms are needed?
• How can inconsistencies be managed?
• How can the required quality be defined?
• What to specify
• How to specify

67
Open questions become even harder (3)

• How can quality be assured/measured? How can we
  reason about it?
• From pre-deployment vv
• to runtime vv
• continuous monitoring and measurement
• reaction to deviations from expected quality,
  self-healing behavior

68
Acknowledgements

• Many thanks to
• Luciano Baresi
• Gianpaolo Cugola
• Elisabetta Di Nitto
• Gian Pietro Picco
• Sam Guinea
• Student

69
Short bibliography

• G. Cugola, E. Di Nitto, C. Ghezzi, M. Mantione,
  "How To Deal With Deviations
• During Process Model Enactment", ICSE 17,
  Seattle, WA, May 1995.
• G. Cugola, E. Di Nitto, A. Fuggetta, C. Ghezzi,
  "A Framework for Formalizing
• Inconsistencies in Human-Centered Systems", ACM
  Transactions on
• Software Engineering and Methodology, Sept.
  1996.
• L. Baresi, E. Di Nitto, C. Ghezzi,
  "Inconsistency and Ephemerality in a World
• of E-Services", REOS 2003, Sept. 8-12, 2003,
  Monterey, USA.
• L. Zanolin, C. Ghezzi, L. Baresi, "An Approach
  to Model and Validate
• Publish/Subscribe Architectures", SAVCBS 2003,
  Sept 1-2, 2003,
• Helsinki, Finland.
• L. Baresi, C. Ghezzi, "Validation of Component
  and Service Federations in
• Automotive Software Applications, ASWSD 2004,
  to appear LNCS.
• L. Baresi, C. Ghezzi, and S. Guinea, "Smart
  Monitors for Composed Services",
• 2nd Int.l Conf. on Service Oriented Computing.
  Nov. 2004, New York, USA.
• L. Baresi, C. Ghezzi, and S. Guinea "Towards
  Self-healing Compositions
• of Services", PRISE'04, Nov. 2004, Buenos Aires,
  Argentina.