evolvability_adaptation

1、Ivan LaneseComputer Science DepartmentUniversity of BolognaItalyFrom services to ABSWith input from Davide Sangiorgi, Fabrizio Montesi, RoadmapFrom services to ABSMessage indirectionNesting and wrappersConclusionsRoadmapFrom services to ABSMessage indirectionNesting and wrappersConclusionsOur aimLoo

2、k for concepts and primitives for ABS inspired by our experience with servicesAnalyze which kinds of patterns they enableIn particular concerning evolvability/adaptationCompare them with the object oriented approach of ABSIntegrate the two approachesWhat are services?A service is a piece of software

3、 providing functionalitiesIt has an identityIt has a well-defined interfaceFunctionalities (called operations) can be invoked by other servicesTo compose complex services/workflowsSimilar to objects (and components)Operations correspond to methodsInstances of a service correspond to instances of a c

4、lassButMore suitable for heterogeneous systems (standards, )No inheritance, code reuse by compositionOur experience with servicesSensoria project on Software Engineering for Service-Oriented Overlay ComputersEuropean FET GC 2 project (just finished)Development of the language JolieFull-fledged langu

5、age for programming service oriented applicationsBased on the formal calculus SOCKProvides high-level primitives for communication and reconfigurationSupported by University of Bologna spin-off italianaSoftwareWhy services for ABS?Service orientation is an HATS requirementMR 21 in Deliverable D5.1Vi

6、rtual Office case study is service oriented Services suitable for programming dynamically evolvable applicationsHigh degree of dynamicitySupport for dynamically change the behaviourMany approaches to evolvability in the literature are based on servicesMeteor-s, PAWS, Which evolvability?Many differen

7、t kinds of evolvability existStatic/dynamicRelated to different steps of the software development process (cfr. Deliverable D3.1.a)We are mainly interested in dynamic evolutionEvolution of behavior that occurs at runtimeBoth specification and enactmentWhich are the right primitives and concepts for

8、specifying and programming dynamic evolution?What can we learn from services/components?Services and dynamic evolutionServices for composing a service-oriented application may be found at runtime in the environmentA service-oriented application automatically evolves if new versions of its component

9、services become availableCommunication between services are mediated by portsConnections can be changed dynamicallyOther mechanisms allow to change the structure/behaviorDynamic embedding, aggregation, redirectionFrom services to ABSDifferent primitives/ideas can be imported in different waysAs exte

10、nsions of ABSRequires to update the syntax/semanticsReal integration with ABS languageAs patterns/best practicesNot always possibleThe programmer may go around themAs additional layersGood for high-level approaches (cfr. JoRBA)RoadmapFrom services to ABSMessage indirectionNesting and wrappersConclus

11、ionsMessage indirectionIn OO languages (and ABS) messages are sent directly to the recipient via method invocationTo change the communication patterns one needs to change the code of the objectsSource code is neededWe want to import the mechanism of input/output ports from servicesMessages sent to p

12、orts, that forward them to the real recipientsWhy message indirection?By changing the content of a port, communication topology is updatedNo need to change the code (difficult and error prone)Can be done without recompilingPorts can be exploited for configuration/deploymentPort content read from con

13、figuration fileCan be used for creating a specific product of a SPLPorts simplify dynamic evolutionPort content can be changed at runtimeAllows to connect/remove componentsLogging via message indirectionSince all the communicationsgo through the port the loggingworks correctlyO1LoggerAuthentication

14、(cfr. Virtual Office)O1O2Authentication (cfr. Virtual Office)O1O2AuthIntLearning from the examplesAll the communications from/to one source can be redirected in a safe and unintrusive wayTwo symmetric mechanisms: input and output portsOutput ports allow to redirect all the outgoing messagesInput por

15、ts allow to redirect all the incoming messagesAllow different kinds of evolvability patternsMessage indirection: Evolvability patternsInput/output loggingMessage format adaptationChanging protocol (cfr. Jacopos talk)Interface adaptationChanging/hiding functionalitiesChanging parametersBufferingMulti

16、castMessage indirection in ABSDeeply influences communicationThe programmer should always exploit itOtherwise direct communications can escape evolvability patternsGood candidate for language extensionHas to be integrated with method invocationCan be both synchronous and asynchronousOutput ports in

17、ABSStrongly related to method invocationInstead 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 boundWhen the output port is invoked, the invocation is forwarded to the target object/input p

18、ortOutput ports may also specify the used protocolInput ports in ABSStrongly related to interfacesExtend interfaces with an additional forward layer For each method signature they should specify to which real method (and object) the call is forwardedMay also specify the protocolManaging input/output

19、 ports in ABSCan be initialized during deployment (cfr. Jacopos talk)New ports have to be created when new objects are createdNeed for primitives to update input/output ports for reconfigurationRebind: changes the binding of a portLogging step by stepO1Logging step by stepAdding loggerO1LoggerLoggin

20、g step by stepBinding loggers output portO1LoggerLogging step by stepRebinding O1 output portO1LoggerRoadmapFrom services to ABSMessage indirectionNesting and wrappersConclusionsNesting and wrappersThe port mechanism allows to change thebehavior of the system dynamicallyThe architecture evolves tooS

21、ome objects depend on each otherE.g., the logger depends on the logged systemThose dependencies are not visibleWith a hierarchic structure one can capture those dependenciesWrapping both the logger and the logged system as a unique entityNesting and wrappersNesting allows more control on internal ob

22、jectWrappers can filter communicationsEntities inside the same wrapper (location) share resourcesLocation dependent behaviorRemoving a wrapper (may) remove all the wrapped components at onceWrappers allow code reuse at runtimeHiding via wrappingO1wrapperPorts not externalized by the wrapper are not

23、visible from the outsideTwo objects are aggregated into oneAggregation via wrappingO1wrapperO2Replacing an application (cfr. Virtual Office)Switch from Outlook to Thunderbird as mailing applicationUsing ports one can disconnect Outlook and connect ThunderbirdOutlook may exploit libraries/auxiliary a

24、pplicationsWill remain thereMay create troubles/inefficienciesSolution: use wrapping to group Outlook and all its dependenciesI can insert Thunderbird (wrapped!) replacing the wrapperReplacing an application (cfr. Virtual office)OutlookwrapperLibNesting: Evolvability patternsGroupingIdentifying reso

25、urce dependenciesAllow location dependent behaviorWrappingHiding/modifying functionalitiesReplacing a complex system as a single objectNesting and wrappers in ABSABS has a two levels structure: objects and coboxesCoboxes are used only for concurrencyNot suitable for wrapping/groupingFrom a structura

26、l point of view ABS systems are flatObjects can communicate freely (using the suitable synchronization form)No way to act on groups of objects at onceNesting and wrappers in ABSObjects are good candidates to implement the hierarchyObjects can already contain (references to) objects in their fieldsSo

27、mething more is necessary to allow real subobjectsControl of communicationsControl of life cycle of subobjectsExploiting the hierarchyWhen the hierarchy is in place, primitives are needed to exploit itCommunication featuresSpecifying access to subobjectsTransparent vs obaque objectsMovementObjects c

28、an be created inside the creator or at the same level of the creatorCan objects move seamlessly?Can objects be deleted and recreated?Location dependenceCan objects discover objects in the same location? RoadmapFrom services to ABSMessage indirectionNesting and wrappersConclusionsSummaryServices (and

29、 components) provide a good toolset of techiques for evolvabilitySome of those techniques can be imported into ABSInput/output ports, hierarchyWhat else?Necessary to find a good integration with ABS main constructsObjects, interfaces, synchronous/asynchronous method callsHigh-level approachesThose p

30、rimitives can be exploited for programming adaptation/evolvability frameworksAllow to specify evolution in a more user-friendly wayWe see as an example the JoRBA frameworkJoRBAA middleware for programming adaptable applicationsApplications provide an adaptation interface, i.e. a set of activities that can be dynamically replacedAdaptation is performed by adaptation servers managing sets of adaptation rulesEach adaptation rule includes a description of the activities it can be applied toso