SEP Runtime Development and Configuration of Dynamic Service

  • Slides: 22
Download presentation
SEP Run-time Development and Configuration of Dynamic Service Networks Aufgabensteller: Prof. Bernd Brügge Ph.

SEP Run-time Development and Configuration of Dynamic Service Networks Aufgabensteller: Prof. Bernd Brügge Ph. D. Prof. Gudrun Klinker Ph. D. Supervisor: Dipl. -Inf. Christian Sandor, Dipl. -Inf. Asa Mac. Williams Presenter: Markus Michael Geipel April 2004

Overview • • Motivation DIVE Problem Statement CAR Requirements Solutions Results Future Work 2

Overview • • Motivation DIVE Problem Statement CAR Requirements Solutions Results Future Work 2 <Markus Michael Geipel> April 2004

Motivation • Data flows are the heart of an AR-System • DWARF is thus

Motivation • Data flows are the heart of an AR-System • DWARF is thus a cooperating service network • Via DIVE this network can be visualized • But: It can not be configured or developed 3 <Markus Michael Geipel> April 2004

DIVE • DWARF Interactive Visualisation Environment • Implemented by Daniel Pustka (SEP) Query Service

DIVE • DWARF Interactive Visualisation Environment • Implemented by Daniel Pustka (SEP) Query Service Descriptions Service Manager Service Descriptions 4 <Markus Michael Geipel> April 2004

Problem Statement • DIVE should not only be a monitoring tool, but a tool

Problem Statement • DIVE should not only be a monitoring tool, but a tool to actively support the development of dynamic service networks. • Further more DIVE has to be convenient to use in means of stability, speed and GUI. 5 <Markus Michael Geipel> April 2004

CAR • CAR acts as a source of new requirements and ideas that originate

CAR • CAR acts as a source of new requirements and ideas that originate from the everyday practice with DWARF. • Further more CAR explores authoring techniques in AR. Thus CAR’s field of application intersects with DIVE’s field of application. 6 <Markus Michael Geipel> April 2004

Requirements Analysis: The Requirements • Functional – Changing the network structure • Changing Attributes

Requirements Analysis: The Requirements • Functional – Changing the network structure • Changing Attributes and Predicates • Connecting Services • Starting Services – Making Changes Persistent – Configuring Services – Looking at the network structure • List View of the Services • Grouped View of the Services • Non Functional (excerpt) – Performance: Suitable for CAR, Update in average within 5 seconds. – Reliability: Running several hours in productive work. 7 <Markus Michael Geipel> April 2004

More GUI, more Views • New Icons • New Color Scheme • New List

More GUI, more Views • New Icons • New Color Scheme • New List View 8 <Markus Michael Geipel> April 2004

More GUI, more Views • Grouping und Filtering 9 <Markus Michael Geipel> April 2004

More GUI, more Views • Grouping und Filtering 9 <Markus Michael Geipel> April 2004

Extensions • Changing Predicates, changing Attributes 10 <Markus Michael Geipel> April 2004

Extensions • Changing Predicates, changing Attributes 10 <Markus Michael Geipel> April 2004

Extensions • Connecting Services 11 <Markus Michael Geipel> April 2004

Extensions • Connecting Services 11 <Markus Michael Geipel> April 2004

Extensions • Making Changes Persistent 12 <Markus Michael Geipel> April 2004

Extensions • Making Changes Persistent 12 <Markus Michael Geipel> April 2004

Configurators Information Graphical User Interface Configuration Information 13 <Markus Michael Geipel> April 2004

Configurators Information Graphical User Interface Configuration Information 13 <Markus Michael Geipel> April 2004

Configurators 14 <Markus Michael Geipel> April 2004

Configurators 14 <Markus Michael Geipel> April 2004

Update Speed • Update Speed – How fast can DIVE’s internal representation of the

Update Speed • Update Speed – How fast can DIVE’s internal representation of the DWARF service network be synchronized with the information residing in each individual Service. Manager • Reorganization of the Update Routine – Don’t throw away the system model – Set the stage for further improvement • Version Counting – Only services that actually changed need to be updated • Multithreaded Update – The main part of the update time is network roundtrip delay – Every Service. Manager runs on a different host and is thus independent. – Thus every Service. Manager can easily be queried in parallel • Reduce the subjective Update Speed – As soon as new information is available, show it. 15 <Markus Michael Geipel> April 2004

Results: Update Speed A: 2 Hosts, 13 active + 128 inactive sercvices B: 3

Results: Update Speed A: 2 Hosts, 13 active + 128 inactive sercvices B: 3 Hosts, 24 active + 192 inactive sercvices C: 4 Hosts, 35 active + 256 inactive sercvices 16 <Markus Michael Geipel> April 2004

Utility Results: Survey 17 <Markus Michael Geipel> April 2004

Utility Results: Survey 17 <Markus Michael Geipel> April 2004

Future Work: Near Future • Refactoring Dwarf. System. Model (Design Patterns) • Refactoring the

Future Work: Near Future • Refactoring Dwarf. System. Model (Design Patterns) • Refactoring the Model Views (complete MVC) • Polishing up the UI – Ergonomic design (like Eclipse or Visual Studio) – Other graphical notations (e. g. UML like) – Minimap and zoom 18 <Markus Michael Geipel> April 2004

Future Work: Far Future • DIVE in 3 D or even in AR? –

Future Work: Far Future • DIVE in 3 D or even in AR? – Mockup by Michael Riedl 19 <Markus Michael Geipel> April 2004

Thank you very much for paying attention • Questions? 20 <Markus Michael Geipel> April

Thank you very much for paying attention • Questions? 20 <Markus Michael Geipel> April 2004

Results: Update Speed Situation C 21 <Markus Michael Geipel> April 2004

Results: Update Speed Situation C 21 <Markus Michael Geipel> April 2004

Services in DWARF • Services have Needs and Abilities, which have types • •

Services in DWARF • Services have Needs and Abilities, which have types • • Abilities have Attributes, Needs have Predicates. These can be set at runtime. One service’s Needs depend on other services’ Abilities. Distributed CORBA-based Middleware establishes connections for communication between services (management, lookup, connection) 22 <Markus Michael Geipel> April 2004