JAIST Repository
https://dspace.jaist.ac.jp/

Title

Evolution of software composition mechanisms

Author(s)Ghezzi, Carlo

CitationIssue Date

2005‑03‑11

Type

Presentation

Text version

publisher

URL

http://hdl.handle.net/10119/8275

RightsDescription

JAIST 21世紀COEシンポジウム2005「検証進化可能電子社会」 = JAIST 21st Century COE Symposium 2005
Verifiable and Evolvable e‑Society , 開催
：2005年3月10日〜11日, 開催場所：石川ハイテク交流センター, Technical session 4 <Modelling and
Evolution>

Japan Advanced Institute of Science and Technology

Outline
 Historical evolution of composition

Evolution of software
composition mechanisms

mechanisms for software– From monolithic to highly decentralized– From static to highly dynamic
 Evolution at “product level” in parallel with

Carlo Ghezzi
Dipartimento di Elettronica e
Informazione
Politecnico di Milano, Italy
carlo.
carlo.ghezzi@polimi.it
ghezzi@polimi.it
COE Symposium, March 2005

evolution of “process level”

 Challenges
 Some research directions
 Conclusions
1

COE Symposium, March 2005

The concept of binding

More on binding Architecting software requires defining Binding occurs at all levels

relationships among elements

2– programming level

 Relationships define the a variable refers to its type, value, scope…
 a subclass refers to its parent classlogical/physical structure Binding is the establishment of a
relationship– component level a component refers to other components

through a use relationshipthe focus here is on binding as a the gluing mechanism among components
COE Symposium, March 2005

3

COE Symposium, March 2005

Binding time andpersistence

Evolution thread When is the binding established?

 Continuous evolution to accommodate

increasing degrees of– typical distinction between runrun-time and"pre" runrun-time– dynamicity– decentralization

 How stable is the established binding?

– can it change?
– how does it change?

to achieve flexibility
 Concurrent evolution at theprocess/organizational/business level explicit
 automatic
COE Symposium, March 2005

4

5

COE Symposium, March 2005

61

Early days:
the “static” scenario (1)Early days:
the “static” scenario (2) The closed,
closed, static , centralized , fixed Responseworld assumption– The waterfall process model– requirements are there Refinement, from clearly and fully specified

 just elicit them rightrequirements down to code

– they are stable TopTop-down development Æ formal deductive

 if not, we got them wrong

approaches– changes should be avoided– static and centralized system compositions,frozen at design time
– monolithic, systematic, toptop-down processes
COE Symposium, March 2005

– Programming languages and methods
producing static verifiable architectures
 static binding Æ static type checking
7

COE Symposium, March 2005

Early days:
the “static” scenario (3)8interfaceinterfaceecch Software structurekcomponent(module)ecchk– From monolithic
 Changes implied recompilation– To separately compiled parts

interfaceinterface Linked statically and then loaded Changes required partial recompilations– Interface separated from implementation
 From FORTRAN to Ada
COE Symposium, March 2005

9

COE Symposium, March 2005

General lessons learned

Initial solutions

 Requirements cannot be fully gathered Evolutionary process models

upfront
 Requirements cannot be frozen
 Requirements intrinsicallydecentralized, complete control andprepre-plan illusory When changed, impact whole
product/process
product/process
COE Symposium, March 200510

– Spiral, prototypingprototyping-based Design for change– Information hiding– Careful distinction between

 specification & implementation
 interface & body Object oriented design and languages– Accommodate limited anticipated productchanges– Towards an open world

11

COE Symposium, March 2005

122

OO design

Design for change

Polymorphism

interfacevisible to clients

interfacestablebody

volatile

encapsulates
modifiable
design choices

Fax f
body

∆-interface∆-bodyDynamic binding
COE Symposium, March 2005

13

Open world and typesafetyf.sendFax();14

COE Symposium, March 2005

Binding may crossnetwork boundaries

 New subclasses (and new objects) definedas the system is running Æ methods
invoked may become known at run time If changes are anticipated and changes canbe cast in the subclass mechanism, dynamic
evolution and dynamic binding can coco-exist
with static checking (and type safety)

COE Symposium, March 2005

15

serverserverRMI
RMI

clientclientcode
code base
base

COE Symposium, March 2005

Conceptual tools

The “components”
scenario Distinguish between logical structure Systems not developed from scratch,and physical structure

but rather out of existing parts– modularity vs.
vs. allocation– Decentralized developments

 The goal of a seamless transition from

centralized to decentralized
deployment

COE Symposium, March 200516

 BottomBottom-up integration vs.
vs. toptop-down

decomposition– ComponentComponent-based development

17

COE Symposium, March 2005

18

3

Gluing software
becoming dominant

Middleware Distinction between components andconnectors
 Wrappers for components
 Middleware provides binding mechanisms

QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.

– Middleware as a decoupling layer separation of concerns– separate component logic from intricacies ofcommunication/cooperation

COE Symposium, March 2005

19

COE Symposium, March 2005

20

Decentralization
dimensions

Mobile scenarios

logical architecture With mobility the structure may

physical architecture

evolve dynamically– physical nodes may appear anddisappear Logical mobility also possible (i.e.,

software/agents migrate)– physical and logical topology may
change dynamically
COE Symposium, March 2005

business and process
model
21

Dynamicity and decentralizationin processes and organizations

22

The old world
 Product From software developed by a single

organization or by a group ofcollaborating organizations
 To components developed byindependent organizations withdifferent degrees of contractual
obligations
COE Symposium, March 2005

COE Symposium, March 2005

– monolithic– centralized– static, closed
 Process– single authority– prepre-planned– monolithic
23

COE Symposium, March 2005

24

4

A vision: the “global
computing” scenario

Achievements
 Product

Applications dynamically federated out of
distributed components, even at run time Motivations
modulardistributed
controlled dynamic binding– monolithic– centralized– static, closed– the network as a bazaar of components– mobility, ubiquitous computing– multimodality

 Process– single authority– prepre-planned– monolithic

static task decomposition
prepre-planned evolution
spiral, agile, extreme

COE Symposium, March 2005

25

This pushes dynamicity, decentralization anddistribution to unprecedented levels
 Problems range from technical to business models


COE Symposium, March 2005

Problem scale

Challenges—1

 From inin-thethe-tiny

 How to design components?

– sensor networks

 How to federate them?

 huge numbers of autonomous cooperating

 How to manage composite systems

devices(without centralized control)?
 How to reason about the “total”
quality of provided services?
 What types of business models?

 To inin-thethe-large– web services
 different scales possible

COE Symposium, March 2005

26

27

COE Symposium, March 2005

28

Service-oriented
architectures

Challenges—2
 What kind of interface should From now on, I cast my presentation

components provide in such a
fluid environment?

in the context of serviceservice-oriented
architectures in particular, web services– Interface should support establishment of“contracts
 Beyond import/export typed lists

 How to ensure a correct “global”

behavior?

– Need for new theories and models?
COE Symposium, March 2005

29

COE Symposium, March 2005

30

5

Motivation: networked
enterprises

A definition“Web services are a new breed of Web application. They
are selfself-contained,
contained, selfself-describing,describing, modular applications
that can be published,published, located,located, and invoked across theWeb. Web services perform functions, which can beanything from simple requests to complicated businessprocesses. …
Once a Web service is deployed, other applications (andother Web services) can discover and invoke the deployed
service.”

31

More on “service” (1)Component encapsulating a business function of
possible value for others– Different level granularity – coarse grained
business services vs.
vs. fine grained objects
 Services must support explicit contracts to allow
independent party accessInteracting applications
naturally belong tomultiple administrative
domains.
COE Symposium, March 200532

 Services lifecycle phases– Allow for SLAs that deal not just with functionality

Services can be the basis for service compositions– New value is created through integration andcomposition– New components are recursively created
COE Symposium, March 2005

Internal applications
seamlessly reach out of
the enterprise.

More on “service” (2)The frequency of externalinteractions and theirreach inside theenterprise increases
dramatically.

Many potential providers
can be found for eachrequired function.

IBM web service tutorial
COE Symposium, March 2005

Web based interactions
become pervasive, basedon standard protocols– specified– published– discovered– negotiated– delivered– composed– monitored

33

COE Symposium, March 2005

34

services

Types of services Atomic services:
services: run to completion without

specificationof functionaland nonfunctional
properties

interaction with service client a search service

 Service packages:
packages: logically related, notinteracting, group of atomic services
 reservation for different theatresorchestration

 Workflow services:
services: workflow includes

composition of other services– state is shared buying a book
COE Symposium, March 2005

35

workflow

COE Symposium, March 2005

36

6

Discovery and binding

Dynamic SOAs

 Design time Composite services are specified by

workflows Workflows contain abstract service
invocations
 Concrete services bound dynamically,at run time Deployment time Run time

self-organizing
behavior

unstable, evolving
environments
ubiquitous, mobile
applications

COE Symposium, March 2005

37

Dynamic SOAs

COE Symposium, March 2005

38

Service contracts
 Contracts in terms of pre and post

 Dynamic discovery and dynamic binding

conditions– the “broker” role SelfSelf-organizing, selfself-healing composite

 Exposed services specify what they

services

promise to fulfill

 Opportunities Workflows specify what they expect– enjoy use of the “best” available services– binding can be “context“context-aware”

from concrete services
 A broker negotiates a contract uponwhich a binding is established Threats– many things can go wrong
COE Symposium, March 2005

39

COE Symposium, March 2005

Threats: contracts can be
brokenConsequences We bind to a concrete service that

 Traditional good software engineering

does not satisfy its stated specification
 The bound service evolvesautonomously and breaks the contract
 The service is “temporarily down”

40

methods stress static reasoning on softwarearchitectures
 This has little value in the new world of run
time variability Improved techniques are needed to monitor
and react to unexpected deviations at runruntime– reaction can lead to selfself-healing systems

COE Symposium, March 2005

41

COE Symposium, March 2005

42

7

Monitoring

authentication

An example

profilecatalog In an open environment, reacting toabnormal behaviors is of greater importancethan in closed environments
 Recovering from problems has to do withknowing what to do when something goes
wrong. But before that we have to:credit cardbaker’spanel
phone
company

QuickTime™
QuickTime™
and aa
QuickTime™
andanda
TIFF(Uncompressed)
decompressor
TIFF(Uncompressed)
decompressor
QuickTime™
and
a
TIFF
(Uncompressed)
decompressor
are neededsee
thispicture.
needed
to to
see
this
picture.
and
TIFF(Uncompressed)
decompressor
are areneededtoQuickTime™
see
thispicture.
QuickTime™
anda a
TIFF (Uncompressed)
decompressor
areneededtosee
thispicture.
QuickTime™
and
a
are
neededtosee
thispicture.
TIFF (Uncompressed) decompressor
TIFF (Uncompressed)
decompressor
QuickTime™
aare needed
to see this andpicture.
TIFF (Uncompressed)
decompressor
are needed to see
this picture.

GPS
map

– Decide what should not go wrong– Detect if and when that happens

are needed to see this picture.

This is where monitoring comes in!
COE Symposium, March 2005

43

COE Symposium, March 2005

44

An assertion-based
approach

Monitoring

Contracts expressed interms of prepre- andpostpost-conditions
 These assertions areinserted as comments
into our process
definition
 External monitors(services)
services) are used tocheck the assertions Defensive programming– Workflow handles timeouts andexceptions raised by remote service
 External contract monitoring– Collect data
– Process data
– Notify workflow

QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.

We cast our proposal in terms of BPEL processes
COE Symposium, March 2005

45

BPEL 2 BPEL
Transformation

COE Symposium, March 2005

46

What are the advantages?
 Limited design overhead– Comments are easy to add and transformation
to a monitored BPEL process is automatic Business logic remains separate from themonitoring logic

 We stick to BPEL

– No need for a special workflow engine
 Monitor alternatives– Different implementations, possibly coco-existing
COE Symposium, March 200547

COE Symposium, March 2005

48

8

Recovery and repair
actions

Restructure Retry Workflow process as a graph– transient faults

 Graph transformation rules express

possible local changes

 Rebind– sequential composition– parallel composition– branch composition– find a suitable replacement for previous
service Restructure (local reconfiguration)– find a collection of services that satisfies
request, or merge given collection into one
COE Symposium, March 2005

49

COE Symposium, March 2005

What kind of problems
due we monitor?

Monitoring contracts

 Three different kinds of problems: An external monitor is needed to– Timeouts– External exceptions -> these can be
implementation errors in the services ormismatches between how we call theservice and how the service expects to becalled– Functional (and/or non functional)
contract enforcementenforcement-> this requires anexternal monitor service
COE Symposium, March 2005

51

monitor a functional or a nonnonfunctional contract
 We implemented two different
monitors for our assertionassertion-based
approach:– The first uses C# and .NET framework– The second uses CLIX and XlinkIt
COE Symposium, March 2005

Conclusions (1)Conclusions (2) We are moving towards unprecedented

 The global computing scenario

degrees of flexibility, dynamicity, anddecentralization at all levels
 New challenges to correctness/reliability, security, performance Crucial to understand how we can build
on previous approaches and where newones are needed
COE Symposium, March 2005

53

50

52

requires more intelligence to be
moved to run time Traditional prepre-deployment tools must
be moved to run time in a seamlessfashion– continuous testing– runrun-time verification
COE Symposium, March 2005

54

9

Our work

Our work

 We have seen an initial attempt to usedefensive programming and an
assertionassertion-based approach tomonitoring to make system partiallyselfself-healing The advantage of our approach is thatit can coexist with current “standards”
developed for SOAs
COE Symposium, March 2005

55

We developed prototypes for assertionassertion-based
monitoring and recovery mechanisms
 We are completing a second wave of prototypes thattake into account performance and usability issues
 We will address nonnon-functional properties
 We will try to achieve a better separation between
business and monitoring logic to support different
monitoring activities for different stakeholders
 Definition of more complex exception handlingroutines
COE Symposium, March 2005

56

Acknowledgments
This work is mainly funded by the EU IP SeCSE (3years project; just started) Members of the group– C. Ghezzi, L. Baresi,
Baresi, E. Di Nitto, S. Guinea and several
graduate studentsMore on this– L. Baresi,
Baresi, C. Ghezzi, S. Guinea, “Smart Monitors for
Composed Services”, Int.l
Int.l Conf. on Service Oriented
Computing, New York, Nov. 2004.
– L. Baresi,
Baresi, C. Ghezzi, and S. Guinea, “Towards SelfSelf-healing
Compositions of Services” Proceedings of PRISE'04, First
Conference on the PRInciples of Software Engineering,
November 2004, Buenos Aires, Argentina.
COE Symposium, March 2005

57

10