1 Ivan Lanese Computer Science Department University of Bologna Italy From services to ABS With input from Davide Sangiorgi, Fabrizio Montesi, …

2 Roadmap l From services to ABS l Message indirection l Nesting and wrappers l Conclusions

3 Roadmap l From services to ABS l Message indirection l Nesting and wrappers l Conclusions

Our aim l Look for concepts and primitives for ABS inspired by our experience with services l Analyze which kinds of patterns they enable –In particular concerning evolvability/adaptation l Compare them with the object oriented approach of ABS l Integrate the two approaches

What are services? l 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 l Similar to objects (and components) –Operations correspond to methods –Instances of a service correspond to instances of a class l But –More suitable for heterogeneous systems (standards, …) –No inheritance, code reuse by composition

Our experience with services l Sensoria project on Software Engineering for Service- Oriented Overlay Computers –European FET GC 2 project (just finished) l 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? l Service orientation is an HATS requirement –MR 21 in Deliverable D5.1 –Virtual Office case study is service oriented l Services suitable for programming dynamically evolvable applications –High degree of dynamicity –Support for dynamically change the behaviour l Many approaches to evolvability in the literature are based on services –Meteor-s, PAWS, …

Which evolvability? l Many different kinds of evolvability exist –Static/dynamic –Related to different steps of the software development process –… (cfr. Deliverable D3.1.a) l We are mainly interested in dynamic evolution –Evolution of behavior that occurs at runtime –Both specification and enactment l Which are the right primitives and concepts for specifying and programming dynamic evolution? l What can we learn from services/components?

Services and dynamic evolution l Services for composing a service-oriented application may be found at runtime in the environment l A service-oriented application automatically evolves if new versions of its component services become available l Communication between services are mediated by ports –Connections can be changed dynamically l Other mechanisms allow to change the structure/behavior –Dynamic embedding, aggregation, redirection

From services to ABS l Different primitives/ideas can be imported in different ways l As extensions of ABS –Requires to update the syntax/semantics –Real integration with ABS language l As patterns/best practices –Not always possible –The programmer may go around them l As additional layers –Good for high-level approaches (cfr. JoRBA)

Roadmap l From services to ABS l Message indirection l Nesting and wrappers l Conclusions

Message indirection l In OO languages (and ABS) messages are sent directly to the recipient via method invocation l To change the communication patterns one needs to change the code of the objects –Source code is needed l 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? l 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 l Ports can be exploited for configuration/deployment –Port content read from configuration file –Can be used for creating a specific product of a SPL l 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 O1O1 Logger

Authentication (cfr. Virtual Office) O1O1 O2O2

O1O1 O2O2 Auth Int

Learning from the examples l All the communications from/to one source can be redirected in a safe and unintrusive way l Two symmetric mechanisms: input and output ports l Output ports allow to redirect all the outgoing messages l Input ports allow to redirect all the incoming messages l Allow different kinds of evolvability patterns

Message indirection: Evolvability patterns l Input/output logging l Message format adaptation –Changing protocol (cfr. Jacopo’s talk) l Interface adaptation –Changing/hiding functionalities –Changing parameters l Buffering l Multicast l…l…

Message indirection in ABS l Deeply influences communication l The programmer should always exploit it –Otherwise direct communications can escape evolvability patterns l Good candidate for language extension l Has to be integrated with method invocation –Can be both synchronous and asynchronous

Output ports in ABS l Strongly related to method invocation l Instead of x=o 1.m(pars) one should write x=p 1.m(pars) l p 1 is an output port (indirect object reference) l One should declare to which method (and input port) the port is bound l When the output port is invoked, the invocation is forwarded to the target object/input port l Output ports may also specify the used protocol

Input ports in ABS l Strongly related to interfaces l Extend interfaces with an additional forward layer l 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 l Can be initialized during deployment (cfr. Jacopo’s talk) l New ports have to be created when new objects are created l Need for primitives to update input/output ports for reconfiguration l Rebind: changes the binding of a port

Logging step by step O1O1

Adding logger O1O1 Logger

Logging step by step Binding logger’s output port O1O1 Logger

Logging step by step Rebinding O 1 output port O1O1 Logger

Roadmap l From services to ABS l Message indirection l Nesting and wrappers l Conclusions

Nesting and wrappers l The port mechanism allows to change the behavior of the system dynamically l The architecture evolves too l Some objects depend on each other –E.g., the logger depends on the logged system l Those dependencies are not visible l With a hierarchic structure one can capture those dependencies –Wrapping both the logger and the logged system as a unique entity

Nesting and wrappers l Nesting allows more control on internal object l Wrappers can filter communications l Entities inside the same wrapper (location) share resources –Location dependent behavior l Removing a wrapper (may) remove all the wrapped components at once l Wrappers allow code reuse at runtime

Hiding via wrapping O1O1 wrapper l Ports not externalized by the wrapper are not visible from the outside

l Two objects are aggregated into one Aggregation via wrapping O1O1 wrapper O2O2

Replacing an application (cfr. Virtual Office) l Switch from Outlook to Thunderbird as mailing application l Using ports one can disconnect Outlook and connect Thunderbird l Outlook may exploit libraries/auxiliary applications –Will remain there –May create troubles/inefficiencies l Solution: use wrapping to group Outlook and all its dependencies

l I can insert Thunderbird (wrapped!) replacing the wrapper Replacing an application (cfr. Virtual office) Outlook wrapper Lib

Nesting: Evolvability patterns l Grouping –Identifying resource dependencies –Allow location dependent behavior l Wrapping –Hiding/modifying functionalities –Replacing a complex system as a single object

Nesting and wrappers in ABS l ABS has a two levels structure: objects and coboxes l Coboxes are used only for concurrency –Not suitable for wrapping/grouping l From a structural point of view ABS systems are flat l Objects can communicate freely (using the suitable synchronization form) l No way to act on groups of objects at once

Nesting and wrappers in ABS l Objects are good candidates to implement the hierarchy l Objects can already contain (references to) objects in their fields l Something more is necessary to allow real subobjects –Control of communications –Control of life cycle of subobjects

Exploiting the hierarchy l When the hierarchy is in place, primitives are needed to exploit it l Communication features –Specifying access to subobjects –Transparent vs obaque objects l 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? l Location dependence –Can objects discover objects in the same location?

Roadmap l From services to ABS l Message indirection l Nesting and wrappers l Conclusions

Summary l Services (and components) provide a good toolset of techiques for evolvability l Some of those techniques can be imported into ABS –Input/output ports, hierarchy –What else? l Necessary to find a good integration with ABS main constructs –Objects, interfaces, synchronous/asynchronous method calls

High-level approaches l Those primitives can be exploited for programming adaptation/evolvability frameworks l Allow to specify evolution in a more user-friendly way l We see as an example the JoRBA framework

JoRBA l A middleware for programming adaptable applications l Applications provide an adaptation interface, i.e. a set of activities that can be dynamically replaced l Adaptation is performed by adaptation servers managing sets of adaptation rules l 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 l At runtime, adaptation rules are applied to make the application evolve

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

End of talk

Components l Components are pieces of software with a well-defined interface that can be composed into complex systems l Components may have subcomponents, giving rise to an inclusion hierarchy l Components can be created, destroyed and the connections between them can be updated l Destroying a component automatically destroies its subcomponents

Components and evolvability l Components evolve by changing the connections between them and by adding/removing/replacing subcomponents l 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 l Components may be communicated and received at runtime