• [OK] destination name factory: naming schemas and patters/regex for Java [Birte]
  • einfache Bennennung der destinations wie z.B sensor_1, phenomenon_3 und statischem RegistrationDestination
  • zwei public Methoden: getDestinationName und getRegristrationDestinationName
  • als Parameter wird der ISpecificconnector übergeben und eine Abfrage der Instanz je nach Sensor, Phenomen oder CommunicationSimulation

• interaction between ICommonConnector and ISpecificConnectors with onMessage()- and insertMessage()- methods

• Code generieren lassen [Daniel]
  • Probleme:
    • die Dictionary Management Messages können nicht in dieser Form vorgenommen werden, da
      • (1) erstellen eines eigenen Messagetypen durch Implementieren von jms.Message viel zu aufwändig ist
      • (2) erben von irgendwelchen MantaMessages nicht möglich ist, da diese nur über eine Session als Factory erstellt werden können.
      • nicht möglich, da MapMessage nur primitive Datentypen erlaubt Lösung: Komplettes verpacken einer Hierarchie von DictManagementMessages ist nicht unbedingt notwendig, da die Dictionary Struktur sehr eng an Mantary geknüpft ist. Stattdessen direkte Verwendung der vorhandenen Klassen MantaMapMessage und MantaObjectMessage.

• data structures for dictionary: e.g. maps or DestinationMap? [Daniel]
  • [OK] Überlegung: die vielen verschiedenen get- und add- Methoden für Destinations werden jeweils mit default Werten an den mächtigsten Aufruf (d.h. mit MessageTyp und int-Array als Argumenten) weitergeleitet
  • [OK] neue Klassenstruktur: ich habe eine abstrakte Klasse AbstractDictionary implements IDictionary erstellt, von der alle Dictionaries erben. Vorteil: * die "convenience Methoden zum Aufruf der mächtigsten Methoden (siehe vorheriger Punkt) werden bereits dort für alle gleich behandelt. Auch die defaults sind stehen dort. Die Collection destinationsToListen, die alle zu abonnierenden Destinations enthält, ist auch mit getter und setter in AbstractDictionary, da ich vermute, diese Liste erfordert keine unterschiedliche Behandlung für die verschiedenen Dictionaries.

• public abstract void addDestination(String dest, SensorWorldMessage msg, int[] recipient);
• public abstract Collection getDestinations(SensorWorldMessage msg, int[] recipients);

• neu in der Klassenstruktur:
  • [OK] auch die common connectoren haben eine abstrakte Ebene bekommen, AbstractCommonConnector implements CommonConnector, MessageListener. Die Behandlung des zugehörigen IDictionary sollte komplett in dieser Ebene handlebar sein.
  • [OK] die getDestinations(), d.h. den Aufruf ohne Paramter, habe ich rausgenommen, da sie meiner Meinung nach ohne die Mapping-Informationen als Liste voller Destinations nicht anwendbar ist.
  • [OK] ICommonConnector und ISpecificConnector sind in package vcl.common gewechselt, in vcl.connectors sind somit nur noch die verschiedenen common connectoren vorhanden
  • [OK] löschen der fake-Klassen Sensor, SWMessage etc. im test-Package und ersetzen mit Simons Implementierungen
  • isDefaultMessage() und isDefaultRecipientsArray() in das abstrakte dictionary eingefügt, protected, kann man in den dictionaries zur sortierung verwenden
  • [OK] habe register() zum ICommonConnector hinzugefügt ... kein Problem, da das sowieso schon im common connector drin stand

• mapping und dictionaries
  • jedes Dictionary bekommt einen "all" - Eintrag, der bei jeder Rückgabe mitgegeben wird, zu debugging zwecken; Vorschlag: einen für jeden Typ, Benennung über dict name factory, getAnyDestionation() als abstrakte Methode im AbstractDictionary, Klasse AnyMessageLogger im Package test hinzugefügt, die lauscht auf alle any topics und loggt diese ... diese Klasse muss dann auch nur initialisiert werden.
  • commsim: ausgehend nur "sensor id >> destination"
  • phensim: erste Entscheidung: ist measuremement response, dann sensoren analog zu commsim; wenn nicht dann message type >> destination
  • sensor: sobald measurement request als typ, dann mapping von phen type >> destination, sobald eine id übergeben wird, dann abspeichern mit sensor zu sensor Destination
  • update (ganzes dict), add, delete destionation message ohne instanzüberprüfungen implementieren, nur eine message klasse
  • änderungen werden direkt propagiert, intelligentere lösungen (entweder nach zeit, oder bestimmter anzahl, oder oder) erst später
    • Aktualisierungsnachrichten werden über 1 Topic je Komponente (Sensoren, Phenomäne, Commsim) verteilt, diese sollten von der destination name factory geholt werden, aber innerhalb der common connectoren nicht gesondert behandelt werden, sondern einfach in die entsprechenden dictionaries hinzugefügt werden.
  • je nach Anzahl der Änderungen werden updatende oder überschreibende Nachrichten gesendet

• [OK] Registration Message und return message
• [OK] inititateMantaQueueConnection() Methode mit aufbau der factory, Connection,session,....im CommomConnector
• [OK] Message ID`s
• [OK] Phenomenon Messages
• [OK] im CommonConnector Map zur Verwaltung der benutzten Queue Objecte

offene Fragen / Vorschläge