Coordination: - PowerPoint PPT Presentation

About This Presentation
Title:

Coordination:

Description:

failure by reconfiguring themselves (self-healing)... The real-time economy... rule now is as simple as reconfiguring the system by replacing the regulator. ... – PowerPoint PPT presentation

Number of Views:29
Avg rating:3.0/5.0
Slides: 47
Provided by: josluizf
Category:

less

Transcript and Presenter's Notes

Title: Coordination:


1
Architecture-based Evolutionof Software Systems
Architecture-based Evolutionof Software Systems
José Luiz Fiadeiro
2
Coping with change
  • In Business Systems today, change is the rule of
    the game
  • The Web is only fuelling the rate of change
    (B2C, B2B, P2P,)
  • Critical infrastructures depend on the ability to
    react to failure by reconfiguring themselves
    (self-healing)
  • The real-time economy
  • Complexity is now on evolution

3
Coping with change
  • In Business Systems today, change is the rule of
    the game
  • The Web is only fuelling the rate of change
    (B2C, B2B, P2P,)

" the ability to change is now more important
than the ability to create e-commerce systems
in the first place. Change becomes a first-class
design goal and requires business and technology
architecture whose components can be added,
modified, replaced and reconfigured". P.Finger,
"Component-Based Frameworks for E-Commerce",
Communications of the ACM 43(10), 2000, 61-66.
  • Critical infrastructures depend on the ability to
    react to failure by reconfiguring themselves
    (self-healing)
  • The real-time economy
  • Complexity is now on evolution

Any ideas on how to incorporate this new
requirement?
4
Architectures?
Requirements
5
The challenge
  • Reflect on the (run-time) architecture of the
    system the different levels of change that can
    take place in the application domain.
  • Support evolution through dynamic
    reconfiguration, without interruption of service,
    minimising impact on the global system.

6
The CCC approach
  • A confluence of contributions from
  • Coordination Languages and ModelsSeparation
    between computation and coordination
  • Software ArchitecturesConnectors as first-class
    citizens
  • Parallel Program DesignSuperposition

7
The CCC approach
  • The Strategy
  • Recognize that change in the application domain
    occurs at different levels

8
The CCC approach
  • Distinguish Computation Resources
  • Units that model core business/domain entities
    and provide services through computations
    performed locally
  • These tend to be stable components, for which
    modifications imply major re-engineering

9
The CCC approach
  • from Coordination Resources

Units that model volatile business rules and
processes and can be superposed, at run time, on
the core units to
  • coordinate their interactions
  • regulate their behaviour
  • adapt their behaviour
  • monitor their behaviour

10
The CCC approach
  • The Strategy
  • Recognize that change in the application domain
    occurs at different levels
  • Reflect these levels in the architecture of the
    system

11
The CCC approach
  • Change-oriented layered architecture

12
The CCC approach
  • The Strategy
  • Recognize that change in the application domain
    occurs at different levels
  • Reflect these levels in the architecture of the
    system
  • Manage evolution according to the architecture.

13
The CCC approach
  • The Configuration Layer

Services that model business activities and
through which the system can be configured, at
run-time, to provide the response that is
required.
These services can be either invoked by
authorized users or triggered by events
(self-adaptation).
  • Computation
  • Resources
  • Coordination
  • Resources

The running system
14
The CCC approach
  • Semantic primitives for Coordination
  • Semantic primitives for Configuration
  • Full mathematical semantics
  • A micro-architecture for deployment over
    platforms for component-based development
  • An instantiation of this micro-architecture for
    Java components the Coordination Development
    Environment (CDE)

15
OO is generating legacy
  • What is intrinsically wrong with OO
  • Feature calling, the basic mechanism through
    which objects interact, is identity-based
    objects call specific features of specific
    objects (clientship)
  • As a result, any change on the interactions is
    intrusive on the code of the object.
  • We propose a way for interactions to be
    externalised and handled as first-class citizens.

16
externalisation ?
  • Superposition captured through morphisms and
    universal constructions (colimits)
  • Configurations modelled as diagrams, and
    reconfiguration through graph-rewriting
  • Separation between computation and coordination
    captured through functors that map systems to
    coordination interfaces

17
Changing the business rule credit is allowed on
withdrawals up to a limit
CommUnity
prog Simple-account out num, bal int in n
int do dep ? balbaln wit baln ?
balbaln
A program in CommUnity
How can we characterise the change?
What is the relationship between the two programs?
  • prog VIP-account
  • out num, bal, cred int
  • in n int
  • do dep ? balbaln
  • wit balcredn ? balbaln

18
Superposition
prog Simple-account out num, bal int in n
int do dep ? balbaln wit baln ?
balbaln
This program is a superposition of a business
rule over a more basic service
prog Account out num, bal int in n int do dep
? balbaln wit ? balbaln
Superposition morphismOut1 ?Out2In1 ? In2
Out2Act2 /?Act1Types are preservedGuards
cannot be weakenedAssignments are preserved
The change is intrusive
prog VIP-account out num, bal, cred int in n
int do dep ? balbaln wit balcredn ?
balbaln
The same applies to the VIP-account for a
different business rule
19
Superposing the business rule
Externalising the business rule
prog Account out num, bal int in n int do dep
? balbaln wit ? balbaln
prog Simple-account out num, bal int in n
int do dep ? balbaln wit baln ?
balbaln
prog Regulator in  r1 int   r2 int do reg
r1r2 ?
The business rule can be externalised as a
first-class object a regulator.
The superposition of the business rule can now be
achieved by interconnecting the regulator and the
base program.
The regulator is capable of reading two values r1
and r2 from the environment and provides an
action that blocks when r1ltr2.
and morphisms that allow the regulator to read
the balance in r1
and the requested amount in r2
and synchronise with withdrawals, blocking them
when the values read do not satisfy the guard
prog Channel in  a int   b int do  c
The interconnection itself is performed through a
channel
20
Categorical semantics
The semantics of the configuration is the
parallel composition of its components as
interconnected through the morphisms.Intuitively
, this should correspond to the original
simple-account.
Parallel composition is computed through a
categorical construction a colimit of the
configuration diagram.For diagrams of this
particular form, a colimit is called a pushout.
In the previous slide, we built a diagram in the
category of CommUnity programs and superposition
morphisms.This diagram depicts a system
configuration.
21
Execution semantics
  • Each action of the channel defines a
    synchronisation set and provides an explicit
    representation of an interaction within the system
  • Each synchronisation set is executed atomically
  • and is guarded by the conjunction of the guards
    of the participating actions
  • and performs the parallel composition of the
    assignments.

22
Evolving the business rule
Changing the business rule now is as simple as
reconfiguring the system by replacing the
regulator. It does not require any changes to be
performed on Account and does not interfere with
the rest of the system
prog VIP-Regulator out cred int in  r1
int   r2 int do reg r1credr2 ?
prog Account out num, bal int in n int do dep
? balbaln wit ? balbaln
prog Regulator in  r1 int   r2 int do reg
r1r2 ?
prog Channel in  a,b int do  c
23
The CCC approach
  • A confluence of contributions from
  • Coordination Languages and ModelsSeparation
    between computation and coordination
  • Software ArchitecturesConnectors as first-class
    citizens
  • Parallel Program DesignSuperposition
  • Reconfigurable Distributed SystemsDynamic
    (run-time) reconfiguration

24
Semantic primitives for coordination
  • Coordination laws that provide abstract models of
    services in terms of reactions to be performed
    upon detection of triggers.
  • Coordination interfaces that identify the types
    of components that can instantiate the service as
    a law.
  • Coordination contracts that provide services as
    concrete coordination units obtained by
    instantiating laws through the binding of the
    interfaces to the public interfaces of given
    components.

25
Services (types) as coordination laws
coordination law standard-withdrawal partners
aaccount-debit ccustomer-withdrawal rul
es when c.withdrawal(n,a)
with a.balance()n do a.debit(n) end law
Operations that can be called within the law as
part of joint actions
Events that need to be observed to provide
triggers .
The reaction a joint action in which the
partners and local actions of the law can
participate executed as a synchronisation set
26
Just-in-time integration
coordination law standard-withdrawal
coordination interface account-debit
coordination interface customer-withdrawal
Bindings of the coordination interfaces (formal
parameters) to specific classes of the
application
Object class account
Object class customer .
Binding may require adaptation
27
Services as coordination contracts
Coordination contract instantiation of a
coordination law
Contracts may have operations and attributes like
a normal class, but these are not public
Contract Partner binding (class-instance
relationship)
28
Semantic primitives for coordination
  • Using Coordination Contracts for Evolution

Customer
Account
For a normal customer
contract Traditional partners x Account y
Customer constraints ?owns(x,y)TRUE coordinatio
n tp when  y.callsx.withdrawal(z) with  x.Balan
ce() z do  x.withdrawal(z) end contract
29
Semantic primitives for configuration
Ad-hoc operations (performed on demand by
authorised users) in this case, subscription of
a VIP-package
coordination context AccountManagement (c
customer) component types Account,
Customer contract types Standard, VIP constants
maxCredit money10000 services subscribe VIP(a
account,limit money) pre exists
Standard(c,a) and limit lt maxCredit post
exists VIP(c,a) and VIP(c,a).credit limit
and not exists Standard(c,a) rules automa
ticVIP when exists VIP(c,a) and
avg.balance() lt 100 post exists Standard(c,a)
and not exists VIP(c,a)
Programmed operations (performed in reaction to
triggers) in this case, a VIP- Package is
automatically removed when the balance goes below
100.
30
A micro-architecture for coordination
  • None of the standards for component-based
    software development CORBA, JavaBeans, COM
    can support superposition as a first-class
    mechanism.
  • Because of this, we propose our solution as a
    micro-architecture that exploits polymorphism and
    subtyping, and is based on well known design
    patterns, such as the Chain of Responsibility,
    and the Proxy or Surrogate.

31
A coordination design pattern
32
A coordination design pattern
33
Account coordination
34
Operational view
  • Before the subject gives rights to the real
    object to execute the request, it intercepts the
    request and gives right to the contract to decide
    if the request is valid and perform other
    actions.
  • This allows us to impose other contractual
    obligations on the interaction between the caller
    and the callee.

35
Operational view
  • On the other hand, it allows the contract to
    perform other actions before or after the real
    object executes the request.
  • Only if the contract authorises can the connector
    ask the involved objects to execute and commit,
    or undo execution because of violation of
    post-conditions established by the contract.

36
CDE - Coordination Development Environment
  • A development and run-time environment for
    layered coordination systems
  • The coordination layer, defining the more
    volatile part of a system, is built over the
    component layer, the stable parts of the business

Software System
Context Setup
Contract Development
Deployment
Run-Time Configuration
Coordination Layer
Testing
Component Layer
Component Development
37
CDE Development Activities
  • Registration components are registered as
    candidates for coordination.
  • Edition Contract types are defined connecting
    registered components. Coordination rules are
    defined on those contracts.
  • Deployment the code necessary to implement the
    coordinated components and the contract semantics
    in the final system is produced according to the
    contract design pattern.

38
CDE Run time Activities
  • Animation facilities are provided allowing
    testing/prototyping of contract semantics
  • Registration contract types are registered in
    the system.
  • Configuration contracts are configured in the
    system (enabling/disabling rules, priorities,
    etc)
  • Evolution concrete contracts are created between
    specific system elements, regulating its
    behaviour.

39
CDE - User interaction
Run time
Development
Developer
Contract Type Registration Contract
Creation Run-time Configuration Definition
Regist Components Contract Type Creation /
Edition
CDE-Rt
System Assembler
Deployed System
Deploy System
Trigger Operation Observe Object
CDE
Testing
User Application Interface
Animation Interface
Tester
40
Architectures for Mobility
  • This architectural approach relies on the fact
    that
  • individual components can perform the
    computations that are required at the locations
    in which they are placed,
  • the coordination mechanisms put in place through
    connectors can be made effective across the
    "wires" that link components in the underlying
    communication network.
  • In the context of mobile systems

41
Architectures for Requirements
M/A/D, fD, G ? R
42
Programming interactions
  • Policy-drive, 2-tiered architectural
    reconfiguration

43
Learn more
  • about how these principles are being used in
    industry!
  • Visit www.atxsoftware.com

44
Learn more
  • download the CDE www.atxsoftware.com/CDE
  • Buy the book

45
Learn more
  • about
  • Buy the book

46
Software Specification and Design _at_ Leicester
Who we are Nasreddine Aoumeur Yifeng Chen
Mohammad El-Ramly José Luiz Fiadeiro Piotr
Kosiuczenko Zhiming Liu Stephan Reiff-Marganiec
Irek Ulidowski
47
www.cs.le.ac.uk/SoftSD
  • What we do
  • component-based and object-oriented methods
  • service-oriented system development
  • architectural aspects of system construction and
    evolution
  • generative and re-engineering techniques
  • verification, testing and analysis techniques
  • real-time, embedded, and reactive system
    specification and design
Write a Comment
User Comments (0)
About PowerShow.com