1 ivan lanese computer science department university of bologna italy from services to abs with...

1

Ivan LaneseComputer Science Department

University of BolognaItaly

From services to ABS

With input from Davide Sangiorgi, Fabrizio Montesi,

…

2

Roadmap

From services to ABS

Message indirection

Nesting and wrappers

Conclusions

3

Roadmap

From services to ABS

Message indirection

Nesting and wrappers

Conclusions

Our aim

Look for concepts and primitives for ABS inspired by our experience with services

Analyze which kinds of patterns they enable– In particular concerning evolvability/adaptation

Compare them with the object oriented approach of ABS

Integrate the two approaches

What are services?

A service is a piece of software providing functionalities– It has an identity– It has a well-defined interface– Functionalities (called operations) can be invoked by other

services– To compose complex services/workflows

Similar to objects (and components)– Operations correspond to methods– Instances of a service correspond to instances of a class

But– More suitable for heterogeneous systems (standards, …)– No inheritance, code reuse by composition

Our experience with services

Sensoria project on Software Engineering for Service-Oriented Overlay Computers– European FET GC 2 project (just finished)

Development of the language Jolie– Full-fledged language for programming service oriented

applications

– Based on the formal calculus SOCK

– Provides high-level primitives for communication and reconfiguration

– Supported by University of Bologna spin-off italianaSoftware

Why services for ABS?

Service orientation is an HATS requirement– MR 21 in Deliverable D5.1

– Virtual Office case study is service oriented

Services suitable for programming dynamically evolvable applications– High degree of dynamicity

– Support for dynamically change the behaviour

Many approaches to evolvability in the literature are based on services– Meteor-s, PAWS, …

Which evolvability?

Many different kinds of evolvability exist– Static/dynamic

– Related to different steps of the software development process

– … (cfr. Deliverable D3.1.a)

We are mainly interested in dynamic evolution– Evolution of behavior that occurs at runtime

– Both specification and enactment

Which are the right primitives and concepts for specifying and programming dynamic evolution?

What can we learn from services/components?

Services and dynamic evolution

Services for composing a service-oriented application may be found at runtime in the environment

A service-oriented application automatically evolves if new versions of its component services become available

Communication between services are mediated by ports– Connections can be changed dynamically

Other mechanisms allow to change the structure/behavior– Dynamic embedding, aggregation, redirection

From services to ABS

Different primitives/ideas can be imported in different ways

As extensions of ABS– Requires to update the syntax/semantics

– Real integration with ABS language

As patterns/best practices– Not always possible

– The programmer may go around them

As additional layers– Good for high-level approaches (cfr. JoRBA)

Roadmap

From services to ABS

Message indirection

Nesting and wrappers

Conclusions

Message indirection

In OO languages (and ABS) messages are sent directly to the recipient via method invocation

To change the communication patterns one needs to change the code of the objects– Source code is needed

We want to import the mechanism of input/output ports from services– Messages sent to ports, that forward them to the real recipients

Why message indirection?

By changing the content of a port, communication topology is updated– No need to change the code (difficult and error prone)

– Can be done without recompiling

Ports can be exploited for configuration/deployment– Port content read from configuration file

– Can be used for creating a specific product of a SPL

Ports simplify dynamic evolution– Port content can be changed at runtime

– Allows to connect/remove components

Logging via message indirection

Since all the communications

go through the port the logging

works correctly

O1Logger

Authentication (cfr. Virtual Office)

O1 O2

Authentication (cfr. Virtual Office)

O1 O2

Auth

Int

Learning from the examples

All the communications from/to one source can be redirected in a safe and unintrusive way

Two symmetric mechanisms: input and output ports Output ports allow to redirect all the outgoing messages Input ports allow to redirect all the incoming messages Allow different kinds of evolvability patterns

Message indirection: Evolvability patterns

Input/output logging Message format adaptation

– Changing protocol (cfr. Jacopo’s talk)

Interface adaptation– Changing/hiding functionalities

– Changing parameters

Buffering Multicast …

Message indirection in ABS

Deeply influences communication The programmer should always exploit it

– Otherwise direct communications can escape evolvability patterns

Good candidate for language extension Has to be integrated with method invocation

– Can be both synchronous and asynchronous

Output ports in ABS

Strongly related to method invocation Instead of x=o1.m(pars) one should write x=p1.m(pars)

p1 is an output port (indirect object reference)

One should declare to which method (and input port) the port is bound

When the output port is invoked, the invocation is forwarded to the target object/input port

Output ports may also specify the used protocol

Input ports in ABS

Strongly related to interfaces Extend interfaces with an additional forward layer For each method signature they should specify to which

real method (and object) the call is forwarded– May also specify the protocol

Managing input/output ports in ABS

Can be initialized during deployment (cfr. Jacopo’s talk) New ports have to be created when new objects are

created Need for primitives to update input/output ports for

reconfiguration Rebind: changes the binding of a port

Logging step by step

O1

Logging step by step

Adding logger

O1Logger

Logging step by step

Binding logger’s output port

O1Logger

Logging step by step

Rebinding O1 output port

O1Logger

Roadmap

From services to ABS

Message indirection

Nesting and wrappers

Conclusions

Nesting and wrappers

The port mechanism allows to change thebehavior of the system dynamically

The architecture evolves too Some objects depend on each other

– E.g., the logger depends on the logged system

Those dependencies are not visible With a hierarchic structure one can capture those

dependencies– Wrapping both the logger and the logged system as a unique

entity

Nesting and wrappers

Nesting allows more control on internal object Wrappers can filter communications Entities inside the same wrapper (location) share

resources– Location dependent behavior

Removing a wrapper (may) remove all the wrapped components at once

Wrappers allow code reuse at runtime

Hiding via wrapping

O1

wrapper

Ports not externalized by the wrapper are not visible from the outside

Two objects are aggregated into one

Aggregation via wrapping

O1

wrapper

O2

Replacing an application (cfr. Virtual Office)

Switch from Outlook to Thunderbird as mailing application

Using ports one can disconnect Outlook and connect Thunderbird

Outlook may exploit libraries/auxiliary applications– Will remain there

– May create troubles/inefficiencies

Solution: use wrapping to group Outlook and all its dependencies

I can insert Thunderbird (wrapped!) replacing the wrapper

Replacing an application (cfr. Virtual office)

Outlook

wrapper

Lib

Nesting: Evolvability patterns

Grouping– Identifying resource dependencies

– Allow location dependent behavior

Wrapping– Hiding/modifying functionalities

– Replacing a complex system as a single object

Nesting and wrappers in ABS

ABS has a two levels structure: objects and coboxes Coboxes are used only for concurrency

– Not suitable for wrapping/grouping

From a structural point of view ABS systems are flat Objects can communicate freely (using the suitable

synchronization form) No way to act on groups of objects at once

Nesting and wrappers in ABS

Objects are good candidates to implement the hierarchy Objects can already contain (references to) objects in

their fields Something more is necessary to allow real subobjects

– Control of communications

– Control of life cycle of subobjects

Exploiting the hierarchy

When the hierarchy is in place, primitives are needed to exploit it

Communication features– Specifying access to subobjects– Transparent vs obaque objects

Movement– Objects can be created inside the creator or at the same level

of the creator– Can objects move seamlessly?– Can objects be deleted and recreated?

Location dependence– Can objects discover objects in the same location?

Roadmap

From services to ABS

Message indirection

Nesting and wrappers

Conclusions

Summary

Services (and components) provide a good toolset of techiques for evolvability

Some of those techniques can be imported into ABS– Input/output ports, hierarchy

– What else?

Necessary to find a good integration with ABS main constructs– Objects, interfaces, synchronous/asynchronous method calls

High-level approaches

Those primitives can be exploited for programming adaptation/evolvability frameworks

Allow to specify evolution in a more user-friendly way We see as an example the JoRBA framework

JoRBA

A middleware for programming adaptable applications Applications provide an adaptation interface, i.e. a set of

activities that can be dynamically replaced Adaptation is performed by adaptation servers

managing sets of adaptation rules Each adaptation rule includes

– a description of the activities it can be applied to– some information for deciding whether adaptation is

possible/useful – the updated code for replacing the old one

At runtime, adaptation rules are applied to make the application evolve

To discuss

Which are the best suited constructs for adaptation? How can they be integrated with ABS? Can the same constructs be used for variability?

End of talk

Components

Components are pieces of software with a well-defined interface that can be composed into complex systems

Components may have subcomponents, giving rise to an inclusion hierarchy

Components can be created, destroyed and the connections between them can be updated

Destroying a component automatically destroies its subcomponents

Components and evolvability

Components evolve by changing the connections between them and by adding/removing/replacing subcomponents

Not necessary to know how complex a component is to remove it– A complex system can be wrapped into one component and

considered as a unit

Components may be communicated and received at runtime