1 ivan lanese computer science department university of bologna italy from services to abs with...
Post on 20-Dec-2015
215 views
TRANSCRIPT
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