Dieses Beispiel auf der nächsten Folie zeigt, wie sowas aussehen könnte.
Wir haben also in einem Legacy-System mehrere Funktionen und die eine Funktion soll ersetzt werden durch eine neue,
beziehungsweise die zweite Funktion soll außerhalb in einem Entervice Jamabians-basierten System zugänglich gemacht werden.
Kennzeichen für solche Systeme sind, dass wir einen Servicebroker haben.
Insofern können sie das durchaus auch in ein klassisches serviceorientierte Architektur sich ähnlicherweise vorstellen,
dass das AGB ist jetzt hier nur ein Beispiel für eine Technologie, die man da verwenden kann.
Das hängt ja sehr davon ab, was unsere Zielplattform ist. Also wir wollen diese Funktion von außen zugänglich machen und zum Beispiel als Service,
das heißt,
der Service-Proker muss den Zugriff darauf ermöglichen und der Service-Proker gibt dann das zum Beispiel als Bienen nach außen und die Bienen,
die dann woanders verfügbar ist als Komponente auf der neuen Plattform,
auf der Endepress Java-Winen-Plattform, arbeitet in Wirklichkeit so,
dass es hier ein Adapter gibt,
der auf diese Funktion zugreift das nützt und die Funktion 1,
die wir nicht brauchen,
die wird halt neu geschrieben und sodass wir dann als in diesem service-orientierten System die Funktion 2 im Original und die Funktion 1 als neu zur Verfügung gestellt bekommen.
Und hier ist ein Adapter dazwischen. Das ist natürlich umso einfacher,
je weniger Änderungen wir haben, wenn sich das entspricht,
also sowohl von den Datenformaten als auch von Zustandsraum,
vom Protokoll her, ist das dann entsprechend einfacher.
Andererseits muss man sich natürlich daran orientieren,
was hier gebraucht wird, je größer die Unterschiede sind,
desto eher lohnt es sich,
nicht so ein Adapter oder ein Rapper
zu verwenden,
sondern etwas tatsächlich neu zu implementieren