Konzept: Partitionierung der Lösung
In diesem Konzept werden die Prinzipien einer auf verschiedenen organisatorischen Problemstellungen basierenden Partitionierung eines Systems in logische Cluster von Elementen erläutert. Diese Problemstellungen können geschäftliche, physische oder auch abstraktere Grenzen sein.
Beziehungen
Hauptbeschreibung

Einführung

Es wurde schon viel über die Dekomposition von Softwaredesigns in Komponenten oder Subsysteme diskutiert. Es wurde auch schon oft darüber diskutiert, dass es notwendig ist, die Deployment-Technologie, die eine Anwendung in einem frühen Stadium ihres Lebenszyklus benötigt, zu verstehen, damit richtige Entscheidungen hinsichtlich der Architektur getroffen werden können. Es gibt jedoch nur sehr wenige identifizierte oder gegenwärtig verwendete Mechanismen, die die logische Partitionierung eines Systems bei der Architekturanalyse so unterstützen, dass Entscheidungen hinsichtlich der logischen Topologie einer Lösung und der Einschränkungen, die sich durch nicht funktionale Anforderungen ergeben, auf Modellebene einfach bearbeitet werden können, bevor detaillierte Arbeitsergebnisse für das Design und die Implementierung generiert werden. Auf der folgenden Seite wird eine Gruppe einfacher Modellelemente erläutert, die diese Argumentation unterstützen. Diese Verfahren wurden vor dem Hintergrund serviceorientierter Lösungen entwickelt und können auf jede Art von Architekturmodellierung angewendet werden.

Partitionen und Schichten

Die folgenden Definitionen entstammen dem Glossar von Rational Unified Process (RUP) und grenzen die Begriffe "Schicht" (Layer) und "Partition" gegeneinander ab. Interessanterweise erscheint der Begriff Ebene (Tier), obwohl bei der Beschreibung der logischen Architektur einer Lösung üblich, nicht im RUP-Glossar.

Schicht
1) Eine spezielle Art der Gruppierung von Paketen in einem Modell auf derselben Abstraktionsebene.
2) Die Organisation von Klassifikationsmerkmalen oder Paketen auf derselben Abstraktionsebene. Eine Schicht stellt einen horizontalen Sektor, eine Partition hingegen einen vertikalen Sektor in einer Architektur dar.
Partition
1) Tätigkeitsgraphen: Ein Teil eines Tätigkeitsgraphen, der die Zuständigkeiten für Aktionen organisiert. Siehe auch Verantwortlichkeitsbereich.
2) Architektur: Eine Untergruppe von Klassifikationsmerkmalen oder Paketen auf derselben Abstraktionsebene. Eine Partition stellt einen vertikalen horizontalen Sektor, eine Schicht hingegen einen horizontalen Sektor in einer Architektur dar.

Somit enthält eine Partition eine Gruppe von Elementen, die einen Teil der Architektur darstellen, aber wie unterteilt der Softwarearchitekt ein Modell in Sektoren? Die Antwort ist sehr einfach: Partitionen und Schichten sind organisatorische Konstrukte, auf der Ebene der Architektur stellen sie nur die logische Organisation dar. Welche Aspekte der Organisation einer Lösung möchten Sie also darstellen? Wenn die Modellsicht, die Sie entwickeln möchten, sich mit Sicherheit befasst, können Sie Vertrauenszonen (Trust Zones) nach Johnston darstellen.

Weitere Informationen finden Sie in den Abschnitten zu den Konzepten Schichten und Verteilungsmuster.

Was kann eine Partition darstellen?

Wie zuvor gesagt, kann eine Partition verwendet werden, um bestimmte Probleme einer Organisation, auf die der Architekt sich konzentrieren möchte, darzustellen. Im Folgenden werden allgemeine Sichten erläutert, die in einem Modell erstellt werden. Ein wichtiger Aspekt der Partition ist, dass sie keine Eignerschaft bzw. keinen Einschluss impliziert und ein Service somit in mehreren Partitionen gleichzeitig erscheinen kann.

Organisation der logischen Lösung. In diesem Fall stellen die Partitionen das logische Clustering von Elementen in einer bestimmten Lösung dar. Beispielsweise können in einer Geschäftsanwendung Partitionen verwendet werden, um die Trennung in Services für Benutzerinteraktion, Geschäftsservices und Infrastrukturservices darzustellen. Eine solche Sicht entspricht eher der Verwendung von Schichten in RUP, mit denen die Ebenen einer Anwendung beschrieben werden. Da Services nicht einfach in Schichten angeordnet sind wie eine komponenten- oder objektbasierte Lösung, werden Partitionen verwendet. Weitere Informationen zu diesen Serviceklassifikationen finden Sie im Konzept Serviceportfolio.

Im Kontext beschriebene Abbildung

Problemorientierte physische Verteilung. In diesem Fall können Partitionen verwendet werden, um lokale Services im Gegensatz zu fernen Services zu bezeichnen, zumindest, wenn die physische Distanz der Architektur Einschränkungen auferlegt. Es ist z. B. wichtig festzuhalten, dass webb die Kunden-, Account- und Auftragsservices im primären Rechenzentrum und das EDI-Gateway (Electronic Data Interchange) in einem sekundären Rechenzentrum betrieben werden, auch die Bandbreite der Verbindung zwischen diesen Rechenzentren verwaltet und die Kommunikation zwischen diesen Partitionen sorgfältig gesteuert werden muss.
Grenzen für Geschäftsanwendung/Eigentumsrecht. In diesem Fall werden Partitionen verwendet, um das Eigentumsrecht an Services, das ein Geschäftsbereich oder ein Anwendungsbereich hat, darzustellen. Beispielsweise kann man feststellen, dass bestimmte Services hinsichtlich des Eigentumsrechts Personalabteilungen zugeordnet sind, z. B. Verkauf und Marketing. Das ist zwar kein architektonisches Problem, die meisten Projekte müssen sich jedoch mit Fragen auseinander setzen, die keine Technologie oder Architektur, sondern soziale und politische Aspekte der Organisation umfassen. In diesem Zusammenhang bieten Partitionen die Möglichkeit zu verfolgen, wie die Interaktion zwischen Services bestimmte Grenzen überschreiten und sich auf den Entwicklungsprozess auswirken kann, indem sie für organisationsübergreifende Änderungen Unterstützung von Stakeholdern anfordert. Die Kategorien für dieses Modell sind in diesem Fall im Artefakt Geschäftssystem angegeben.
Grenzen für Geschäftsprozesse. In diesem Fall werden End-to-End-Prozessbereiche mit Partitionen dargestellt, die die Services nach den Prozessen, die sie unterstützen, gruppieren. Das folgende Diagramm setzt die Sicht der Geschäftssysteme von der Sicht der Geschäftsanwendung bzw. des Eigners, die als vertikale Balken erscheint, ab. Es ist in vielen Fällen wichtig, diese zwei Sichten für bereits implementierte Services und von einem Projekt geplante Services zueinander in Beziehung zu setzen.

Im Kontext beschriebene Abbildung

Diese Beziehung zwischen dem vertikalen Geschäftsbereich und dem geschäftsübergreifenden Prozess ist wichtig, um zu verstehen, wie die einzelnen Geschäftsbereiche Services für die Prozesse, die die Basis des Geschäfts bilden, bereitstellen. Hinsichtlich des oben genannten Beispiels formiert diese Sicht die zuvor identifizierten Services in neue Partitionen um, wie unten dargestellt.

Im Kontext beschriebene Abbildung

Nähere Informationen zur Verbindung zwischen Prozessmodellierung und Serviceidentifikation finden Sie in der Beschreibung der Aktivität Analyse vorhandener Assets.

Partitionen im Servicemodell

Im Servicemodell wird ein bestimmtes Modellelement, die Servicepartition, zur Modellierung logischer Partitionen verwendet. Die UML-2.0-Darstellung für Partitionen basiert auf der Verwendung des Modellelements Klasse. (Einige Benutzer bevorzugen Untertypen des Modellelements Klasse, z. B. Komponente oder Knoten, sofern diese Untertypen ihren Anforderungen besser entsprechen.) Die Services in einer Partition und die Kommunikation zwischen diesen Services wird durch eine zusammengesetzte Struktur definiert. Das Element Servicepartition ist in den obigen Abbildungen dargestellt und enthält möglicherweise nicht nur Instanzen der Serviceprovider, sondern auch Instanzen anderer Partitionen, und kann somit bei Bedarf weiter unterteilt werden. Eine Servicepartition kann auch eine oder mehrere Service-Gateways angeben, die benannte und typisierte UML-2.0-Ports sind. Diese Ports werden durch Servicespezifikationen auf dieselbe Weise wie ein Service typisiert und können daher als virtuelle Services betrachtet werden, die die Schnittstelle zu einer Partition angeben.

Beachten Sie, dass dieselbe Schnittstelle zum Serviceprovider für den Auftragseingang, die im obigen Diagramm dargestellt ist, auf den Prozessbereich für die Auftragsverwaltung zugreift. Das wird als Umstufung der Schnittstelle vom Service zur Partition bezeichnet. Das folgende Diagramm veranschaulicht das und zeigt, wie der Serviceprovider für den Auftragseingang mit den anderen Services in der Partition kommuniziert.

Im Kontext beschriebene Abbildung

Eine Fähigkeit des Service-Gateway besteht darin, die Kommunikationsbindungen zwischen Clients im äußeren Bereich und Services im inneren Bereich einer Partition zu vermitteln. Das erlaubt Services, nur bestimmte Protokollbindungen innerhalb einer Partition zu einzusetzen, z. B., eine höhere Leistung oder ein sichereres Protokoll innerhalb der Grenzen zu verwenden und Clients über ein anderes Protokoll bestimmte Funktionen zugänglich zu machen. Weitere Informationen finden Sie im Abschnitt zur Aktivität Servicevermittlung.

Beachten Sie auch Folgendes: Da die Partitionen auf der Verwendung von zusammengesetzten UML-2.0-Strukturen basieren, gibt es keine Einschlussbeziehung zwischen der Partition und den Services. Es ist, wie oben dargestellt, möglich, dieselben Services in vielen Partitionen oder Sichten darzustellen. Wenn diese Flexibilität an Service-Gateways gebunden ist, können der Softwarearchitekt und der Designer Services in logischen Gruppen zusammenfassen und Service-Gateways die Möglichkeit bieten, Clients nur relevante Schnittstellen zugänglich zu machen.

Strikte Partitionen angeben

In einer strikten Partition erfolgt der Zugriff auf alle enthaltenen Services durch Clients/Services außerhalb der Partition über Service-Gateways. Dabei wird vorausgesetzt, dass die Servicepartition eine eigene Gruppe von Schnittstellen hat und so als logischer Serviceprovider einer höheren Ebene betrachtet werden kann. Das ist besonders nützlich für Partitionen, die Grenzen für Geschäftsanwendungen oder für Geschäftsprozesse darstellen. Außerdem können so für den dargestellten Prozess die Schnittstellen, die für den Rest des Unternehmens verfügbar gemacht werden, identifiziert werden, und es kann angegeben werden, welche der Services, die den Prozessbereich unterstützen, öffentlich zugänglich sind. Die Partition für die Auftragsverwaltung ist eine strikte Partition, aber das Konzept der "Striktheit" kann nur über die Bewertung einer Partition eingeschätzt werden und ist keine Eigenschaft des Modellelements selbst.

Im folgenden Beispiel kann die Partition auf der linken Seite als strikte Partition angesehen werden, denn der OrderClient (außerhalb der Partition) kann nur über ein Gateway mit dem Provider des Auftragserfassungssystems (OrderEntryProvider) (innerhalb der Partition) kommunizieren. Die Partition auf der rechten Seite des Diagramms kann dagegen nicht als strikte Partition betrachtet werden, denn der Client kommuniziert direkt mit dem Provider des Auftragserfassungssystems (innerhalb der Partition).

Sie sollten sich darüber im Klaren sein, dass die Modellierung strikter Partitionen, ja sogar die Verwendung von Gateways überhaupt, optional ist und nur als ein Tool für die Modellierung einer expliziten Kommunikation zwischen Partitionen zu verstehen ist (unabhängig davon, was diese Partitionen repräsentieren). Bei vielen Zwecken zahlt sich der zusätzliche Systemaufwand möglicherweise nicht aus.

Referenzliteratur

[JOHNSTON] Simon Johnston, Sicherheitsfragen in serviceorientierten Architekturen modellieren. IBM developerWorks 2004.