Konzept: Serviceportfolio
Dieses Konzept beschreibt die Vorteile von Services, wenn es darum geht, Organisationen in die Lage zu versetzen, Wiederverwendung durch die Komposition von Anwendungen aus einem Serviceportfolio zu fördern. Die Kategorisierung von Services für effektives Speichern, Ermitteln und Abrufen von Services aus Repositorys wird ebenfalls erläutert.
Beziehungen
Hauptbeschreibung

Einführung

Einer der erklärten Vorteile der serviceorientierten Architektur ist ihre Fähigkeit, von der isolierten Denkweise im IT-Bereich, d. h. der Entwicklung von Anwendungen als Träger von Funktionalität, wegzukommen. Heutzutage werden Anwendungen oft als vertikale Integration einer Komponentengruppe verstanden, die für einen bestimmten Zweck entwickelt wurde. Es kommt häufig vor, dass Entwicklungsprojekte um die Entwicklung bzw. Wartung einer Anwendung herum aufgebaut werden. In Extremfällen kommt es vor, dass Entwicklungsteams nur für eine einzige Anwendung zuständig sind. Die folgende Abbildung stellt eine allgemeine Geschäftsanwendungsstruktur dar, die zeigt, dass die einzige Wiederverwendung zwischen Anwendungen oft nur in der gemeinsamen Nutzung einer Datenbank besteht.

Im Kontext beschriebene Abbildung

Der serviceorientierte Ansatz führt hingegen zu einer eher horizontalen Sicht von Anwendungen als Integration von Services. Tatsächlich sind alle Services Peers in einem Portfolio von Funktionen, aus dem Anwendungen, die jetzt als Bestandteile der mit den Benutzern interagierenden IT-Lösungen betrachtet werden können, entwickelt werden können. Im Folgenden wird veranschaulicht, wie die Bestellungsanwendung als Gruppe von Portlets für die Integration in einen Portalserver entwickelt werden kann. Außerdem wird gezeigt, dass die Geschäftslogik von einer Servicegruppe, die ihrerseits eine Gruppe von Infrastrukturservices verwendet, bereitgestellt wird.

Im Kontext beschriebene Abbildung

Services bieten unabhängig implementierte Komponenten, die mit einer Unterteilung bereitgestellt werden, die sie vollkommen unabhängig macht. Das führt dazu, dass Services ihre eigenen Datenspeicher verwalten und speichern und keinen Datenbankspeicher gemeinsam nutzen. Dies scheint im Widerspruch zu einigen Unternehmen zu stehen, die über die Jahre versucht haben, allgemeine Datenspeicher oder zumindest allgemeine Datenmodelle einzuführen, die von allen Anwendungen gemeinsam genutzt werden. Eine serviceorientierte Architektur bringt Designer oft dazu, nicht allgemeine Datenspeichermodelle, sondern allgemeine Nachrichtenmodelle zu entwickeln, die die Integration von Services über Middleware-Technologien vereinfachen.

Unternehmenssicht 

Wie schon erwähnt, haben sowohl Projekte als auch Entwicklungsteams einen begrenzten Umfang und auch eine begrenzte Einsicht breiter angelegten Funktionen, Anforderungen und Ziele der IT-Services und, was noch wichtiger ist, in das von den Services unterstützte Geschäft. Für die Hinwendung zu serviceorientierten Lösungen und horizontalen Sichten integrierter Lösungen ist es von entscheidender Bedeutung, dass die Architekten auf der IT-Seite in der Lage sind, das Portfolio der Services, das die für den Geschäftsbetrieb selbst erforderlichen Geschäftslösungen unterstützt, zu visualisieren. Ein Vorteil bei der Servicemodellierung besteht darin, dass ein abstraktes Modell in der Lage ist, bestimmte Details auszulassen und daher die breit angelegte Sicht des Serviceportfolios in einer skalierbaren Form darzustellen. Mit anderen Worten, das Modell ist bei vielen vorhandenen Services in der Lage, Sichten des Portfolios, das die Entscheidungsfindung für den Softwarearchitekten und den Designer unterstützt, darzustellen.

Wenn Organisationen zur serviceorientierten Architektur übergehen, nimmt die Zahl der Services zu. Das Portfolio beginnt also nicht als großes Modell, es ist allerdings möglich, den Status des Übergangs hinsichtlich verfügbarer und geplanter Services zu erfassen. Servicepartitionierung ist ebenfalls von entscheidender Bedeutung bei der Organisation des Modells und der Kategorisierung von Services während der Entwicklung des Portfolios.

Kategorisierung von Services 

In den frühen Stadien der Serviceidentifikation (siehe Aktivität Analyse vorhandener Assets) werden geeignete Services in der Regel nur als eine Auflistung von Namen erfasst, die ggf. hierarchisch gegliedert oder in tabellarischer Form gespeichert ist. Eine solche Liste ist hilfreich, wenn Sie in einer Workshop-Umgebung arbeiten und das Quellenmaterial sichten, um geeignete Services auszuwählen. Wenn die geeigneten Services rasch an Zahl zunehmen, kann eine unstrukturierte Liste schnell unübersichtlich werden. Deshalb sollte umgehend ein Kategorisierungsschema für Services gefunden werden, um geeignete Services in Gruppen der Kategorienhierarchie organisieren zu können.

Eine einfache Liste mit Servicenamen kann ein guter Ausgangspunkt für den Schnelleinstieg sein. Sie sollten jedoch zusätzliche Informationen zu den einzelnen Services erfassen, da diese später von Bedeutung sein könnten. Dabei geht es einerseits um Informationen, die die Serviceidentifikation unterstützen, und anderseits um Informationen, die die Servicespezifikation unterstützen. Den Schwerpunkt der Serviceidentifikation bildet die Erstellung eines Portfolios mit Services, die Geschäftsfunktionen, Geschäftszielen und Assets (z. B. vorhandenen Systemen) zugeordnet werden können. Darüber hinaus geht es bei der Serviceidentifikation vorrangig um die Festlegung, ob ein Service als geeignet oder als mit Risiken behaftet anzusehen ist. Mit Hilfe der Serviceportfoliovorlage können Sie Services mit dem gewünschten Detaillierungsgrad im Serviceportfolio dokumentieren.

Es ist wichtig, die Services im Portfolio auf verschiedene Weise kategorisieren zu können, meist wird jedoch Terminologie verwendet, die den Zweck, das Eigentumsrecht oder die Organisation des Service beschreibt. Zur Unterstützung dieser Kategorisierung oder Klassifikation hat jede Servicepartitionierung die Eigenschaft Classification, die zur Bezeichnung der Klassifikationsart verwendet werden kann. Der Name der Partition wird zu einem Wert in diesem Klassifikationsschema.

Von verschiedenen Unternehmen wurde z. B. das folgende Diagramm (bzw. eine Variante davon) entwickelt, um die Servicetypen im Portfolio besser visualisieren zu können. Beachten Sie, dass diese Kategorisierung - obwohl üblich - nur eine Möglichkeit darstellt, das Serviceportfolio zu segmentieren. In diesem Beispiel wird die Eigenschaft Classification bei allen Partitionen auf "zone" gesetzt.

Im Kontext beschriebene Abbildung

  • Services für Benutzerinteraktion werden verwendet, um zu beschreiben, wie der Benutzer mit der Anwendung interagiert. Wenn beispielsweise ein Service einem Benutzer Arbeit zuordnen muss, müssen Services vorhanden sein, die den Benutzer in geeigneter Form über diese Arbeit benachrichtigen und dann den ursprünglichen Service über deren Fertigstellung benachrichtigen können.
  • Anwendungsspezifische Services sind Services, von denen man annimmt, dass sie für die Wiederverwendung nicht geeignet sind und daher nicht als Teil des Portfolios gelten. Da Services zusammensetzbare Entitäten sind, ist es auch möglich, dass ein Service zwar Bestandteil des Portfolios sein kann, die verschachtelten Services, die er verwendet, jedoch nicht veröffentlicht werden.
  • Prozessintegrationsservices sind Services, die normalerweise über kommerzielle Middleware zur Verfügung gestellt werden und die Servicechoreographie bereitstellen, damit Prozesse in der Middleware aktiviert werden und die Services im Portfolio zur Implementierung eines Prozesses nutzen können.
  • Services für Informationsintegration sind ebenfalls kommerzielle Middleware-Services, die Services für die Vermittlung von Datenformaten und Nachrichteninhalten zwischen Services bereitstellen. Beispielsweise kann eine Kundennachricht von dem Service generiert werden, der eine Aggregation von Daten ist, die von anderen Services im Portfolio abgerufen wurden.
  • Geschäftsservices sind diese Services, die spezifisch für das Geschäft sind, für das Geschäft entwickelt wurden und die Anwendungen, die zur Unterstützung des Geschäfts entwickelt wurden, unterstützen. Beispiele dafür sind CustomerMgmt, Inventory, HR etc.
  • Infrastrukturservices sind Services, die allgemeine IT-Funktionen bereitstellen, die nicht nur für die Geschäftsservices, sondern auch für die Integrationsservices erforderlich sind. Beispiele dafür sind Messaging, Verzeichnis, Authentifizierung, Zugriff auf traditionelle Anwendungen etc.

Weitere Beispiele für Klassifikationsarten finden Sie im Abschnitt Servicepartitionierung.

Service-Repositorys 

Abgesehen von einem Modell des Serviceportfolio ist es wichtig, dass Designer und Entwickler bei Design und Implementierung detailliert auf Servicespezifikationen zugreifen können. Außerdem können mehrere Services dieselbe Spezifikation implementieren, so dass eine Registry, die Abfragen des Formats "alle Services, die die Spezifikation IOrdering implementieren" zulässt, Entwicklern erlaubt, Lösungen aus vorhandenen Services zusammenzusetzen, und Integrationsentwicklern die Möglichkeit bietet, die Services zu bestimmen, die zur Erfüllung geschäftlicher oder technischer Anforderungen verwendet werden.

Service-Repositorys können die Klassifikationswerte, die mit den obigen Servicepartitionen eingeführt wurden, ebenfalls verwenden, um vorab die Werte als Metadaten, die die vom Repository gespeicherten Services beschreiben, festzulegen.

Beispielsweise kann eine Lösung einen Versandservice aufrufen, die Registry kann drei Services mit Versandfunktionen identifizieren, zwei Services mit sicherem Nachrichtenaustausch, einen Service mit Nachrichtenaustausch über Java Message Service (JMS) und einen Service mit SOAP over HTTP. Geschäftsanforderungen geben nur an, dass Kundeninformationen vertraulich gehandhabt werden sollen, und damit ist ein sicherer Nachrichtenaustausch erforderlich. Laut IT-Standards sollte JMS nicht für einen fernen Service verwendet werden, also wurden die Auswahlmöglichkeiten eingeengt.

Im Folgenden werden einige der technischen Implementierungen präsentiert, die gegenwärtig für Service-Registrys verfügbar sind.

  • UDDI. Die Standard-Registry für Web-Services, die sehr verbreitet ist und sowohl Anfragen zur Entwicklungszeit als auch zur Integrationszeit unterstützen sollte. Die Anpassungsstufe, die erforderlich war, um alle einer Servicespezifikation zugeordneten Daten zu überwachen, hat sicherlich einige Fragen darüber aufgeworfen, ob UDDI in seiner heutigen Form ausreicht, um das Serviceportfolio des Unternehmens, das hier erläutert wird, zu unterstützen.
  • RAS-Repository. Die Reusable Asset Specification sollte eine anpassbare Metadatenbeschreibung für wiederverwendbare Assets unterstützen und hat ein Metadatenprofil für Web-Services. RAS wurde zwar nicht entwickelt, um ein Serviceportfolio bereitzustellen, könnte dies für Metadaten der Entwicklungszeit jedoch tun. Allerdings ist das für Abfragen der Integrationszeit gegenwärtig nicht geeignet.
  • Benutzerdefiniert. Viele Organisationen haben angesichts dieser Optionen die Wahl getroffen, benutzerdefinierte Service-Repositorys zu implementieren, die eine Gruppe von Metadaten oder Designdokumenten für Services zur Designzeit sowie zugeordnete Web-Services-Artefakte für die Implementierungszeit verwalten. In den meisten Fällen wird dann bei der Implementierung von Produktionsservices für Abfragen der Integrationszeit ein separates UDDI-Repository verwendet.