\documentclass[11pt,a4paper]{article}

%\usepackage{graphicx}
%\usepackage{ngerman}

%\documentclass[a4paper,12pt]{scrreprt}
\usepackage[latin1]{inputenc}
\usepackage{glossary}
\makeglossary
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage[pdftex]{graphicx}
\usepackage[plainpages=false,pdfpagelabels]{hyperref}
\hypersetup{colorlinks,
	linkcolor=black,
	filecolor=black,
	urlcolor=black,
	citecolor=black}

\begin{document}

\title{Vergleich wichtiger Komponententechnologien bez"uglich ihrer Eignung in SOA}
\author{Harry Trautmann\\
Hochschule f"ur Technik, Stuttgart}
\date{\today}
\maketitle
% Kurzfassung auf Titelseite
\begin{abstract} 
Immer mehr Unternehmen setzen service-orientierte Architekturen (SOA) zur Integration ihrer Gesch"aftsprozesse \glossary{name={Geschäftsprozess}, description={Abfolge von Schritten innerhalb
einer Organisation, um ein bestimmtes Resultat zu erhalten}} ein. Um eine m"oglichst hohe Eignung von neu entwickelter Software f"ur SOA zu erreichen, empfiehlt sich die Verwendung von Komponententechnologie. Im Folgenden
werden die drei momentan wichtigsten Komponententechnologien CCM\glossary{name={CCM}, description={(CORBA Component Model) eine auf CORBA 3.0 basierende Komponententechnologie}}, .NET \glossary{name={.NET}, description={eine von Microsoft spezifizierte Komponententechnologie}} und EJB \glossary{name={EJB}, description={(Enterprise Java Bean(s)) eine auf Java basierende Komponententechnologie; im Singular eine einzelne Komponente}} hinsichtlich
ihrer Eignung f"ur SOA verglichen. Dabei wird ber"ucksichtigt, inwieweit die jeweilige
Komponententechnologie den Charakteristiken von SOA entspricht und wie flexibel die Technologie
gegen"uber sp"ateren Architektur"anderungen reagiert.
\end{abstract}
\thispagestyle{empty}
\pagebreak
\pagenumbering{Roman}
\tableofcontents

%Optional: Liste der Abbildungen und Tabellen
%\listoffigures
%\listoftables

\pagebreak
\pagenumbering{arabic}
\section{Einleitung}
Von Beginn der "Ara an, in der man computergest"utzte Datenverarbeitung in Unternehmen einsetzte, schrieb man eigene Programme, die einzelnen Unternehmenszweigen einen Mehrwert boten. So entstanden beispielsweise Module, die ausschlie"slich dem Finanzwesen dienten, Module, die man nur in der Produktionsplanung nutzte, sowie Module, die externe Kunden zur Kommunikation "uber Datenleitungen nutzen konnten. Doch im Laufe der Zeit zeigte sich, dass es zwar einerseits in hohem Ma"se erstrebenswert war, alle diese Insell"osungen \glossary{name={Insellösung}, description={technisches System, das nur innerhalb der eigenen Grenzen wirksam und zu ähnlichen oder verwandten Systemen inkompatibel ist}} in einer standardisierten Anwendung zu integrieren, aber andererseits auch einen erheblichen Aufwand darstellte.

Beispielsweise w"are es n"otig gewesen, weite Teile eines monolithischen \glossary{name={monolitisch}, description={(in der Informatik) eine Software, deren Architektur technisch und / oder semantisch
nicht in Module aufgeteilt ist}} Altsystems \glossary{name={Altsystem}, description={(engl. Legacy System) eine i. d. R. über lange Zeit verwendete und historisch gewachsene Anwendung im Bereich der Unternehmenssoftware, deren Wartung ausgesetzt wurde, da entweder die Dokumentation unvollständig oder überhaupt nicht vorliegt und / oder die urspr"unglichen Programmierer nicht mehr im Unternehmen angestellt sind (zumeist, da sie den beruflichen Ruhestand antraten)}} umzuschreiben, um sie nach au"sen hin mit den notwendigen Schnittstellen f"ur die Integration auszustatten. Dies stellt jedoch einen erheblichen Aufwand dar, denn meist fehlt Altsystemen die Dokumentation des Quellcodes, w"ahrend die urspr"unglichen Programmierer bereits im Ruhestand oder zumindest nicht mehr im Unternehmen sind. Dadurch wird es extrem schwierig, sicher zu stellen, dass die umgeschriebene Software noch die gleiche Funktionalit"at bietet.

Um die Altsysteme also nicht ver"andern zu m"ussen und ihre Verf"ugbarkeit dennoch effektiv auf
das ganze Unternehmen zu erweitern, werden sie "uber eine spezielle Schnittstellenschicht zu einer so genannten service-orientierten Architektur (SOA) \glossary{name={SOA}, description={Paradigma zur Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird\cite{Oasis2006}}} erg"anzt. Gerade diese F"ahigkeit, Altsysteme fast unver"andert zu integrieren, macht SOA zu einem wichtigen Thema f"ur die meisten gro"sen Unternehmen.

Damit man bei neu entwickelter Software nicht dieselben Fehler begeht wie bei Altsystemen, und gleichzeitig die Eignung f"ur eine Integration in eine SOA erh"oht, wird oft die Komponententechnologie \glossary{name={Komponententechnologie}, description={Spezifikation für Syntax und Semantik von (Software-)Komponenten; i. d. R. werden auch grundlegende Dienste zur Erstellung, Aktivierung und Deaktivierung von Komponenten bereitgestellt}} eingesetzt. Mittels Komponententechnologie k"onnen Architekturen besser modularisiert und die einzelnen Gesch"aftsprozesse besser gekapselt werden. Au"serdem erh"oht sich die Wiederverwendbarkeit der Module, und die Versionierung\glossary{name={Versionierung}, description={archivisches Verwaltungssystem von alternativen Programmversionen; im Rahmen der Komponententechnologien dient die Versionierung dazu, die Kompatibilität von Programmen sicher zu stellen, die auf unterschiedliche
Versionen von Komponenten zugreifen}}, sowie das Deployment \glossary{name={Deployment}, description={Verteilung, Konfiguration und Installation von Software auf einem Zielsystem}} werden
beg"unstigt.

Da sich in den letzten zehn Jahren mehrere Komponententechnologien etablierten, sollen im Folgenden die drei wichtigsten daraufhin verglichen werden, welche davon sich f"ur die Implementierung einer SOA am besten eignet. Zun"achst werden Aufbau und Funktionsweise der drei ausgew"ahlten Technologien CCM, .NET und EJB beleuchtet. Darauf folgt die Darstellung der Charakteristiken von SOA. Die anschlie"sende Einsch"atzung der Eignung dieser Komponententechnologien f"ur SOA ist aufgeteilt in die Untersuchung, wie sehr die einzelnen Komponententechnologien den Charakteristiken von SOA entsprechen, sowie eine Betrachtung der Flexibilit"at gegen"uber Architektur"anderungen. Ein Fazit mit einem Ausblick auf die zu erwartende Zukunft von SOA schlie"st die Untersuchung ab.

\section{Umfeld}
\subsection{Komponententechnologien}
Eine Komponententechnologie spezifiziert nach \cite[S. 261]{Andresen2004} die Syntax und Semantik von Komponenten und stellt eine zugeh"orige Laufzeitumgebung \glossary{name={Laufzeitumgebung}, description={(engl. Runtime Environment) ein meist vom Betriebssystem abhängiges Programm, das Dienste zur Interpretation und Ausführung von Programmen dient, die einem speziellen Protokoll folgen und / oder in einen Bytecode vorkompiliert wurden}} bereit. Diese Laufzeitumgebung verf"ugt "uber
grundlegende Dienste, wie z. B. zur Erzeugung, Aktivierung und Deaktivierung von Komponenten, sowie weitere Dienste \glossary{name={Dienst}, description={wohldefiniertes, in sich abgeschlossenes Modul, das standardisierte, für einen Geschäftsprozess charakteristische Funktionalität bereitstellt und unabhängig von Zustand oder Kontext anderer Dienste ist \cite[S. 1]{Papazoglou2007}}} f"ur Persistenzmanagement,
%\glossary{name={Persistenz}, description={todo}}
Transaktionen,
%\glossary{name={Transaktion}, description={todo}}
Sicherheit und Verzeichnisdienste. Die
jeweilige Technologie kann auf spezifischen Application Servern\glossary{name={Application Server}, description={Software, die als Umgebung für den Ablauf von Anwendungen dient und ihnen besondere Dienste zur Verfügung stellt}}, als auch auf spezifischer Middleware \glossary{name={Middleware}, description={Programme, die zwischen anderen Anwendungen vermitteln mit dem Ziel, die Komplexität dieser Kommunikation 
zu verbergen}} basieren.

	In den letzten zehn Jahren wurden diverse Standards f"ur Komponententechnologien entworfen. Doch 
haben sich nur wenige davon in breitem Ma"se durchgesetzt. Die drei wichtigsten sind CCM, EJB und .NET.
Um Unterschiede in Konzepten und Aufbau darzustellen werden sie im Folgenden beschrieben.

\subsubsection{CORBA Component Model}
CORBA \glossary{name={CORBA}, description={(Component Object Request Broker Architecture) von der Object Management Group zusammengestellter Standard für Middleware}}ist ein plattform- und sprachunabh"angiger Standard f"ur Middleware und wurde von der
Object Management Group (OMG) zusammengestellt, welche damals von ca. 800 Firmen gebildet wurde.
CCM (CORBA Component Model) ist ein auf CORBA aufgesetzter Komponentenstandard.
W"ahrend CORBA die semantischen Zusammenh"ange von Programmmodulen im Gro"sen beschreibt,
ist CCM ein konkretes Modell f"ur die Programmierung. CCM regelt die Definitionen der
Komponentenschnittstellen, -lebenszyklus, -zust"ande und -vertr"age. Desweiteren bietet 
CCM Funktionalit"aten zur Verpackung und Verteilung von Komponenten \cite[S. 270]{Andresen2004}.

	Grundlegend f"ur CORBA ist der ORB (Object Request Broker). Dies ist eine Schicht, in der 
notwendige Basis-Services implementiert sind. Der ORB stellt den Komponenten und Komponenten-Containern\glossary{name={Container}, description={(Komponenten-) ein Programm, das eine oder mehrere Komponenten enthält}} Transaktions-, Sicherheits-, Benachrichtigungs- und Persistierungsdienste zur Verf"ugung \cite[S. 274]{Andresen2004}.

	CCM-Komponenten sind stets in eine Container-Struktur eingebettet. Diese Struktur bildet f"ur
die Komponente die Laufzeitumgebung und verwaltet ihren Lebenszyklus. Das hei"st, dass der
Container die konkrete Erstellung und Freigabe der Komponente veranlasst, sowie Anfragen an
die API \glossary{name={API}, description={(Application Programming Interface) von einem Programm bereitgestellte Schnittstelle, die dazu dient, von außerhalb des Programms Einfluss auf den Ablauf des Programms zu nehmen oder einzelne Teile davon aufzurufen}} der Komponente und Anfragen der Komponente an externe Komponenten-APIs ausf"uhrt.
	Dabei verwaltet der POA (Portable Object Adapter) die Referenzen
%\glossary{name={Referenz}, description={todo}}
auf externe (evtl. entfernte) Instanzen von CORBA-Komponenten. Das "`Component Home"'-Interface \glossary{name={Interface}, description={(dt. Schnittstelle) eine von einem Protokoll festgelegte Austauschweise für Informationen; im Rahmen der Komponententechnologien bezieht sich der Begriff auf die semantische Bedeutung sowie deren technische Implementierung von Methoden und Objekten des Komponentenmodells}} ist ein vom ORB verwaltetes Objekt, welches dazu dient, das Instanzieren \glossary{name={Instanzieren}, description={ein individuelles Abbild einer Klasse, das über einen eigenen Speicherbereich verfügt, (Instanz) erzeugen}} und die Einbettungen von Komponenten zu kontrollieren.
Da mehrere unterschiedliche Implementierungen des CORBA-Standards existieren, wurde der POA ab CORBA
2.0 notwendig, um instanzierte Komponenten zwischen den unterschiedlichen Implementierungen portabel
zu halten \cite[S. 146]{Qian2005}.

	In Abbildung 1 wird der Aufbau dargestellt, wie CCM-Komponenten, -Container, die jeweiligen Schnittstellen, sowie der ORB zusammenarbeiten.

%\setlength{\hoffset}{-30}
\begin{figure}
	\includegraphics[width=1.00\textwidth,keepaspectratio]{model_CORBA_v2.png}
	\caption{Einbettung von Komponenten in einer CCM-Architektur \cite[S. 275]{Andresen2004}}
	\label{fig:model_CORBA}
\end{figure}
%\setlength{\hoffset}{0}
CCM-Komponenten stellen sich nach au"sen "uber vier Arten von Schnittstellen dar.
\begin{enumerate}
	\item Facets: sie sind die zur Komponente externe Schnittstelle f"ur die Gesch"aftslogik der Komponente.
	\item Receptables: sie sind nach au"sen ver"offentlichte Referenzen auf externe Komponenten/Systeme.
	\item Event Sources: sie dienen der Ver"offentlichung von in den Komponenten erzeugten Ereignissen.
	\item Event Sinks: sie sind Empf"anger von zur Komponente extern erzeugten Ereignissen.
\end{enumerate}

\subsubsection{.NET}
Das .NET-Framework \glossary{name={Framework}, description={(dt. Rahmengerüst) der beschleunigten Programmierung dienende implementierte Klassen und Hilfsprogramme}} wurde von der Microsoft Corporation entwickelt und 2000 ver"offentlicht. Es dient der schnellen
Erstellung und Bereitstellung von Softwarekomponenten. Die Implementierung des .NET-Frameworks von Microsoft l"auft nur auf den Windows-Betriebssystemen. Allerdings erweitert das "`Mono Project"' mit einer eigenen Implementierung die Lauff"ahigkeit auch auf die Betriebssysteme Linux, Solaris, Mac OS X und Unix \cite{Mono2007}.

	Die Basis des Frameworks bildet der CLR-Dienst (Common Language Runtime) \glossary{name={CLR}, description={(Common Language Runtime) Laufzeitumgebung im .NET-Framework; dient der Ausführung von Assemblies}}. Es ist eine virtuelle Maschine \glossary{name={virtuelle Maschine}, description={Software, die eine virtuelle Laufzeitumgebung bereitstellt, so dass Bytecode ausgeführt werden kann}}, die sogenannte Assemblies\glossary{name={Assembly}, description={Bezeichnung für .NET-Komponenten \cite[S. 26]{Qian2005}}} ausf"uhren kann. Dies wiederum sind vorkompilierte \glossary{name={Kompilieren}, description={Vorgang des Umwandelns des Quelltextes eines Programms in ein Binärprogramm}}, in dem Bytecode-Format\glossary{name={Bytecode}, description={i. d. R. maschinenunabhängige Sammlung von Befehlen, die von einer virtuellen Maschine interpretiert werden}} MSIL (Microsoft Intermediate Language)\glossary{name={IL}, description={(Intermediate Language) eine Sprache, die der Definition von Assemblies dient}} vorliegende Bin"arprogramme\glossary{name={Binärprogramm}, description={Programm, das als binär repräsentierte Anweisungen vorliegt}}.

	Au"serdem enth"alt das .NET-Framework eine Klassenbibliothek\glossary{name={Klassenbibliothek}, description={Sammlung von fertig gestellten Klassen}} mit \linebreak
grundlegenden Klassen\glossary{name={Klasse}, description={(in der Objektorientierung) die Beschreibung der gemeinsamen Struktur und des gemeinsamen Verhaltens von Objekten}}, sowie grundlegende Dienste zur
Ver"offentlichung von Funktionalit"at "uber das Web (ADO.NET) oder als Anwendung f"ur die Oberfl"ache von Windows (Windows Forms).

	Abbildung 2 stellt den groben Aufbau des .NET-Frameworks dar.

	.NET-Komponenten sind selbstbeschreibende Assembly-Dateien. Dabei kann eine Komponente wiederum aus
mehreren weiteren in MSIL vorliegenden Modulen bestehen und andere Komponenten, sowie Klassen der .NET-Klassenbibliothek referenzieren. Eine .NET-Komponente besteht aus den folgenden vier Teilen \cite[S. 200]{Qian2005}:
\begin{enumerate}
	\item einem Manifest (enth"alt u. a. Versionsnummer, einen eindeutigen Namen und Definitionen der verwendeten Typen),
	\item Metadaten \glossary{name={Metadaten}, description={Daten, welche Informationen über andere Daten enthalten}} der beteiligten Module,
	\item IL-Code der Module und
	\item Ressourcen (wie beispielsweise Bilddateien).
\end{enumerate}

Wenn .NET-Komponenten ausgef"uhrt werden sollen, l"adt zun"achst der CLR-Class Loader das entsprechende Assembly und die evtl. referenzierten Klassen aus der .NET-Klassenbibliothek. Danach erzeugt der JIT-Compiler so genannten "`Managed Native Code"'. Das sind in Maschinensprache des jeweiligen Betriebssystem, auf dem die Komponente ausgef"uhrt werden soll, vorliegende bin"are Anweisungen, die vorher auf Sicherheit hinsichtlich Speicherzugriffen, Abl"aufen von Threads \glossary{name={Thread}, description={ein einzelner Ausführungsstrang bei der Abarbeitung von Computerprogrammen}} und Systemschutz gepr"uft wurden. Die CLR-Ausf"uhrungseinheit f"uhrt den Managed Native Code aus.

\begin{figure}[htb]
	\centering
	\includegraphics[width=0.50\textwidth]{model_dotNETFramework_v2.png}
	\caption{Aufbau des .NET-Frameworks \cite[S. 196]{Qian2005}}
	\label{fig:model_dotNETFramework}
\end{figure}

\subsubsection{Enterprise Java Beans}
Die EJB-Komponententechnologie ist eng an die J2EE-Plattform gebunden\glossary{name={J2EE}, description={(Java 2 Enterprise Edition) Spezifikation einer Softwarearchitektur für transaktionsbasierte Ausführung von Java-Anwendungen; insbesondere stellt J2EE den Rahmen für die
Verwendung von EJB zur Verfügung}}. Die J2EE-Plattform wurde 
prim"ar f"ur die Entwicklung von Unternehmensdiensten (Enterprise Services) entworfen und bietet 
den EJB per Design essentielle Dienste, wie beispielsweise Transaktionsmanagment, Persistenzmanagement und Verwaltung ihres Lebenszyklus an. Somit k"onnen bei EJB-Implementierungen diese Aspekte au"ser Acht gelassen werden, so dass sich der Code voll auf die Umsetzung der Gesch"aftslogik \glossary{name={Geschäftslogik}, description={Ablaufbeschreibung der Interaktion von
Geschäftsprozessen miteinander}} konzentriert. Eine J2EE-Architektur
wird im Allgemeinen in die folgenden semantischen Bereiche (die sogenannten Tiers) \glossary{name={Tier}, description={eine einzelne Schicht in einem mehrschichtigen Architektur einer Anwendung}} aufgegliedert.
\begin{enumerate}
	\item Client-Tier: diese Ebene enth"alt die Funktionalit"at zur Interaktion des Benutzers mit dem System. Oft werden Java-Anwendungen wie Browser diesem Tier zugerechnet.
	\item Web-Tier: hierin wird die Information aufbereitet, die entweder dem Business-Tier entnommen wird oder vom Client erhalten zum Business-Tier weitergeleitet werden soll.
	\item Business-Tier: die Gesch"aftslogik des Systems befindet sich im Busi\-ness-Tier. EJB geh"oren in diesen Tier.
	\item EIS-Tier
%\glossary{name={EIS}, description={todo}}
: dieser Tier dient der Anbindung des J2EE-Systems an "`Enterprise Information Systeme"'. Das k"onnen beispielsweise externe Datenbanksysteme oder Host-Anwendungen sein.
\end{enumerate}
	EJB k"onnen erst zusammen mit einer Laufzeitumgebung genutzt werden. Der EJB-Server stellt eine
solche zur Verf"ugung. Der EJB-Server bietet den EJB grundlegende Dienste wie Verwaltung von Prozessen und Threads an,
aber auch komplexe, wie beispielsweise einen Dienst f"ur das Zusammenlegen gleichartiger Instanzen 
von Netzwerk- und Datenbankenressourcen, so dass mehrere EJB sie gemeinsam nutzen k"onnen.

	Auch EJB werden innerhalb Containern ausgef"uhrt. Sie abstrahieren die EJB-Schnittstellen nach au"sen, so dass externe Zugriffe auf die EJB-Schnittstelle vom Container kontrolliert werden. Au"serdem bietet der Container einer EJB-Komponente die Implementierung allgemeiner Funktionalit"aten wie Sicherheits-, Konstruktions-\glossary{name={Konstruktion}, description={Vorgang der Instanzierung eines Objekts einer Klasse}} und Destruktionsmechanismen \glossary{name={Destruktion}, description={Vorgang der Freigabe von durch ein Objekt gebundenen Ressourcen}} an. Dadurch kann der Code der EJB in noch h"oherem Ma"s auf die eigentliche Gesch"aftslogik konzentriert werden. Die Container werden "uber die J2EE-Plattform oder von J2EE-konformen Tools bereitgestellt.

	EJB-Container verf"ugen "uber sogenannte Connector-Objekte, die dazu dienen, J2EE-externe Systeme des EIS-Tiers an die J2EE-Architektur anzubinden \cite[S. 269]{Qian2005}.
	
	Abbildung 3 visualisiert den Zusammenhang zwischen EJB-Komponente, -Container, -Server, sowie externen Systemen.
	
	Auf den Systemen liegen EJB in Form von JAR-Dateien, wodurch alle Teile der Komponente innerhalb einer einzelnen Datei gekapselt (und optional gepackt) vorliegen.

\begin{figure}[htb]
	\includegraphics[width=1.00\textwidth,keepaspectratio]{model_EJB_v2.png}
	\caption{Einbettung von Komponenten in eine EJB-Architektur \cite[S. 269]{Andresen2004}}
	\label{fig:model_EJB}
\end{figure}

\subsection{Service-oriented Architecture}
Nachdem die relevanten Eigenschaften der zu betrachtenden Komponententechnologien aufgef"uhrt wurden,
m"ussen auch die Kriterien eingehender ausgef"uhrt werden, mittels denen sich ihre Eignung f"ur SOA
bewerten l"asst.
	Zun"achst soll der Begriff SOA gekl"art werden, um dann auf die wichtigsten Charakteristiken
einzugehen.

\subsubsection{Definition}
%Mit der Etablierung verteilter Computersysteme ergaben sich zwei Hauptprobleme: Heterogene (da propriet"are) \glossary{name={proprietär}, description={nicht allgemein anerkannten Standards entsprechend}} Standards und enge Kopplung \glossary{name={enge Kopplung}, description={geringe Flexibilität bezüglich der Kombination und Rekombination von Komponenten}} existierender Systemmodule aneinander. Dies erzeugte die Problematik inkompatibler und schwer zu wartender Systeme. 
Moderne Anforderungen, wie z. B. globale Verf"ugbarkeit von Programmfunktionalit"at und notwendige Kosteneinsparung bei der Wartung, f"uhrten dazu, die vorhandenen Dienste einer Software-Architektur mit einer offenen Schnittstellenschicht auszustatten, um ihre Funktionalit"at in anderer Software wieder verwenden zu k"onnen.
Das erm"oglichte Architekturen, deren Aufbau sich an den zur Verf"ugung stehenden Diensten ausrichtet. Obwohl dies den SOA entspricht, existiert derzeit immer noch keine einheitliche Definition des Begriffs "`Service-orientierte Architektur"'.
Entsprechend \cite[S. 32]{Gartner2007} wird er im Folgenden verstanden als Stil einer Anwendungsarchitektur, bei der die von der Anwendung "uber Metadaten bereitgestellten und von der Implementierung getrennten Schnittstellen der unterliegenden Gesch"aftsprozesse wiederholt von unterschiedlichen Konsumenten aufrufbar sind.

\subsubsection{Charakteristiken}
Um die Eignung einer Komponententechnologie f"ur den Einsatz in SOA beurteilen zu k"onnen, mu"s zuvor eine Charakterisierung der Eigenschaften von SOA vorgenommen werden. Dann k"onnen die Eigenschaften der jeweiligen Technologie dagegen verglichen werden. Im Zusammenhang mit den Komponententechnologien
werden die folgenden Charakteristiken als bedeutend identifiziert.
\begin{itemize}
	\item Fokussierung auf Gesch"aftsprozesse: jede durch eine SOA bereitgestellte Schnittstelle repr"asentiert einen Gesch"aftsprozess in Form einer Black Box. Komponententechnologien, die eine Trennung Gesch"aftslogik und deren Pr"asentation beg"unstigen, sind daher im Vorteil.
	\item Lose Kopplung \glossary{name={lose Kopplung}, description={Beziehung zwischen einem Dienst und
einem Konsumenten, wobei der Konsument bei Anforderung des Dienstes keinen ausschlie"slichen Zugriff darauf erhält}} von Diensten:	Dienste sind lose gekoppelt, wenn kein Konsument des Dienstes ausschlie"slichen Zugriff darauf erh"alt.
Daraus resultiert eine hohe Flexibilit"at f"ur Dienste bez"uglich ihrer internen Kombination und Rekombination. Diese "Anderungen in ihrer internen Zusammenstellung wirken sich dann weniger gravierend auf die dar"uberliegende Architektur aus.
%Diese standardisierte Interoperabilit"at\glossary{name={Interoperabilität}, description={Fähigkeit zur Zusammenarbeit heterogener Systeme}} \cite[S. 52]{Taylor2006} erm"oglicht die sogenannte Service-Orchestrierung\glossary{name={Service-Orchestrierung}, description={Erstellung eines neuen Service, der ausschließlich aus bereits bestehenden Diensten zusammengesetzt ist}} - die Erstellung eines neuen Dienstes, der ausschlie"slich aus bereits bestehenden Diensten zusammengesetzt ist.
Somit ist eine Komponententechnologie besser f"ur SOA geeignet, je flexibler ihre Komponenten zur Laufzeit zusammengestellt werden k"onnen.

	\item Skalierbarkeit\glossary{name={Skalierbarkeit}, description={Verhalten des Wachstums an Ressourcenbedarf von Programmen bei ver"anderter Eingabemenge}}: SOA werden vornehmlich im Umfeld der Web Economy \glossary{name={Web Economy}, description={eine vom Kommerz mit den (neuen) Kommunikationsmedien des Internet geprägte Wirtschaftsform; der auf das Web ausgerichtete Zweig der New Economy}} eingesetzt. Dort ist es eine "ubliche Anforderung an eine Software, einer gro"sen Anzahl von Anfragen an Dienste frei von Verz"ogerungen nachzukommen \cite{Becking2007}. Daher ist eine Komponententechnologie umso besser f"ur SOA geeignet, je besser sie unter Last von Anfragen skaliert, um der Bedienung vieler Konsumenten frei von Verz"ogerungen nachzukommen.
\end{itemize}

\section{Entsprechung gegen"uber SOA-Charakteristiken}

\subsection{Fokussierung auf Gesch"aftsprozesse}
Um eine SOA wiederverwendbar zu halten, muss bereits in der Technologie, welche die SOA implementiert, eine m"oglichst weit gehende Trennung zwischen der Gesch"aftslogik und ihrer Pr"asentation vorhanden
sein.
\begin{itemize}
	\item Mit Hilfe von unterschiedlichen Container-Klassen erzwingt die J2EE-Plattform eine Trennung
zwischen Gesch"aftslogik und deren Pr"asentation. Dabei sind f"ur die Implementierung von Gesch"aftslogik Klassen vorgeschrieben, die auf den EJB aufbauen. F"ur die Pr"asentation m"ussen
Klassen auf Basis von JSP \glossary{name={JSP}, description={Java Server Page}} oder Servlets \glossary{name={Servlet}, description={spezielle Java-Klassen, die innerhalb eines J2EE-Applikationsservers dazu dienen, Anfragen von Clients zu beantworten}} verwendet werden.
	\item CCM schreibt keine derartige Trennung vor. Eine Fokussierung auf Gesch"aftsprozesse ist daher
nicht inh"arent gegeben.
	\item .NET schreibt keine Trennung vor, bietet aber mit der Bereitstellung von entsprechenden Klassen in der ASP.NET-Klassenbibliothek eine Hilfestellung daf"ur.
\end{itemize}

\subsection{Lose Kopplung}
Eine grundlegende Eigenschaft von SOA ist ihre Flexibilit"at hinsichtlich der Komposition miteinander. Dabei kommt es zwangsl"aufig dazu, dass Komponenten unter ge"anderten Parametern verwendet werden m"ussen. Daher ist es von Vorteil, wenn ein Komponentenstandard die erneute Konfiguration einer Komponenteninstanz einfach gestaltet.
\begin{itemize}
	\item EJB werden in JAR-Dateien verpackt, die auch einen so genannten Deployment-Descriptor mit umfangreichen Einstellm"oglichkeiten enth"alt. Der Deployment-Deskriptor enth"alt u. a. die Versionierungsinformationen und kann auch nach Ver"offentlichung noch ge"andert werden, ohne dass die Komponente neu erstellt werden muss \cite[S. 291]{Andresen2004}. Dies stellt innerhalb SOA einen Vorteil dar.
	\item Wenn eine neue CCM-Komponente bereitgestellt werden soll, ist es lediglich notwendig, deren in IDL (Interface Definition Language) \glossary{name={IDL}, description={(Interface Definition Language) eine deklarative formale Sprache, die der Beschreibung von Schnittstellen von Software-Komponenten dient}} spezifizierte Schnittstellen um die neuen Schnittstellen zu erweitern und die bestehende Komponente mit der neu kompilierten zu ersetzen \cite[S. 233]{Andresen2004}. Somit ist es auf relativ unkomplizierte Art m"oglich, die Konfiguration eines Systems, das auf CCM-Komponenten aufbaut, zu "andern.
	\item .NET unterst"utzt die Ber"ucksichtigung der Verteilung von Komponenten w"ahrend ihrer Zusammenstellung (Component Assembly Deployment). Dadurch k"onnen mehrere Versionen von Komponenten desselben Namens nebenher ohne Konflikt koexistieren. \cite[S. 195]{Qian2005}
\end{itemize}

\subsection{Skalierbarkeit}
Die Komponententechnologien bieten diverse Techniken an, um die Systemressourcen \glossary{name={Systemressource}, description={die auf einem Computer verfügbaren Betriebsmittel, i. d. R. Rechenzeit und Speicherplatz}} zu schonen. Einige dieser Techniken verfolgen das Ziel, die 
Antwortszeit des Systems auch unter einer sich dynamisch ver"andernden Last von Anfragen stabil zu halten und dienen damit der Skalierbarkeit. Hier wird beleuchtet, welche dieser Techniken das sind.
\begin{itemize}
	\item EJB-Server verf"ugen "uber Mechanismen f"ur den Zusammenschlu"s gleicher Datenbankverbindungen und EJB-Instanzen, sowie deren Ablage in einem Cache \glossary{name={Cache}, description={ein Speicherbereich mit geringer Zugriffszeit, der Kopien von Inhalten anderer (langsamerer) Speicherbereiche enthält mit dem Ziel, den zukünftigen Zugriff auf diese Inhalte zu beschleunigen}}. Somit ist die EJB-Technologie sehr gut skalierbar. \cite[S. 288]{Andresen2004}
	\item Skalierbarkeit kann in CCM durch Verwendung unterschiedlicher Container erreicht werden \cite[S. 289]{Andresen2004}. Dies verlangt also, dass bereits w"ahrend des Kompilierens bekannt sein muss, wie das System skalieren muss. Soll zu einem sp"ateren Zeitpunkt auf einen flexibleren Container gewechselt werden, muss ein neues Deployment stattfinden. Insofern ist CCM prinzipiell, aber nicht besonders flexibel skalierbar.
	\item Innerhalb des .NET-Framework sorgen die ASP.NET- und ADO.NET-Module f"ur die Ablage von Datenbankverbindungen und Statusinformationen der Instanzen in einem Cache. Wie gut eine .NET Architektur skaliert, h"angt aber vor allem auch von der Konfiguration \glossary{name={Konfiguration}, description={eine bestimmte Einstellung von Software oder Hardware}} des Backend \glossary{name={Backend}, description={(dt. hinteres Ende) in einer Client-Server-Architektur die Ebene der Server}} ab \cite[S. 289]{Andresen2004}.
\end{itemize}

\section{Flexibilit"at bei Architektur"anderungen}
Neben der "Uberdeckung der SOA-Charakteristiken ist auch entscheidend, wie flexibel sich eine
auf Komponententechnologie basierende Architektur ver"andern l"asst. Denn einmal vorliegende Architekturen tendieren dazu, erweitert zu werden, ebenso wie die Anforderungen und das Umfeld
einer Software dazu tendieren, sich in unerwarteter Weise zu "andern. Im Kontext der SOA wird
dieser Umstand noch versch"arft, da man Dienste auch dynamisch zusammengestellen k"onnen soll.
Flexibilit"at einer Komponententechnologie definiert sich daher aus deren Grad an Ungebundenheit
von Plattform, Programmiersprache und Hersteller.

\subsection{Plattformunabh"angigkeit}
Plattformunabh"angigkeit meint hier die Losl"osung vom unterliegenden Betriebssystem, nicht die Losl"osung vom unterliegenden Middleware-Standard, der ja ebenfalls als Plattform bezeichnet wird.
\begin{itemize}
	\item Die EJB sind durch Verwendung von Java als unterliegende Sprache prinzipiell plattformunabh"angig, da die Implementierung einer JVM \glossary{name={JVM}, description={(Java Virtual Machine) die Laufzeitumgebung für Java-Programme, die zu Bytecode kompiliert wurden}} f"ur moderne Betriebsysteme mandatorisch ist.
	\item Auch CCM ist prinzipiell plattformunabh"angig, denn eines der wesentlichen Ziele beim Entwurf des CCM unterliegenden Middleware-Standards CORBA war es, f"ur CORBA-Architekturen Abh"angigkeit vom Betriebssystem zu eliminieren.
	\item Das .NET-Framework ist von Microsoft nur auf den Windows-Betriebs\-systemen implementiert. Doch durch das "`Mono Project"' existieren auch f"ur eine Reihe weiterer Betriebssysteme Umsetzungen des .NET-Frameworks. Somit sind auch .NET-Komponenten plattformunabh"angig \cite{Mono2007}. 
	
	TODO Mono einf"ugen
\end{itemize}

\subsection{Sprachunabh"angigkeit}
\begin{itemize}
	\item EJB k"onnen nur in Java programmiert werden und setzen die Verwendung von Klassen aus der J2EE voraus. Damit ist die EJB-Technologie in hohem Ma"s sprachabh"angig.
	\item CCM-Komponenten setzen keine bestimmte Programmiersprache voraus.
	\item .NET-Komponenten k"onnen in einer Vielzahl von Sprachen erstellt werden. Derzeit werden die meisten Komponenten in VB 6.0, VB 7.0, VC.NET und C\# geschrieben, da dies die ersten Sprachen waren, f"ur die es IL Compiler f"ur das .NET-Framework gab.
\end{itemize}

\subsection{Herstellerbindung}
\glossary{name={Herstellerbindung}, description={Freiheitsgrad in der Beziehung zwischen einer Software und ihrem Ersteller}} Die Abh"angigkeit einer Technologie vom Hersteller hat zwei Seiten. Zum einen stellt dies die Anh"angigkeit von Pl"anen dar, die der Hersteller in Zukunft mit der Technologie verfolgt (z. B. Unterst"utzung, Erweiterungen). Zum anderen bedeutet das aber auch, dass diese Pl"ane zeitnah umgesetzt werden k"onnen, statt dass sich mehrere Parteien zuerst "uber ein Vorgehen einig werden m"ussen. Insofern muss vor Verwendung der jeweiligen Technologie abgewogen werden, ob eher die Unabh"angigkeit von einem Hersteller oder ein beschleunigter Reifeprozess der Technologie als wichtiger zu bewerten ist.
\begin{itemize}
	\item EJB ben"otigt die J2EE-Plattform. Diese wird aber von mehreren gros\-sen Unternehmen (z. B. Sun Microsystems, Oracle, JBoss Inc.) angeboten, wodurch die EJB-Technologie herstellerunabh"angig ist.
	\item CORBA, wie auch CCM, wurden von einem Zusammenschluss aus mehreren hundert Firmen entworfen. Somit ist CCM nicht spezifisch von einem Hersteller abh"angig.
	\item Aufgrund der Existenz des "`Mono Projects"' besteht die Wahl, ob man lieber die Implementierung von Microsoft einsetzt oder die Open-So\-urce-Implementierung des "`Mono Projects"'. Die Implementierung von Microsoft ist zwar einerseits an die Windows-Betriebssysteme gebunden. Andererseits pflegt Microsoft sie sorgf"altig, beispielsweise, indem es zeitnah mit Updates auf Sicherheitsl"ucken in der Frame\-work-Implementierung reagiert. Die "`Mono"'-Implementierung befreit von der Abh"angigkeit von Microsoft, gibt allerdings keine Gew"ahr.
\end{itemize}

\section{Weitere g"unstige Eigenschaften}
Im Folgenden sollen einige Eigenschaften der betrachteten Technologien untersucht werden, die zwar nicht notwendig sind, deren Vorliegen aber die Eignung f"ur SOA beg"unstigt. Zumeist lassen sich aufgrund dieser Eigenschaften die "ublichen SOA-Einsatzzwecke leichter umsetzen.

\subsection{Sicherheitsmechanismen}
SOA schreibt keine besonderen Sicherheitsma"snahmen vor. Sowohl Konsumenten, als auch Dienstleister sind selbst in der Pflicht, f"ur geeigneten Schutz zu sorgen. Insofern wird jeglicher von einer Komponententechnologie bereitgestellter der Sicherheit dienender Mechanismus als positiv bewertet.
\begin{itemize}
	\item Die EJB-Technologie nutzt die J2EE-Sicherheitsmechanismen, welche auf denjenigen des darunterliegenden Betriebssystems aufbauen. "Uber Rollen kann der Zugriff bis auf Methodenebene eingeschr"ankt werden \cite[S. 289]{Andresen2004}.
	\item CCM verf"ugt "uber ein "ahnliches Rollen-System wie die EJB-Tech\-no\-lo\-gie basierend auf CORBA.
	\item Beim .NET-Framework wird zwischen Authentifizierung, Autorisie\-rung und Personifizierung unterschieden. Um eine Zugriff auf das System zu erlangen, muss ein Dienstkonsument erst jede dieser Stufen durchlaufen.
\end{itemize}

\subsection{Kostentransparenz}
Oft soll mittels einer SOA die Kostentransparenz \glossary{name={Kostentransparenz}, description={Offenlegung der Verbrauchs an Ressourcen (Kosten)}} eines Systems erh"oht werden. Man soll nachvollziehen k"onnen, welche Teile des Systems wie viele der vorhandenen Ressourcen in Anspruch nehmen. Insbesondere ist dies dann wichtig, wenn extern ver"offentlichte Dienste Kunden berechnet werden sollen \cite{Koll2007}.
\begin{itemize}
	\item Das J2EE-Konzept unterst"utzt weitgehende Trennung zwischen dem eigentlichen Gesch"aftsprozess und dessen Pr"asentation. Somit f"allt es bei Verwendung der EJB leichter, die Kosten zu berechnen.
	\item Das CCM ist ein sehr fein granulierter Komponentenstandard. Die Verwendung von externen Klassenbibliotheken ist nicht vorgeschrieben. Dadurch wird ein tiefer Einblick in die Abl"aufe des Systems m"oglich, was bedeutet, dass tief greifende Kostentransparenz m"oglich, aber unter Umst"anden auch kompliziert zu implementieren ist.
	\item Falls die .NET-Klassenbibliotheken ASP.NET und ADO.NET verwendet werden, k"onnen die von diesen Klassen verursachten Aufw"ande leicht abgesch"atzt werden.
\end{itemize}

%\subsection{Usability des Komponentenmodells}
%\begin{itemize}
%	\item EJB: todo
%	\item CCM: todo
%	\item .NET: todo
%\end{itemize}

%\subsection{Transaktionsunterst"utzung}
%\begin{itemize}
%	\item EJB: todo
%	\item CCM: todo
%	\item .NET: todo
%\end{itemize}

\pagebreak
\section{Fazit}
Die derzeit wichtigsten Komponententechnologien EJB, CCM und .NET wurden
ebenso dargestellt, wie das noch relativ neue Konzept der service-orientierten Architekturen. Die Untersuchungen dieser Technologien auf ihre Eignung im SOA-Kontext bezogen Eigenschaften ein, die den SOA-Charakteris\-tik\-en entsprechen, flexible Reaktionen auf neue Entwicklungen beg"unstigen, sowie generell w"unschenswert sind.
Es wurde nachgewiesen, dass EJB vor allem aufgrund der gr"o"seren Offenheit f"ur SOA-Systeme am besten
geeignet ist, w"ahrend das propriet"are\glossary{name={proprietär}, description={nicht allgemein anerkannten Standards entsprechend}} .NET sehr auf Webservices\glossary{name={Webservice}, description={Softwareanwendung, die mittels einem Uniform Resource Identifier identifiziert wird und
deren Schnittstellen über XML-Artefakte beschrieben werden}} abzielt, die nur eine Spezialisierung von SOA sind.

Gartner sah bereits 2003 f"ur das Jahr 2008 voraus, dass 60\% der Unternehmen SOA als
leitendes Prinzip einsetzen werden, wenn sie gesch"aftskritischen Anwendungen, bzw.
Prozesse erstellen \cite{Gartner2003}. Einerseits wird im aktuellen Gartner-Bericht "`Hype Cycle for
Application Development 2007"' sowohl f"ur SOA als auch f"ur die Microsoft .NET-Plattform
eine Dauer von noch zwei bis f"unf Jahren gesch"atzt, bis diese Konzepte von der breiten
Ma"se akzeptiert sind \cite{Gartner2007}. Andererseits sieht Gartner f"ur die J2EE-Plattform eine Dauer
von deutlich unter 2 Jahren voraus. Somit ist EJB bereits wegen der
allgemein gr"o"seren Akzeptanz die derzeit am besten geeignete Technologie f"ur
SOA-Anwendungen.

\pagebreak

\printglossary

\pagebreak

\begin{thebibliography}{20000000}

\bibitem {Andresen2004} Andreas Andresen, \textsl{Komponentenbasierte Software-Entwicklung mit MDA, UML 2 und XML}, 2004, Carl Hanser Verlag M"unchen Wien

\bibitem {Becking2007} Rolf Becking \textsl{Wohnmodil statt Lego-Haus}, 2007, e-commerce Magazin Special: Integration, serviceorientierte Architektur f"ur Legacy-Applikationen, http://www.e-commerce-magazin.de/index.php3?page=05-04/special.html, Abruf: 20.10.2007

\bibitem {Gartner2003} Gartner Research \textsl{Introduction to Service-Oriented Architecture}, 14.04.2003, Gartner Inc. and/or its Affiliates

\bibitem {Gartner2007} Gartner Research \textsl{Hype Cycle for Application Development 2007}, 29.06.2007, Gartner Inc. and/or its Affiliates

\bibitem {Koll2007} Sabine Koll \textsl{Softwarepreis wird individuell}, 10.09.2007 Computer Zeitung Nr. 37, Konradin IT-Verlag GmbH

\bibitem {Mono2007} Mono Project \textsl{The Mono Project}, 2007, Mono Project, http://www.mono-project.com/Main\_Page, Abruf: 31.12.2007

\bibitem {Oasis2006} OASIS Consortium \textsl{Reference Model for Service Oriented Architecture 1.0}, 2006, OASIS Con\-sor\-ti\-um, http://www.oasis-open.org/committees/tc\_home.php?wg\_abbrev=soa-rm, Abruf: 30.12.2007

\bibitem {Papazoglou2007} Mike P. Papazoglou, Willem-Jan van den Heuvel \textsl{Service oriented architectures: approaches, technologies and research issues}, 2007, Springer Verlag, Berlin Heidelberg

\bibitem {Qian2005} Andy Ju An Wang, Kai Quian \textsl{Component-Oriented Programming}, 2005, John Wiley and Sons, Inc. Hoboken, New Jersey

\bibitem {Samaschke2006} Karsten Samaschke \textsl{XML.NET - XML und Web Services mit dem .NET Framework}, 2006, entwickler.press

%\bibitem {Taylor2006} Eric Pulier, Hugh Taylor \textsl{Understanding Enterprise SOA}, 2006, Manning Publications Co.

\end{thebibliography}


%Optional: Anhang
%\pagebreak
%\appendix{Anhang}

\end{document}


