Die Anwendungsarchitektur
Die Anwendung ist stark verteilt da sie bereits über eine On-premise-Java-Anwendung verfügt. Zusätzlich zu dieser On-premise-Java-Anwendung kommt eine Windows-Azure-Anwendung hinzu. Die Java-Anwendung verwendet Tomcat und Spring. Aufgrund der oben genannten Interop-Szenarien wird in unserem Fall die Möglichkeit gewählt, Daten über eine Queue auszutauschen. Sobald ein autorisierter Benutzer (Arzt, Angehöriger) die Patientenidentifikationsdaten anhand der Sozialversicherungsnummer eingibt, wird eine Message versendet. Die On-premise-Java-Anwendung der Krankenkassen untersucht die Einweisungsregister und Sozialdaten. Hierbei wird ein Datenservice der Versicherungen und ein Datenservice der einzelnen Krankenhäuser abgefragt. Letztere Datenservices stellen einen OData-Endpunkt zur Verfügung. Die On-premise-Java-Anwendung aggregiert die Daten und liefert eine Message an den Client zurück. Die Kommunikation basiert auf XML Schema, um einen korrekten Datenaustausch zu gewährleisten. Das komplette Szenario ist in Abbildung 3 dargestellt.
Die Anwendung ist, wie bereits mehrmals erwähnt, stark verteilt. Hierbei kommen .NET-Datenservices zum Einsatz, die in einem TableStorage liegen. Der Windows Azure TableStorage bietet einen OData-Endpunkt an, der von der Java-Anwendung konsumiert wird. Hierfür gibt es ein SDK. OData ist ein offener Standard für Daten. Die Java-Anwendung kommuniziert über den AppFabric Service Bus mit der Windows-Azure-Anwendung. Die Zusammenarbeit der einzelnen Dienste ist in Abbildung 4 nochmal genau dargestellt.
