Aufgabensteller:Prof. Bernd Brügge Ph.D. Prof. Gudrun Klinker Ph.D. Supervisor:Dipl.-Inf. Christian Sandor, Dipl.-Inf. Asa MacWilliams Presenter:Markus Michael Geipel April 2004 SEP Run-time Development and Configuration of Dynamic Service Networks
April /20 Overview Motivation DIVE Problem Statement CAR Requirements Solutions Results Future Work
April /20 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
April /20 DIVE DWARF Interactive Visualisation Environment Implemented by Daniel Pustka (SEP) Service Descriptions Service Manager Query Service Descriptions
April /20 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. Problem Statement
April /20 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.
April /20 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.
April /20 More GUI, more Views New Icons New Color Scheme New List View
April /20 More GUI, more Views Grouping und Filtering
April /20 Extensions Changing Predicates, changing Attributes
April /20 Extensions Connecting Services
April /20 Extensions Making Changes Persistent
April /20 Configurators Configuration Graphical User Interface Information
April /20 Configurators
April /20 Update Speed –How fast can DIVE’s internal representation of the DWARF service network be synchronized with the information residing in each individual ServiceManager 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 ServiceManager runs on a different host and is thus independent. –Thus every ServiceManager can easily be queried in parallel Reduce the subjective Update Speed –As soon as new information is available, show it.
April /20 Results: Update Speed A: 2 Hosts, 13 active inactive sercvices B: 3 Hosts, 24 active inactive sercvices C: 4 Hosts, 35 active inactive sercvices
April /20 Results: Survey Utility
April /20 Future Work: Near Future Refactoring DwarfSystemModel (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
April /20 Future Work: Far Future DIVE in 3D or even in AR? –Mockup by Michael Riedl
April /20 Thank you very much for paying attention Questions?
April /20 Results: Update Speed Situation C
April /20 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)