16-01-2013, 16:11:01
(Dieser Beitrag wurde zuletzt bearbeitet: 19-01-2013, 22:02:55 von mziegler.)
Wireshark ist da auch nicht ganz das beste Werkzeug für diesen Zweck. (Ansonsten ein grossartiges Werkzeug für Netzwerkanalyse).
Einfacher geht das mit Fiddler2. Der übernimmt auch einfach die ssl-Entschlüsselung.
Die Kommunikation zwischen der Silverlight Applikation (ich nehme an, diese ist mit OOE gemeint) und der SHC erfolgt über http/ssl. Das Nachrichtenformat ist xml und gut verständlich, wenn auch teilweise etwas sehr kommunikativ.
Bei jedem Start der Anwendung findet folgendes statt (jeweils request und response):
1. Login request - response
2. Auslesen der Konfiguration request - response
3. Auslesen der aktuellen Zustände (sind nicht Bestandteil der Response auf 2)
4. Registrieren für Notifications bezüglich Zustandsänderungen
5. Regelmässiges pollen auf Notifications request - response
Daneben gibt es dann noch Nachrichten, um Zustände zu ändern oder die Konfiguration zu ändern.
Alles zu implementieren wird relativ umfangreich.
Ein paar kleinere Fallstricke gibt es noch, z.B. Erzeugung des Passwort Hashes über SHA256 und Base64 oder dass die Versionsnummer der Konfiguration entsprechend immer die aktuelle sein muss, aber an sich sind die Nachrichten relativ gut verständlich.
Ich würde grob schätzen, dass ich für die Analyse und Aufbau von Basisobjektmodell mit Unittests ca. 2 x 4 Stunden gebraucht habe.
Wenn ich von RWE ein positives Feedback bekommen habe, kann ich gerne mal den grundlegenden Aufbau detaillierter beschreiben.
Einfacher geht das mit Fiddler2. Der übernimmt auch einfach die ssl-Entschlüsselung.
Die Kommunikation zwischen der Silverlight Applikation (ich nehme an, diese ist mit OOE gemeint) und der SHC erfolgt über http/ssl. Das Nachrichtenformat ist xml und gut verständlich, wenn auch teilweise etwas sehr kommunikativ.
Bei jedem Start der Anwendung findet folgendes statt (jeweils request und response):
1. Login request - response
2. Auslesen der Konfiguration request - response
3. Auslesen der aktuellen Zustände (sind nicht Bestandteil der Response auf 2)
4. Registrieren für Notifications bezüglich Zustandsänderungen
5. Regelmässiges pollen auf Notifications request - response
Daneben gibt es dann noch Nachrichten, um Zustände zu ändern oder die Konfiguration zu ändern.
Alles zu implementieren wird relativ umfangreich.
Ein paar kleinere Fallstricke gibt es noch, z.B. Erzeugung des Passwort Hashes über SHA256 und Base64 oder dass die Versionsnummer der Konfiguration entsprechend immer die aktuelle sein muss, aber an sich sind die Nachrichten relativ gut verständlich.
Ich würde grob schätzen, dass ich für die Analyse und Aufbau von Basisobjektmodell mit Unittests ca. 2 x 4 Stunden gebraucht habe.
Wenn ich von RWE ein positives Feedback bekommen habe, kann ich gerne mal den grundlegenden Aufbau detaillierter beschreiben.