Serviceorientierte Programmierung für Ansätze bei der Web-Services-Architektur

Ein Service ist ein Kernstück einer Business-Logic, welches protokoll- und ortsunabhängig ist und keinen User-Zustand beinhaltet. Services enthalten keine Präsentationslogik und keine Logik zur Integration mit Daten-Eben-Ressourcen wie beispielsweise Datenbanken. Services beschäftigen sich ausschließlich mit der Lösung von Business-Domain-Problemen.

Services sind sehr lose an andere Komponenten einer Anwendung gekoppelt. Sie sind protokollunabhängig, weshalb auf sie auf verschiedenen Wegen zugegriffen werden kann, und grobkörnig. Dadurch kann der Service in einem einzigen Aufruf seine Business-Logic ausführen und das Ergebnis ausgeben. Ein gutes Beispiel dafür ist ein Service mit dem Namen getAccounts, der die Informationen aller angegebenen Bankkonten eines beliebigen Anwenders ausgibt.

Services arbeiten üblicherweise mit Konfigurationsdaten, um über bestimmte Dinge wie beispielsweise über den Aufruf eines bestimmten Daten-Integrationsmodul zu entscheiden. Allerdings werden die Konfigurationsdaten für individuelle Anwender normalerweise nicht abgespeichert. Services sollten Userdaten zum Beispiel nicht über eine einzelne Anfrage hinaus speichern. Dadurch sind Services Multiuser-fähig (das heißt: ein einzelner Service kann von vielen Anwendern gleichzeitig aufgerufen werden).

Anwendungen werden normalerweise durch das beschrieben, was sie tun, und nicht unbedingt dadurch, was sie sind oder was sie beinhalten. Daher ist es sehr viel einfacher, eine Anwendung mit Hilfe von Verben und nicht über Nomen zu beschreiben. Im Gegensatz dazu arbeitet OOP auf der Grundlage der Beschreibung von Objekten und des in ihnen enthaltenen Zustands und Verhaltens.

In den meisten Distributed-Component-Frameworks (wie zum Beispiel Enterprise Java Beans (EJBs) von J2EE) basieren die wichtigsten für Business-Logic vorgesehenen Einheiten auf einer OOP-Komponente. Da Objekte eine Sache und keine Aktion definieren, kann es beim Versuch der Einkapselung dessen, was eine Komponente tut (und eben nicht ist), zur Sprachdiskrepanz (Impedance Mismatch) kommen.

Im SOP wird eine Anwendung auf sehr viel natürlichere Weise beschrieben. Jede Funktion der Anwendung, die sich verbalisieren lässt, wird wahrscheinlich auch ein Kandidat für einen Service sein.