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.
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.
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.
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.
Nähere Informationen zur Verbindung zwischen Prozessmodellierung und Serviceidentifikation finden Sie in der
Beschreibung der Aktivität Analyse vorhandener Assets.
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.
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.
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.
[JOHNSTON] Simon Johnston, Sicherheitsfragen in serviceorientierten Architekturen modellieren. IBM
developerWorks 2004.
|