SelfCon Foil no 1 Self configurating systems - a starter Rolv Bræk, Item.

Slides:



Advertisements
Similar presentations
What is RMI? Remote Method Invocation –A true distributed computing application interface for Java, written to provide easy access to objects existing.
Advertisements

SelfCon Foil no 1 Dynamic component systems 1. SelfCon Foil no 2 Pre-structured systems vs. dynamic component systems Pre-structured – emphasis on content.
Web Services Nasrullah. Motivation about web service There are number of programms over the internet that need to communicate with other programms over.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 12 Slide 1 Distributed Systems Design 2.
SelfCon Foil no 1 Dynamic component systems 2. SelfCon Foil no 2 Fire and burglar alarms Climate control: heating and cooling Power control: minimize.
Software Engineering 2003 Jyrki Nummenmaa 1 OBJECT ARCHITECTURE DESIGN These slides continue with our example application, based on the simplified.
Computer Monitoring System for EE Faculty By Yaroslav Ross And Denis Zakrevsky Supervisor: Viktor Kulikov.
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects.
Distributed Service Architectures Yitao Duan 03/19/2002.
PROGRESS project: Internet-enabled monitoring and control of embedded systems (EES.5413)  Introduction Networked devices make their capabilities known.
II. Middleware for Distributed Systems
Practical Issues of RPCCS-4513, D-Term Remote Procedure Call Practical Issues CS-4513 Distributed Computing Systems (Slides include materials from.
Communication in Distributed Systems –Part 2
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Quality Attributes & Tactics (4) Modifiability.
© DSRG 2001www.cs.agh.edu.pl Cross Grid Workshop - Kraków Krzysztof Zieliński, Sławomir Zieliński University of Mining and Metallurgy {kz,
[ §4 : 1 ] 4. Requirements Processes II Overview 4.1Fundamentals 4.2Elicitation 4.3Specification 4.4Verification 4.5Validation Software Requirements Specification.
Client/Server Software Architectures Yonglei Tao.
Additional SugarCRM details for complete, functional, and portable deployment.
THE NEXT STEP IN WEB SERVICES By Francisco Curbera,… Memtimin MAHMUT 2012.
A. Mednonogov / Helsinki University of Technology / Conformance Testing of CORBA Services Using TTCN / / Page 1 Conformance Testing of CORBA Services.
B.Ramamurthy9/19/20151 Operating Systems u Bina Ramamurthy CS421.
An Introduction to Software Architecture
Robot Autonomous Perception Model For Internet-Based Intelligent Robotic System By Sriram Sunnam.
1 Vrijendra Gokhale, Bernard Menezes K. R. School of Information Technology IIT Bombay User Interfaces for Jini Services The Jini Pattern Language Workshop.
Architecting Web Services Unit – II – PART - III.
SelfCon Foil no 1 Self configuring systems - introduction II.
Comparison of Web Services, RMI, CORBA, DCOM Usha, Lecturer MCA Department of Computer Science and Engineering.
SelfCon Foil no 1 Design of Self-Adaptive Systems Course introduction 2013 Rolv Bræk, ITEM.
PERVASIVE COMPUTING MIDDLEWARE BY SCHIELE, HANDTE, AND BECKER A Presentation by Nancy Shah.
Component frameworks Roy Kensmil. Historical trens in software development. ABSTRACT INTERACTIONS COMPONENT BUS COMPONENT GLUE THIRD-PARTY BINDING.
Spring/2002 Distributed Software Engineering C:\unocourses\4350\slides\DefiningThreads 1 RMI.
SE-02 COMPONENTS – WHY? Object-oriented source-level re-use of code requires same source code language. Object-oriented source-level re-use may require.
Sunday, October 15, 2000 JINI Pattern Language Workshop ACM OOPSLA 2000 Minneapolis, MN, USA Fault Tolerant CORBA Extensions for JINI Pattern Language.
INTERNET AND ADHOC SERVICE DISCOVERY BY: NEHA CHAUDHARY.
Client Call Back Client Call Back is useful for multiple clients to keep up to date about changes on the server Example: One auction server and several.
Distributed Objects and Middleware. Sockets and Ports Source: G. Coulouris et al., Distributed Systems: Concepts and Design.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking.
Copyright © 2013 Curt Hill SOAP Protocol for exchanging data and Enabling Web Services.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Jini Architecture Alessandro Brawerman. Contents Jini definition Advantages Architecture How it works Websites to check.
CS 501: Software Engineering Fall 1999 Lecture 12 System Architecture III Distributed Objects.
Dynamic and Selective Combination of Extension in Component-based Applications Eddy Truyen, Bart Vanhaute, Wouter Joosen, Pierre Verbaeten, Bo N. Jørgensen.
SelfCon Foil no 1 Self configuring systems - introduction I.
Service Discovery Protocols Mobile Computing - CNT Dr. Sumi Helal Professor Computer & Information Science & Engineering Department University.
Jini Architecture Introduction System Overview An Example.
An Introduction to Web Services Web Services using Java / Session 1 / 2 of 21 Objectives Discuss distributed computing Explain web services and their.
SelfCon Foil no 1 Variability in Self-Adaptive Systems.
Seminar on Service Oriented Architecture Distributed Systems Architectural Models From Coulouris, 5 th Ed. SOA Seminar Coulouris 5Ed.1.
Science and Technology Norwegian University of NTNU Rolv Bræk, January Introduction to Systems Engineering by Rolv Bræk NTNU.
Slide 1 Service-centric Software Engineering. Slide 2 Objectives To explain the notion of a reusable service, based on web service standards, that provides.
1 Getting Service Engineering Right Next Generation Service Engineering Making the most of service models Rolv Bræk, Norwegian University of Science and.
Secure middleware patterns E.B.Fernandez. Middleware security Architectures have been studied and several patterns exist Security aspects have not been.
What’s Ahead for Embedded Software? (Wed) Gilsoo Kim
Lecture 21: Component-Based Software Engineering
RobustBPEL2: Transparent Autonomization in Business Processes through Dynamic Proxies Onyeka Ezenwoye S. Masoud Sadjadi Autonomic Computing Research Lab.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 15 System Architecture III.
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Context-Aware Middleware for Resource Management in the Wireless Internet US Lab 신현정.
SelfCon Foil no 1 Pre-structured Systems. SelfCon Foil no 2 Pre-structured systems (e.g. SDL systems) Stable (cannot be added or changed dynamically)
Design Patterns-1 7 Hours.
OO Methodology OO Architecture.
Inventory of Distributed Computing Concepts and Web services
Operating Systems Bina Ramamurthy CSE421 11/27/2018 B.Ramamurthy.
Patterns.
Component--based development
An Introduction to Software Architecture
COMPONENTS – WHY? Object-oriented source-level re-use of code requires same source code language. Object-oriented source-level re-use may require understanding.
Design Yaodong Bi.
Presentation transcript:

SelfCon Foil no 1 Self configurating systems - a starter Rolv Bræk, Item

SelfCon Foil no 2 Self configuration By self configuration we mean dynamic configuration with minimal human participation. Self configuration means dynamic adaptation to changing environments. Applied in plug-and-play, ad-hoc systems/networks, autonomic computing,... By self configuration we mean dynamic configuration with minimal human participation. Self configuration means dynamic adaptation to changing environments. Applied in plug-and-play, ad-hoc systems/networks, autonomic computing,...

SelfCon Foil no 3 What can I do here? ???

SelfCon Foil no 4 Self configuration Basis 1.Communication infrastructure 2.Registry functionality: to register objects, types, services/roles to find objects, types, services/roles to manage dynamic associations 1.Communication infrastructure 2.Registry functionality: to register objects, types, services/roles to find objects, types, services/roles to manage dynamic associations Registry object-a:Type-1object-x:Type-z Type-1Type-n role c

SelfCon Foil no 5 Object plug-in 1.plug-in 2.Find Registry (Discovery) 3.Register with Registry 4.Explore the Registry 5.Request actors of services/roles 6.Establish dynamic association (lease) May be mutually performed 1.plug-in 2.Find Registry (Discovery) 3.Register with Registry 4.Explore the Registry 5.Request actors of services/roles 6.Establish dynamic association (lease) May be mutually performed Registry object-a:Type-1object-x:Type-n Type-1Type-n object-b:Type , 4, 5 6

SelfCon Foil no 6 Object plug-out 1.Release dynamic associations 2.De-register with Registry 3.Plug-out 1.Release dynamic associations 2.De-register with Registry 3.Plug-out Registry object-a:Type-1object-x:Type-n Type-1Type-n object-b:Type

SelfCon Foil no 7 Rebind on error 1.Detect error on dynamic associations 2.Request another actor for the role 3.Establish new dynamic association Fault tolerance is a kind of self configuration, but not the same as rebind on error 1.Detect error on dynamic associations 2.Request another actor for the role 3.Establish new dynamic association Fault tolerance is a kind of self configuration, but not the same as rebind on error Registry object-a:Type-1object-x:Type-n Type-1Type-n object-b:Type

SelfCon Foil no 8 Using stubs/proxies 1.Hiding the protocols actually used 2.Making remote interfaces local May be only one-way interfaces in some cases 1.Hiding the protocols actually used 2.Making remote interfaces local May be only one-way interfaces in some cases Registry object-a:Type-1object-x:Type-n Type-1Type-n x-proxy:a-proxy: x-stub: a-stub: x- skeleton: a- skeleton: Synchronoues method calls:

SelfCon Foil no 9 Composite plug-in, plug-out Registry object-a:Type-1object-x:Type-z Type- 1 Type- n role c Registry object-a:Type-1object-x:Type-z Type- 1 Type- n role c Eg: –Bluetooth networks –Sub-systems –Network nodes –Computers –… Possibly a Manager for each composite Manager

SelfCon Foil no 10 A few points Each object will discover/find its actual context Objects bind dynamically to each other in application dependent ways Objects supervise each other, detect errors and may rebind Objects may receive configuration information from each other and adapt to each other Objects may be composite (subsystems) Objects may represent or be associated with external devices Discovery may be mutual Each object will discover/find its actual context Objects bind dynamically to each other in application dependent ways Objects supervise each other, detect errors and may rebind Objects may receive configuration information from each other and adapt to each other Objects may be composite (subsystems) Objects may represent or be associated with external devices Discovery may be mutual

SelfCon Foil no 11 Self configuration viewpoints HW OS Middleware i/o application Services/roles Type-1 Type-2 modeling implementation –plug-in –plug-out –move –change type –load type

SelfCon Foil no 12 Object environments: roles In self configurating systems the object structure is not fixed, even the types may change. All objects assume an environment with roles that are bound statically or dynamically to actual objects (actors) When active; objects will seek to find and bind to the actors they need. For this they need some basic facilities for discovery and lookup that we assume is handled by a registry interfaces may be fixed or adaptable In self configurating systems the object structure is not fixed, even the types may change. All objects assume an environment with roles that are bound statically or dynamically to actual objects (actors) When active; objects will seek to find and bind to the actors they need. For this they need some basic facilities for discovery and lookup that we assume is handled by a registry interfaces may be fixed or adaptable Type-1 Registry type-x 1 registry role role-a 0..1 type-y role-b 0..* type-z role-c 1..4

SelfCon Foil no 13 Common use of roles Roles in organizations: role in a play role in a project role in a service or function Roles in organizations: role in a play role in a project role in a service or function Roles in associations: family business session Are played by: actors persons objects AaseSolveigPeer mother lover son HepburnEastwoodRoberts

SelfCon Foil no 14 A service role is: Conference Call … Enquiry Call ab c com Basic Call ab call(a,b) callind(a) MSC Basic Call Busy answer(b) calling(b) end banswer(b) end a:subcomsysb:sub com call(a,b) callind(a) MSC Basic Call Succesful answer(b) calling(b) end banswer(b) end a com b S-role behaviour ServicesService roles the part some object plays in a service used to model services separately the part some object plays in a service used to model services separately

SelfCon Foil no 15 An association role is: abcom Service roles the part of a behaviour (e.g. service role) visible at an association end or interface it defines a dynamic interface behaviour used to align interfaces, to check consistency and synthesize designs the part of a behaviour (e.g. service role) visible at an association end or interface it defines a dynamic interface behaviour used to align interfaces, to check consistency and synthesize designs association roles call(a,b) callind(a) answer(b) calling(b) A-role behaviour abcom

SelfCon Foil no 16 Role relationships service–role association role interface–role 1..*

SelfCon Foil no 17 Services and actors Typical services involve more than one service role Actors may play more than one service roles Different actors may play the same service role Service roles may interact and contend for actors Typical services involve more than one service role Actors may play more than one service roles Different actors may play the same service role Service roles may interact and contend for actors A service change typically has impact on several types service Actor service role 1..* plays 1..*

SelfCon Foil no 18 Roles are like projections And useful for: Architecture definitions: roles help to define interfaces precisely Reuse: roles are reusable in many types Design synthesis: roles serve as specifications Design verification: inverse of design - checking that the provided roles “contain” the specified roles Validation of associations and links: roles can be used like “plugs” and “sockets” - provided roles must “contain” required roles And useful for: Architecture definitions: roles help to define interfaces precisely Reuse: roles are reusable in many types Design synthesis: roles serve as specifications Design verification: inverse of design - checking that the provided roles “contain” the specified roles Validation of associations and links: roles can be used like “plugs” and “sockets” - provided roles must “contain” required roles

SelfCon Foil no 19 An actor has provided and required roles

SelfCon Foil no 20 Aligning provided and required roles Provided role behaviours shall “contain” the required role behaviours

SelfCon Foil no 21 How to achieve well-formed systems? Content rules: govern the internal composition of (instances of) a type. A (context-free) grammar, for instance, is entirely made up of content rules. Too restrictive for open systems. Context rules: govern the external use of (instances of) a type. Gate constraints in SDL and interface definitions CORBA style, can be seen as context rules. Well defined association roles provide context rules. Content rules: govern the internal composition of (instances of) a type. A (context-free) grammar, for instance, is entirely made up of content rules. Too restrictive for open systems. Context rules: govern the external use of (instances of) a type. Gate constraints in SDL and interface definitions CORBA style, can be seen as context rules. Well defined association roles provide context rules. self configuration is based on context rules

SelfCon Foil no 22 Context rules only Context rules only: Generally: Any object structure is well-formed as long as all context rules are satisfied. Lego: the “rules of the bricks” Here: required roles to be contained by provided roles. Context rules only: Generally: Any object structure is well-formed as long as all context rules are satisfied. Lego: the “rules of the bricks” Here: required roles to be contained by provided roles. O1 O2O3O4

SelfCon Foil no 23 Levels of role alignment  Validation. Checking that the required roles are contained in the provided roles, and raising exceptions if not.  Adaptation. Negotiating and adapting the roles (within predefined bounds).  Learning. Learning to play new roles by receiving role definitions (e.g. using Java class loading)  Validation. Checking that the required roles are contained in the provided roles, and raising exceptions if not.  Adaptation. Negotiating and adapting the roles (within predefined bounds).  Learning. Learning to play new roles by receiving role definitions (e.g. using Java class loading)

SelfCon Foil no 24 Role composition Defining roles as design units that can be composed and managed by actors Challenge 1: modular design units Challenge 2: composition rules Defining roles as design units that can be composed and managed by actors Challenge 1: modular design units Challenge 2: composition rules Actor Design units Roles Actor Composition

SelfCon Foil no 25 Role learning Provider roles are those that provide the service Client roles are those that use the service Client roles are propagated on demand Provider roles are those that provide the service Client roles are those that use the service Client roles are propagated on demand Roles Design units Actor CPC learn C C CPC compose

SelfCon Foil no 26 An actor design is required that: simplifies adding or changing provider service roles; can hold descriptions, or references to descriptions, of required client roles in a form that enable client objects to fetch role implementations as part of role alignment; can itself learn client roles required from other objects as part of role alignment. simplifies adding or changing provider service roles; can hold descriptions, or references to descriptions, of required client roles in a form that enable client objects to fetch role implementations as part of role alignment; can itself learn client roles required from other objects as part of role alignment.

SelfCon Foil no 27 Vision: plug-and-play for services Define the service in terms of service roles Design the provider roles and client roles (as manus or design pattern) Install the roles in provider agents Dynamic role learning by client agents when linked to providers Challenges: role design role composition dynamic role learning (not the same as Jini Proxies!!) Define the service in terms of service roles Design the provider roles and client roles (as manus or design pattern) Install the roles in provider agents Dynamic role learning by client agents when linked to providers Challenges: role design role composition dynamic role learning (not the same as Jini Proxies!!)

SelfCon Foil no 28 Note Few (no) languages support self configuration, support outside the languages is required Inherent part of many architectures: CORBA, DCOM, RMI OSA/PARLAY JINI Service Discovery Protocols in general ­HAVi ­SLP (Service Location Protocol) ­Salutation, NINJA MAC-OS Windows Ad-hoc networking Bluetooth Semantic web Few (no) languages support self configuration, support outside the languages is required Inherent part of many architectures: CORBA, DCOM, RMI OSA/PARLAY JINI Service Discovery Protocols in general ­HAVi ­SLP (Service Location Protocol) ­Salutation, NINJA MAC-OS Windows Ad-hoc networking Bluetooth Semantic web

SelfCon Foil no 29 To discuss About object and type description/search criteria and substitution criteria About dependence on physical location and devices And about individual objects vs groups vs any instance of a type Use telecom examples About a typical PC configuration About the need for composites and composite managers About object and type description/search criteria and substitution criteria About dependence on physical location and devices And about individual objects vs groups vs any instance of a type Use telecom examples About a typical PC configuration About the need for composites and composite managers