Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dynamic Synthesis of Mediators to Support Interoperability in Autonomic Systems


Published on

  • Be the first to comment

  • Be the first to like this

Dynamic Synthesis of Mediators to Support Interoperability in Autonomic Systems

  1. 1. Dynamic Synthesis of Mediators to Support Interoperability in Autonomic Systems Amel Bennaceur and Valérie Issarny ARLES project-team Inria Paris-RocquencourtNII-Shonan Workshop: Engineering Autonomic Systems (EASy)
  2. 2. Interoperability in Autonomic Systems Systems are becoming increasingly connected • Future Internet, Cyber-Physical System, Internet of Things • Integration becoming more difficult Interactions among components cannot be planned beforehand • Increasingly dynamic • Unanticipated components System and its components figure out how to interact at runtime • Automatically ensuring interoperation at runtime
  3. 3. Our Research on Interoperability Sustaining composition in highly heterogeneous and dynamic environments • Multi-* networking environments with heterogeneity at all layers (application, middleware) • Semantics of networked systems needed to reason about and achieve on-the-fly interoperability • Ontology for the description of functional semantics • LTSs for the description of behavioural semantics 3
  4. 4. Illustrating the Interoperability Challenges GMES: Global Monitoring for Environment & Security Discovery, Interaction , Data , Application, NFP heterogeneity What kindcandata available services inuse? peers? Am I What kindcan I exchange othervicinity? What are Ithetoof application to other peers? How of communicate with with other allowed forward data can I peers? Highly-dynamic and complex environments 4
  5. 5. Existing Approaches to Interoperability× Change the system × A chosen shared × Use a common abstraction or attach an adaptor language Legacy systems No one-size-fits-all Need to be aware about all the No runtime support standard possible configurations beforhand Can we  an intermediary system: Transform on the fly using observe, synthesize and deploy mediators dynamically? the mediator 5
  6. 6. Dynamic Mediation to Support InteroperabilitySystems with compatible functionalities should be able to interact despite heterogeneities in their data and behavioral models. Mediators that seamlessly overcome these heterogeneities should be dynamicallysynthesized and deployed in their environment. 6
  7. 7. Dynamic Mediation to Support Interoperability Discovery → Learning → Synthesis → Concretization → Monitoring Ontolog y DownloadPhoto = getPhoto Photo = PhotoMetadata + PhotoFile PhotoMetadata = PhotoID + Location + CameraID + details … Synthesis Mediator Model write PhotoMetadata DownloadPhoto read PhotoMetadataModel write PhotoFile downloadPhoto read PhotoFilelevel Model Model Extraction Deployment Extraction System (NS1) System (NS2)System write PhotoMetadata level DownloadPhoto Emergent Middleware write PhotoFile Monitor
  8. 8. Ontology-based Networked System Model Ontology-based Functional Semantics 1 Networked • Affordance System • The high-level functionality of a system <SendSOAPRequest, 0..n • e.g., <Req, PhotoSharing, Preferences, Photo> DownloadPhoto,{CameraID}, > • Interface Interface Affordance 1 <ReceiveSOAPResponse, Behaviour • A set of observable actions DownloadPhoto,  {Photo}> , • e.g., <SendSOAPRequest, DownloadPhoto, {CameraID}, > LTS-based Behavioural semantics • The way the observable actions are coordinated Ontologies • At both application and middleware layers • Application → Business logic • Middleware → Communication & coordination protocol 8
  9. 9. Emergent Middleware Synthesis Informed by Ontologies NS1 Model Ontologies NS2 Model ThingAffordance a d Affordance B ir A <Prov, B, IB,OB> <Req, A, IA,OA> iaInterface Nothing Interface δ1 = <SOAPCall, d, id, od>α1 = <rd, a, ia, oa> λ1 = <SOAPCall, l, il, ol>β1 = <out, b, ib, ob> ρ1 = <SOAPCall, r, ir, or> Functional BehaviourBehaviour Matching t3 t2 !δ 1 ?β 1 ?ρ 1 !α 1 !δ 1 ?δ 2 !ρ 2 ?α 2 !β 2 ?λ 1 t4 t1 Does it make sense for NS1 and NS2 to interact?
  10. 10. Emergent Middleware Synthesis Informed by Ontologies Ontologies NS1 Model Thing NS2 Model a dAffordance B ir A Affordance ia <Req, A, IA,OA> <Prov, B, IB,OB> NothingInterface Interface δ1 = <SOAPCall, d, id, od>α1 = <rd, a, ia, oa> λ1 = <SOAPCall, l, il, ol> Middlewareβ1 = <out, b, ib, ob> Abstraction ρ1 = <SOAPCall, r, ir, or> BehaviourBehaviour t3 t2 !δ 1 ?β 1 ?ρ 1 !α 1 !δ 1 ?δ 2 !ρ 2 ?α 2 !β 2 ?λ 1 t4 t1 Abstract from the communication protocol details and concentrate on application semantics
  11. 11. Emergent Middleware Synthesis Informed by Ontologies Ontologies NS1 Model Thing NS2 Model a d Affordance B ir A Affordance ia <Req, A, IA,OA> <Prov, B, IB,OB> Nothing Interface Interfaceα = <a, ia, oa> δ = <d, id, od> λ = <l, il, ol>β = <b, ib, ob> Ontology-based Action Mapping ρ = <r, ir, or> Behaviour Behaviour α = < α , <δ, λ> > δ α β β = < β , <ρ> > ρ λ …. ρ δ α What are the translations that need to be performed?
  12. 12. Emergent Middleware Synthesis Informed by Ontologies NS1 Model α = < α , <δ, λ> > NS2 Model β = < β , <ρ> > Affordance …. Affordance <Req, A, IA,OA> <Prov, B, IB,OB> Interface Interfaceα = <a, ia, oa> Behavioral δ = <d, id, od> Matching & Synthesis λ = <l, il, ol>β = <b, ib, ob> ρ = <r, ir, or> Behaviour Behaviour Success δ α β ρ Abstract CONNECTor Model λ ρ δ α δ ρ λ α β Select the appropriate mapping processes and compose them such that both systems reach their final states
  13. 13. Emergent Middleware Synthesis Informed by Ontologies Ontologies Thing NS1 Model a d NS2 Model B ir A Affordance ia Affordance Nothing <Req, A, IA,OA> <Prov, B, IB,OB> Abstract CONNECTor Model Interface Interface ρ δ δ = <d, id, od>α = <a, ia, oa> λ λ = <l, il, ol>β = <b, ib, ob> α β ρ = <r, ir, or> Behaviour Behaviour δ α β Concretization ρ λ ρ δ α Concrete CONNECTor Model t2 t3 !δ 1 !ρ 1 ?β 1 ?α 1 ?δ 2 ?ρ 2 !β 2 !α 2 ?λ 1 t1 t4 Refines the mediator model into a concrete software artifact: an emergent middleware
  14. 14. Approach In Action: Domain-specific Ontology PhotoSharing PhotoSharingProducer PhotoSharingProducer PhotoSharingServer PhotoSharingServer PhotoSharingConsumer PhotoSharingConsumer Photo Subsumption (is-a) PhotoMetadata PhotoFile PhotoID: string CameraID: string Longitude: double Latitude: double Resolution: integer Information:string SearchPhoto DownloadPhoto UploadPhoto14
  15. 15. Approach In Action: Functional Matching System1 System 2AffC2 = <Req, PhotoSharing, AffDrone = <Prov, PhotoSharing, {CameraID}, {PhotoFile}>  {Photo}> , CameraID subsumes  (co-variant) Photo subsumes a PhotoFile (contra-variant) There is a functional matching between AffC2 and AffDrone 15
  16. 16. Approach In Action: Middleware Ontology RemoteProcedureCallAPI RemoteProcedureCallAPI SendSOAPRqt ReceiveSOAPResp ReceiveSOAPRqt SendSOAPResp 0..1 + 0..1 + follows {some} 0..1 + follows {some} 0..1 + follows {some} Call ReceiveReply ReceveReply ReceiveCall Reply +hasOutput {some} +hasInput {some} +hasInput {some} +hasOutput {some} MethodName MethodName Arguments Arguments ReturnValue ReturnValue +hasInput {some} +hasOutput {some} SOAPRequest SOAPResponse16
  17. 17. Approach In Action: Middleware Abstraction C2 Middleware-agnostic C2 Behavior Behavior <SendSOAPRequest, DownloadPhoto,{CameraID}, > <DownloadPhoto,{CameraID}, {Photo}> <ReceiveSOAPResponse, DownloadPhoto,{Photo} >17
  18. 18. Approach In Action: Middleware Abstraction DroneMiddleware-agnostic Drone Behavior Behavior <write, PhotoMetaData, , {photometadata}> <PhotoMetaData, , {photometadata}> <write, PhotoFile, , {photofile}> <PhotoFile, , {photofile}>18
  19. 19. Approach In Action: Generating Mapping Processes C2 Interface Drone Interface<DownloadPhoto,{CameraID}, {Photo}> <PhotoMetaData, , {photometadata}> <PhotoFile, , {photofile}> 1 - Define the constraints that need to hold between compatible actions e.g., photo sumsumed by photometadata union photofile 2- Use constraint programming to find possible mapping between interfaces <DownloadPhoto,{CameraID}, {Photo}>⟼ <<PhotoMetaData, , {photometadata}>, <PhotoFile, , {photofile}>> 3- Generate the corresponding mapping process PhotoMetaData PhotoFile DownloadPhoto 19
  20. 20. Approach In Action: Behavioral Matching C2 Behavior Mediator Behavior Drone Behavior PhotoMetaData PhotoMetaData DownloadPhoto PhotoFile PhotoFile DownloadPhoto20
  21. 21. Approach In Action: Deployment <receiveCall, DownloadPhoto, {cameraID},  >  Refine the mappingPhotoMetaData processes using <read, PhotoMetadata, middleware semantics {cameraID}, {photometadata}>PhotoFile Get photoID from photoMetadata <read, PhotoFile, {photoID}, {photoFile}>DownloadPhoto Middleware <reply, DownloadPhoto,  {photoFile}> , & Domain-specific Ontologies 21
  22. 22. Approach In Action: DeploymentSystem1 Emergent Middleware System 2 Parser 1 Mediator Composer 2 Composer 1 Parser 2
  23. 23. Open Issues Learning is (almost) always partial Evolution and incremental synthesis Discovery New NSs Learning Evolution of the NS Model Monitoring (re)Synthesis Synthesis23
  24. 24. Open Issues In CONNECT Enforcing the goal instead of achieving it Ontologies • Processing overhead, fuzziness, learning, heterogeneity in ontologies, alignment
  25. 25. Summary Interoperability remains a fundamental problem in today’s complex systems Dynamic synthesis of mediators promises to address interoperability in a future-proof mannerStill.. Need to make complete the NS model and re(synthesize) mediators incrementally25
  26. 26. Thank you
  27. 27. Further Information Home page: ARLES: CONNECT: The Role of Ontologies in Emergent Middleware: Supporting Interoperability in Complex Distributed Systems, In Proc. Middleware 2011 Middleware-layer Connector Synthesis: Beyond State of the Art in Middleware Interoperability, In SFM 2011 Towards an architecture for runtime interoperability, In Proc. ISoLA 201027