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.
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.
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.
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.
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.
-
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.
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.
|