\documentclass{article}[11pt,a4paper]

\usepackage{graphicx}
\usepackage{ngerman}

%Optional: Kurzfassung auf Titelseite
%\begin{abstract}
%Hier kann eine Kurzfassung der Ausarbeitung stehen.
%\end{abstract}

%Optional: Abkürzungsverzeichnis vgl.
%http://www.uni-giessen.de/hrz/tex/cookbook/ninth.html

\begin{document}
\title{Vergleich wichtiger Komponententechnologien bez"uglich ihrer Eignung in SOA}
\author{Harry Trautmann\\
Hochschule f"ur Technik, Stuttgart}
\date{\today}
\maketitle
\thispagestyle{empty}
\pagebreak
\tableofcontents
\pagenumbering{Roman}

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

\pagebreak
\section{Einleitung}
\pagenumbering{arabic}
In den vergangenen Jahrzehnten stieg sowohl Rechenleistung, als auch
Speicherkapazit"at von Computersystemen. Ebenso wuchs mit der Nachfrage nach
geeigneter Informationstechnologie die Abh"angigkeit der Gesellschaft davon. Um dieser Nachfrage
gerecht zu werden, mussten Systemarchitekten immer gr"ober granulierte Automatisierungs- und
Kapselungstechnologien einf"uhren. G"abe es derartige Standards heute nicht, k"onnten beispielsweise
moderne Betriebssysteme wie Windows XP nicht ann"ahernd in der heute vorliegenden Qualit"at realisiert
werden. Daher ist leicht einsichtig, dass Modularisierung eher zum
Erfolg f"uhrt, wenn einigerma"sen große Computersysteme erstellt werden m"ussen.
Diese Modularisierung begann auf prozeduraler Ebene (Funktionen und
Funktionsbibliotheken) und f"uhrte in Form der Objektorientierung zu modularisierten
Daten, um schlie"slich das Paradigma von semantisch in Komponenten gekapselter
Software zu begr"unden. Heute existieren mehrere Standards f"ur so genannte
Komponententechnologien nebenher.

Moderne Bestrebungen, welche darauf abzielen, Gesch"aftsabl"aufe und die dabei
ben"otigten Daten wiederverwendbar und zueinander kompatibel zu machen, f"uhren die
Modularisierung auf einer abstrakteren Stufe sogar noch weiter. Diese Service-orientierten
Architekturen (SOA) stellen momentan die gr"obste Granularität an Modularisierung dar.
Analog zu den Komponententechnologien, die in den 90er Jahren ausreiften, befindet sich
die SOA-Technologie derzeit in einer Konsolidierungsphase. Abseits der Webservices,
welche derzeit die bekannteste SOA-Anwendung darstellt, stehen Umsetzungen noch weitgehend aus.

Im Folgenden soll die Verbindung zwischen den wichtigsten der nunmehr etablierten
Komponententechnologien und der noch neuen SOA-Technologie untersucht werden.
Aufgeworfene Fragestellungen beziehen sich vor allem darauf, inwieweit die einer
Architektur jeweils unterliegende Komponententechnologie die Charakteristika von SOA
von sich aus unterstützt und wie flexibel die Technologie auf Entwicklungen in der noch
jungen SOA-Historie reagieren kann. Insbesondere soll die Enterprise Java Beans
Technologie betrachtet werden, um nachzuweisen, dass sie aktuell am geeignetsten ist,
um mit ihr SOA-Systeme zu realisieren.

\section{Umfeld}
\subsection{Komponententechnologien}
Eine Komponententechnologie spezifiziert nach [Andresen2004, 261] die Syntax und Semantik der Komponenten und stellt eine Laufzeitumgebung bereit, die "uber gewisse Basisdienstleistungen (z. B. Erzeugung, Aktivierung, Deaktivierung von Komponenten), sowie erweiterte Dienste, wie Persistenzmanagement, Transaktionsverhalten, Sicherheit, Verzeichnisdienste, verf"ugt. Die Technologie kann auf spezifischen Applikations-Server und -Container, als auch auf spezifischer Middleware basieren.

	In den letzten 10 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.

\subsubsection{CORBA Component Model}
CORBA ist ein plattform- und sprachunabh"angiger Middleware-Standard und wurde von der
Object Management Group (OMG) erschaffen, 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. [Andresen2004, 270]

	Grundlegend f"ur CORBA ist der ORB (Object Request Broker). Dies ist eine Schicht, welche die
notwendigen Basis-Services abstrahiert. Der ORB stellt den Komponenten und Komponenten-
Containern Transaktions-, Sicherheits-, Benachrichtigungs- und Persistierungsdienste zur 
Verf"ugung. [Andresen2004, 274]
\linebreak
	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 der Komponente und Anfragen der Komponente an externe Komponenten-APIs ausf"uhrt.
	Dabei verwaltet der POA (Portable Object Adapter) die Referenzen auf externe (evtl. entfernte) 
Instanzen von CORBA-Komponenten. Das "`Component Home"'-Interface ist ein vom ORB verwaltetes
Objekt, welches dazu dient, die Instanziierungen und 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. [Qian2005, 146]
%\setlength{\hoffset}{-30}
\begin{figure}	\includegraphics[width=1.00\textwidth,keepaspectratio]{C:/data/studium/HfT/Wissensschrei/_work/model_CORBA.png}
	\caption{Einbettung von Komponenten in einer CCM-Architektur [Andresen2004, 275]}
	\label{fig:model_CORBA}
\end{figure}
%\setlength{\hoffset}{0}
CCM-Komponenten stellen sich nach aussen "uber 4 Arten von Schnittstellen dar.
\begin{enumerate}
	\item Facets: sie sind die komponentenexterne Schnittstelle f"ur die Business Logic der Komponente.
	\item Receptables: sie sind nach aussen 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 komponentenextern erzeugten Ereignissen.
\end{enumerate}

\subsubsection{.NET}
Das .NET Framework wurde von der Microsoft Corporation entwickelt und 2000 ver"offentlicht. Es dient der schnellen
Erstellung und Bereitstellung von Softwarekomponenten. Momentan gibt es nur f"ur die Microsoft Windows Betriebssysteme
Implementierungen des .NET Frameworks.

	Die Basis des Frameworks bildet der CLR-Dienst (Common Language Runtime). Es ist eine virtuelle Maschine, die 
sogenannte Assemblies ausf"uhren kann. Dies wiederum sind vorkompilierte, in dem Bytecode-Format MSIL (Microsoft
Intermediate Language) vorliegende Bin"arprogramme.

	Ausserdem enth"alt das .NET Framework eine Klassenbibliothek mit grundlegenden Klassen, sowie grundlegende Dienste zur
Ver"offentlichung von Funktionalit"at "uber das Web (ADO.NET) oder als Windows Desktop Applikation (Windows Forms).^

	.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 [Qian2005, 200]:
\begin{enumerate}
	\item einem Manifest (enth"alt u. a. Versionsnummer, einen eindeutigen Namen und Definitionen der verwendeten Typen),
	\item Metadaten 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 sogenannten "`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, Threadabl"aufen 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]{C:/data/studium/HfT/Wissensschrei/_work/model_dotNETFramework.png}
	\caption{Aufbau des .NET Frameworks [Qian2005, 196]}
	\label{fig:model_dotNETFramework}
\end{figure}

\subsubsection{Enterprise Java Beans}
Die EJB-Komponententechnologie ist eng an die J2EE-Plattform gebunden. 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 
Lifecycle Management an. Somit k"onnen bei EJB-Implementierungen diese Aspekte ausser Acht gelassen
werden, so dass sich der Code voll auf die Umsetzung der Geschäftslogik konzentriert. Eine J2EE-Architektur
wird im Allgemeinen in die folgenden semantischen Bereiche (die sogenannten Tiers) aufgegliedert.
\begin{enumerate}
	\item Client-Tier: diese Ebene enth"alt die Funktionalit"at zur Interaktion des Benutzers mit dem System. Dabei kann der Benutzer beispielsweise ein Browser oder eine Java Applikation sein.
	\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 Business-Tier. EJBs geh"oren in diesen Tier.
	\item EIS-Tier: dieser Tier dient der Anbindung des J2EE-Systems an "`Enterprise Information Systeme"'. Das k"onnen beispielsweise externe Datenbanksysteme oder Host-Anwendungen sein.
\end{enumerate}
	EJBs k"onnen erst zusammen mit einer Laufzeitumgebung genutzt werden. Der EJB-Server stellt eine
solche zur Verf"ugung. Der EJB-Server bietet den EJBs grundlegende Dienste wie Prozess- und Thread-Verwaltung an,
aber auch komplexe, wie beispielsweise einen Dienst f"ur das Pooling der von mehreren EJBs gemeinsam
genutzten Netzwerk- und Datenbankenressourcen.

	Auch EJBs werden innerhalb Containern ausgef"uhrt. Sie abstrahieren die EJB-Schnittstellen nach aussen, so
dass externe Zugriffe auf die EJB-Schnittstelle vom Container kontrolliert werden. Ausserdem bietet der
Container einer EJB-Komponente die Implementierung allgemeiner Funktionalit"aten wie Sicherheits-,
Konstruktions- und Destruktionsmechanismen 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.
[Qian2005, 269]

\begin{figure}[htb]
		\includegraphics[width=1.00\textwidth,keepaspectratio]{C:/data/studium/HfT/Wissensschrei/_work/model_EJB.png}
	\caption{Einbettung von Komponenten in eine EJB-Architektur [Andresen2004, 269]}
	\label{fig:model_EJB}
\end{figure}

\subsection{Service-oriented Architecture}
Mit der Etablierung verteilter Computersysteme ergaben sich zwei Hauptprobleme: Heterogene Standards (Propriet"at) und enge Kopplung existierender Systemmodule aneinander. Dies erzeugte die Problematik inkompatibler und schwer zu wartender Systeme. Moderne Anforderungen, wie z. B. global ben"otigte Verf"ugbarkeit von Programmfunktionalit"at und notwendige Kosteneinsparung bei der Systemwartung, f"uhrten dazu, vor allem die vorhandenen Systemdienste mit einer offenen Schnittstellenschicht auszustatten, um ihre Funktionalit"at in anderen Systemmodulen wiederverwenden zu k"onnen. Dies f"uhrte zu Architekturen, deren Aufbau sich an den zur Verf"ugung stehenden Diensten ausrichtet.

\subsubsection{Definition}
Derzeit existiert noch keine einheitliche Definition des Begriffs "`Service-orientierte Architektur"'. Entlang [Gartner2007, 32] 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{Charakteristika}
Um die Eignung einer Komponententechnologie f"ur denm Einsatz in SOA beurteilen zu k"onnen, muss zuvor eine Charakterisierung der Eigenschaften von SOA vorgenommen werden. Dann k"onnen die Eigenschaften der jeweiligen Technologie dagegen verglichen
werden. 
\begin{itemize}
	\item Fokus auf Gesch"aftsprozesse: jede durch eine SOA bereitgestellte Schnittstelle repr"asentiert einen Gesch"aftsprozess in Form einer Black Box. Komponententechnologien, welche eine Trennung von Layout und Gesch"aftslogik beg"unstigen, sind daher von Vorteil.
	\item Lose Kopplung von Diensten: Dienste sind lose gekoppelt, wenn ihre Kommunikation auf nicht-propriet"aren offenen Standards basiert. "Anderungen in der Zusammenstellung der Dienste wirken sich dann weniger gravierend auf die Architektur aus. Diese standardisierte Interoperabilit"at [Taylor2006, 52] erm"oglicht die sogenannte Service-Orchestrierung - die Erstellung eines neuen Dienstes, der ausschlie"slich bestehende Dienste verwendet. Somit ist eine Komponententechnologie besser f"ur SOA geeignet, je mehr sie die Verwendung von offenen Standards f"ordert.
	\item Gleichzeitige Bedienung vieler Konsumenten: SOA werden vornehmlich im Umfeld der Web Economy eingesetzt, in dem es f"ur ein System eine grundlegend zu erf"ullende Anforderung ist, viele gleichzeitig gestellte Konsumentenanfragen zu befriedigen [Becking2007]. Daher ist eine Komponententechnologie besser f"ur SOA geeignet, wenn sie "uber gute Skalierungseigenschaften verf"ugt.
\end{itemize}

\subsubsection{Webservices als SOA-Killerapplikation}
Web Services sind eine Spezialisierung von SOA. [Samaschke2006] beschreibt einen Web Service als eine "uber eine URI (Uniform Resource Locator) adressierbare Software-Komponente, deren Schnittstelle mittels den standardisierten Web-Protokollen HTTP, HTTPS, SMTP und/oder FTP angesprochen werden kann. F"ur den Austausch von Daten wird XML in Form von WSDL und SOAP verwendet. Ein UDDI-Komponentenverzeichnis (Universal Description, Discovery and Integration) ist optional.

Das .NET Framework bietet Entwicklern viele Hilfen an f"ur die Entwicklung von Web Services, beispielsweise indem es mit ASP.NET entsprechende f"ur die Verwendung in Web Services vorgefertigte Klassen bereit stellt (siehe Abbildung 2).

Dennoch sollten Dienste anderen Applikationen allerdings nicht nur mittels WSDL (Web Service Definiton Language) als Webservice-Schnittstelle zur Verf"ugung stehen, sondern auch m"oglichst breit andere Standardschnittstellen abdecken, wie z. B. JCA (J2EE Connector Architecture), XML, EDI (Electronic Data Interchange) und SOAP (Simple Object Access Protocol), sowie Kombinationen davon. Sonst besteht die Gefahr, dass die erstellte Architektur nur einseitig nutzbar ist, statt von beliebigen Konsumenten genutzt werden zu k"onnen.

\section{Entsprechung gegen"uber SOA-Charakteristiken}

\subsection{Trennung zwischen Gesch"aftsprozess und dessen Pr"asentation}
Um eine SOA wiederverwendbar zu halten, muss eine m"oglichst weitgehende Trennung zwischen der Gesch"aftslogik und deren Pr"asentation seitens der Technologie unterst"utzt werden.
\begin{itemize}
	\item Die J2EE-Plattform trennt mittels unterschiedlicher Container-Klassen zwischen den EJB, welche f"ur die Implementierung der Gesch"aftslogik gedacht sind, und dem Layout, das durch JSPs oder Servlets realisiert werden kann.
	\item CCM schreibt keine derartige Trennung vor.
	\item .NET schreibt keine Trennung vor, unterst"utzt dies aber mit der Bereitstellung der ASP.NET-Klassenbibliothek.
\end{itemize}

\subsection{Skalierbarkeit}
Von besonderer Bedeutung ist es f"ur eine SOA, dass sie eine gro"se Anzahl von Konsumentenanfragen bedienen kann. Um die Systemressourcen zu schonen, ist es wichtig, dass eine Komponententechnologie, aus der sich die SOA zusammensetzt, m"oglichst gut skaliert.
\begin{itemize}
	\item EJB-Server verf"ugen "uber Mechanismen f"ur des Pooling von Datenbankverbindungen und EJB-Instanzen, sowie Caching derselben. Somit ist die EJB-Technologie hochgradig skalierbar. [Andresen2004, 288]
	\item Skalierung kann in CCM durch Verwendung unterschiedlicher Container erreicht werden [Andresen2004, 289]. Dies verlangt also, dass bereits zur Compile-Zeit 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 verf"ugt CCM prinzipiell "uber Skalierungseigenschaften, die aber nicht flexibel verwendbar sind, wenn sich die Systemarchitektur "andert.
	\item Innerhalb des .NET Framework sorgen die ASP.NET- und ADO.NET-Module f"ur Caching von Datenbankverbindungen und Statusinformationen der Instanzen. Wie gut eine .NET Architektur skaliert, h"angt aber vor allem auch von der Konfiguration der dahinterliegenden Back-End-Server ab [Andresen289].
\end{itemize}

\subsection{Verteilung}
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 einfache Neukonfiguration einer Komponente unterst"utzt.
\begin{itemize}
	\item EJBs werden in JAR-Dateien verpackt, die auch einen sogenannten 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 [Andresen2004, 291]. Dies stellt innerhalb SOA einen Vorteil dar.
	\item Wenn eine neu CCM-Komponente bereitgestellt werden muss, reicht es, deren in IDL (Interface Definition Language) spezifizierte Schnittstellen um die neuen Schnittstellen zu erweitern und die neu kompilierte Komponente in das System einzubauen [Andresen2004, 233]. Somit kann auch ein System, das auf CCM-Komponenten aufbaut, einfach umkonfiguriert werden.
	\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. [Qian2005, 195]
\end{itemize}

\section{Offenheit gegen"uber zuk"unftigen Entwicklungen}
Die folgenden Kriterien sind f"ur die Eignung der jeweiligen Komponententechnologien hinsichtlich SOA nicht entscheidend. Sie stellen aber generell w"unschenswerte Eigenschaften dar, denn einmal vorliegende Architekturen tendieren dazu, erweitert zu werden, sowie die Anforderungen und das Umfeld dazu tendieren, sich in unerwarteter Weise zu "andern.

\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 EJBs sind durch Verwendung von Java als unterliegende Sprache prinzipiell plattformunabh"angig, da die Implementierung einer JVM 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 derzeit nur auf den Microsoft Windows Betriebssystemen implementiert. Somit sind .NET Komponenten plattformabh"angig.
\end{itemize}

\subsection{Sprachunabh"angigkeit}
\begin{itemize}
	\item EJBs 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}
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 zweitnah 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 gro"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 .NET-Komponenten sind mitsamt dem .NET Framework an Microsoft Betriebssysteme gebunden. Allerdings pflegt Microsoft den Standard sorgf"altig, beispielsweise, indem es mit Updates auf Sicherheitsl"ucken in der Framework-Implementierung reagiert.
\end{itemize}

\subsection{Eignung f"ur SOA-Middleware}
Momentan gibt es noch keine vorliegende SOA-Middleware, lediglich einige Ank"undigungen. Beispielsweise hat Sun CAPS (Composite Application Platform Suite) angek"undigt, eine integrierte Software Suite f"ur SOA-Applikationen. Aufgrund der gegebenen Affinit"at von Sun Microsystems zur Java-Programmiersprache ist insbesondere die EJB-Technologie f"ur einen Einsatz in CAPS pr"adestiniert [Sun2007].

	Weiterhin arbeitet die Firma iWay mit mehreren gro"sen Unternehmen, wie z. B. BEA, Microsoft und Sun, zusammen um einen SOA Middleware Standard zu realisieren, der "uber eine m"oglichst breit gef"acherte Unterst"utzung von Technologien verf"ugt, darunter auch das .NET Framework [iWay2007].

\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 Sicherheitsmechanismus 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 [Andresen2004, 289].
	\item CCM verf"ugt "uber ein "ahnliches Rollen-System wie die EJB-Technologie basierend auf CORBA.
	\item Beim .NET Framework wird zwischen Authentifizierung, Autorisierung 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 eines Systems erh"oht werden. Man soll nachvollziehen k"onnen, welche Teile des Systems wieviel der vorhandenen Ressourcen in Anspruch nehmen. Insbesondere ist dies dann wichtig, wenn extern ver"offentlichte Dienste Kunden berechnet werden sollen [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 tiefgreifende Kostentransparenz m"oglich, aber unter Umst"anden auch kompliziert zu implementieren ist.
	\item Die Verwendung der .NET Klassenbibliotheken ASP.NET und ADO.NET machen einen "Ubersicht "uber die tats"achlichen Aufw"ande schwierig.
\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 die das noch junge Konzept der service-orientierten Architekturen. Die Untersuchungen dieser Technologien auf ihre Eignung im SOA-Kontext bezogen vor allem Eigenschaften ein, die den SOA-Charakteristika entsprechen, flexible Reaktionen auf neue Entwicklungen beg"unstigen, sowie generell w"unschenswert sind.
Es wurde nachgewiesen, dass EJB sich vor allem aufgrund der gr"o"seren Offenheit als
geeignetster Standard zur Realisierung von SOA-Systemen darstellt, w"ahrend das
Microsoft-propriet"are .NET sehr auf Webservices abzielt, die ja 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 [Gartner2003]. Im aktuellen Gartner-Bericht "`Hype Cycle for Application
Development 2007"' wird f"ur sowohl für SOA als auch f"ur die Microsoft .NET-Plattform
eine Dauer von noch 2 bis 5 Jahren gesch"atzt, bis sich diese Konzepte von der breiten
Masse akzeptiert ist [Gartner2007]. Andererseits sieht Gartner f"ur die J2EE Plattform daf"ur eine Dauer
von unter deutlich 2 Jahren voraus. Wie es aussieht, ist EJB somit auch schon wegen der
allgemein gr"o"seren Akzeptanz die geeignetere Technologie f"ur SOA-Anwendungen.

\pagebreak

\begin{thebibliography}{20000000}

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

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

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

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

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

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

\bibitem[iWay2007] {KinSOA} iWay Software \textsl{iWay Software - business integration, EAI, middleware and infrastructure solutions}, 2007, iWay Software, http://www.iwaysoftware.com/, Abruf: 19.10.2007

\bibitem[Sun2007] {KinSOA} Sun Microsystems \textsl{Sun Java Composite Application Platform Suite at a Glance}, 2007, Sun Microsystems, http://developers.sun.com/javacaps/index.jsp, Abruf: 19.10.2007

\bibitem[Becking2007] {KinSOA} 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[Samaschke2006] {KinSOA} Karsten Samaschke \textsl{XML.NET - XML und Web Services mit dem .NET Framework}, 2006, entwickler.press

\end{thebibliography}

%Optional: Anhang
%\appendixname

\end{document}


