Einführung in die Service-Entwicklung 

Ein Service bietet eine Lösung für vorgegebene Aufgaben an und ist in einem System implementiert. Entsprechend bezeichnet man denjenigen, der den Service anbietet als Provider und das System, in dem der Service implementiert ist, als Provider-System. Umgekehrt gibt es immer einen Aufrufer oder Consumer des Service und entsprechend ein Consumer-System. Abgesehen von der technischen Implementierung ranken sich viele Fragen und Anforderungen um die Service-Entwicklung. Hier einige Beispiele, die dies verdeutlichen:

●      Wo wird der Service angeboten und wo wird der Service benötigt?

●      Existiert der Service bereits oder muss er noch entwickelt werden?

●      Was ist der Charakter des Service? Ist er eher unternehmensintern (A2A) oder unternehmensübergreifend (B2B)? Wird der Service essentiell für die Ausführung eines Gesamtprozesses benötigt oder kann man ihn eher isoliert betrachten? Ist er eher feingranular oder aus anderen Services zusammengesetzt?

●      Wie viele Consumer sollen auf den Service zugreifen? Ist die Ausführungszeit kritisch in dem Szenario?

●      Sollen Daten des Service auf der Benutzungsoberfläche angezeigt werden?

Die Antworten auf solche Fragen bestimmen, mit welchen Methoden man einen Service implementiert und für Consumer zugänglich macht.

Im folgenden werden einige Methoden und Technologien vorgestellt, um die Service-Entwicklung im Enterprise Services Repository von anderen Szenarien abzugrenzen.

Outside-In versus Inside-Out

Es ist möglich, Services unabhängig von der verwendeten Interface-Technologie aufzurufen. Dazu braucht der Consumer nur eine Service-Beschreibung, über die er den Service aufrufen kann. Es gibt nun zwei Ansätze, wo diese Beschreibung herkommen soll:

·        Existiert der Service bereits im System, kann man die im System vorhandene Service-Signatur dazu verwenden, um eine Service-Beschreibung zu generieren. Der Service kann dann nach außen publiziert werden, beispielsweise auf einem zentralen Server. Entsprechend spricht man bei diesem Entwicklungsansatz vom Inside-Out-Ansatz.

·        Existiert noch kein Service im System, kann man ihn zunächst außerhalb des Systems beschreiben. Das hat den Vorteil, dass man die Beschreibung bereits während des Entwicklungsprozesses und unabhängig von der Implementation für die Entwicklung anderer, eng mit dem Service verzahnter Objekte einsetzen kann. Für die Implementierung und den Aufruf kann man Entwicklungsobjekte in das jeweilige Entwicklungssystem generieren (für den Consumer und den Provider). Entsprechend spricht man bei diesem Entwicklungsansatz vom Outside-In-Ansatz.

SAP NetWeaver verwendet XML-Technologie für die Service-Beschreibungen. Da man beim Outside-In-Ansatz zunächst keine klassischen Entwicklungsobjekte, sondern sprachenunabhängige Service-Beschreibungen anlegt, wird diese Phase mit Design-Phase bezeichnet.

Die Wahl des Entwicklungsansatzes hängt eng mit der Frage zusammen, ob der Service bereits existiert oder nicht. Der nächste Abschnitt geht genauer auf eine weitere Dimension der Service-Entwicklung ein, bei der es um die technische Umsetzung des Aufrufs geht.

Web Services versus erweiterte Szenarien (Integration Server)

Für das Szenario, dass Services systemübergreifend aufgerufen werden sollen, bietet SAP NetWeaver zwei Szenariovarianten an:

·        Den direkten Aufruf des Service mit Hilfe der Web-Service-Technologie (Point-to-Point), siehe auch: Service-basierte Integration (Point-to-Point).

·        Den Aufruf des Service mit Hilfe des Integration Servers, den den Aufruf weiterleitet, siehe auch: Erweiterte Service-basierte Integration.

In beiden Varianten gibt es wiederum die Möglichkeit, Services nach dem Outside-In- oder Inside-Out-Ansatz zu entwickeln:

Szenariovarianten und Entwicklungsansätze

Variante	Ansatz	Grundsätzliche Vorgehensweise
Point-to-Point	Inside-Out	Für eine vorhandene Funktion im Anwendungssystem erzeugen Sie ein WSDL-Dokument (das sie beispielsweise auf einem UDDI-Server publizieren können). Aus dem WSDL-Dokument kann sich der Aufrufer ein Consumer-Proxy generieren, mit dem die Anwendung auf Consumer-Seite den Service beim Provider aufrufen kann.
	Outside-In	Die Entwicklung beginnt im Enterprise Services Repository mit dem Design von Service-Interfaces, die direkt als WSDL-Dokument abrufbar ist. Ausgehend von den Service-Interfaces generieren Entwickler sowohl Proxies für den Provider als auch für den Consumer. Im WSDL-Dokument fehlen allerdings noch Informationen darüber, wie der Provider des Service adressiert werden kann. Die Methode, wie diese Informationen ergänzt werden, hängt von der Szenariovariante ab (Point-to-Point oder über Integration Server).
Über Integration Server
	Inside-Out	Sie importieren eine XML-Beschreibung für eine vorhandene Funktion in das Enterprise Services Repository. Die XML-Beschreibung lässt sich für eine Kommunikation über den Integration Server durch beliebige Aufrufer verwenden.

Die Dokumentation zum Enterprise Services Repository konzentiert sich auf Details zu den jeweiligen Objekteditoren im Enterprise Services Builder. Besonderheiten zur jeweiligen Entwicklungsvariante werden nur am Rande erwähnt. Um einen Einstieg aus Sicht der jeweiligen Entwicklungsvariante zu bekommen, hilft das passende IT-Szenario. Die folgende Tabelle führt die hier relevanten IT-Szenarien auf und welche Themen dort primär behandelt werden:

IT-Szenarien als Anwendungsfall der Service-Entwicklung

IT-Szenario	Abschnitt im SAP NetWeaver Developer’s Guide	Schwerpunkte
Enabling Enterprise Services	Point-to-Point-Services Outside-In entwickeln	Modellierung des übergeordneten Geschäftsprozesses, Entwicklung von Services für Point-to-Point-Variante, Entwicklung von Services für die Benutzungsoberfläche
Enabling A2A-Processes	Services für erweiterte A2A-Prozesse entwickeln	Entwicklung von Services für Integration-Server-Kommunikation (unternehmensintern)