Preview:

*) Überschrift: Kriterien zum Vergleich der Komponenten

- Art des Standards

- Plattform-Unabhängigkeit

- Programmiersprache

- Skalierbarkeit

- Sicherheit

- Entwicklung

- Verteilung

- Transaktionen

*) Vergleich von Enterprise Java Beans (EJB), Component Object Model (COM+),

CORBA Component Model (CCM) und .NET

Question:

A) Welche Komponententechnologien bieten welche besonderen Vorteile?

B) Welche Komponententechnologien weisen welche gravierende Nachteile auf?

C) Welche Standards gibt es?

Read:

A)

- Microsoft-Betriebssysteme besitzen einen hohen Einsatzgrad in der Industrie. Daher haben COM+

und .NET aufgrund ihrer Proprietät die Eigenschaft, sich (bzw. ihre Änderungen) schneller am Markt durchzusetzen als

die offenen Standards, deren Änderungen erst formal und theoretisch ausgefeilter von vielen

beschlossen werden muss.

- EJB und CCM sind prinzipiell plattformunabhängig.

- .NET ist vor allem auf Webservices (also Serviceorientierung der Anwendung) ausgelegt, insofern

besonders offen für Internetanwendungen.

- die deklarativen Attribute von EJB-Komponenten können auch nach der Verteilung noch

spezifiziert / geändert werden.

- EJB, CCM und .NET bieten weitgehendes Transaktionsmanagement an.

B)

- Einsatz von COM+ und .NET-Komponenten ist auf Microsoft-Betriebssysteme beschränkt.

- geringe Unterstützung für Transaktionsmanagement bei COM+

C)

- Sprachunabhängigkeit

- Skalierbarkeit, v. a. was DB-Anbindungen und Instanzenverwaltung betrifft

- Tools zur Generierung, bzw. schnellem Gerüstentwurf; dadurch Konzentration auf Business-Logik

- Beim Deployment wird die Konfiguration der Komponente spezifiziert.

Reflect:

*) Interessant ist der Vergleich von .NET als SOA-Technologie im Vergleich mit den klassischen

Komponententechnologien.

Recite:

*) Art des Standards: offen / proprietär?

- Offene Standards: EJB, CCM

- Proprietär: COM+, .NET

*) Plattformunabhängigkeit: Einsetzbarkeit auf verschiedenen Betriebssystemen?

- plattformunabhängig: EJB, CCM;

- plattformabhängig: COM+, .NET; wobei .NET-Services von verschiedenen Plattformen aus genutzt werden kann.

*) Programmiersprache: sprachunabhängig? Binärstandard?

- EJB: Binärstandard Byte-Code; relativ sprachunabhängig durch JNI

- CCM: kein Binärstandard benötigt, sprachunabhängig

- COM+: sprachunabhängig (VB 6 / 7, C++, C#), Binärstandard vorhanden

- .NET: sprachunabhängig (C#, Managed C++, VB.NET)

*) Skalierbarkeit: Systemskalierung / inhärente Begrenzungen? Einsatz in Intranet-/Internet-/Extranet-Umfeld?

Verhalten bei steigender Anzahl Komponenten, Komponenten-Instanzen, Server?

- EJB: hochgradig skalierbar durch Poolingmechanismen, v. a. für DB-Verbindungen; Caching für EJB-Instanzen

- CCM: Skalierbarkeit innerhalb des Komponentensystems einstellbar

- COM+: JIT-Instanziierung, ASAP-Zerstörung von Instanzen; Poolingmechanismen für DB-Verbindungen und

Laden von umfangreichen nicht-transaktionsrelevanter Daten zwischen mehreren Komponenteninstanzen

- .NET: Skalierbarkeit orientiert sich v. a. am verwendeten Backend-Server (SQL-Server, BizTalk-Server);

Skalierbar auch für Webservices; Statusinformationen werden über Serverfarmen hinweg verteilt

*) Sicherheit: unterstützte Maßnahmen? Zugriffsrechteverwaltung?

- EJB, CCM: rollenbasiert; Zugriffrechte auf Methodenebene; Sicherheitsmechanismen des Betriebssystem werden

genutzt

- COM+, .NET: mehrere Authentisierungsebenen: Authentifizierung, Autorisierung, Personifizierung

*) Entwicklung: einfache Nutzung des Modells? Nutzung vorhandener Frameworks/Bibliotheken? Unterstützung

vertikaler / horizontaler Dienste?

- EJB, CCM, COM+: Tools zur weitgehenden Generierung sind vorhanden; Konfigurationsaufwand moderat; Programmierer

kann sich auf Business-Logik konzentrieren

- .NET: Nutzung des .NET-Frameworks, -Services, dadurch Trennung von Layout und Code; schnelle, einfache

Entwicklung möglich

*) Verteilung: einfach? Laufzeit-Anbindung möglich?

- EJB: JAR-Datei ist für spezifische EJB-Komponentenmodellimplementierung vorgesehen; Komponentenmodell-

implementierungen unterschiedlicher Hersteller sind eingeschränkt portabel untereinander, wobei Kommunikation

über RMI / IIOP stets möglich ist.

- CCM: ähnlich wie EJB

- COM+: Verteilung über Windows Installer Package

- .NET: Verteilung über .asmx Datei im virtuellen Pfad einer ASP.NET-Anwendung

*) Transaktionen: Transaktionsmanagement? Steuerung von Transaktionen?

- EJB: Transaktionsmanagement kann generiert werden; Persistence Manager nimmt dem Entwickler die Komplexität

ab.

- CCM: "Object Transaction Service" setzt flache und verschachtelte Transaktionen um; Zustände werden mit 5

unterschiedlichen Containern auf Erfordernisse spezifiziert.

- COM+: DB-/Ressourcenlocks; Transaktionen zustandslos; JIT / ASAP-Lifecycle ermöglicht bessere Skalierbarkeit

- .NET: Unterstützung für Transaktionsmanagement wird per Klassenattribut festgelegt und nutzt COM+-Services.

Review:

Der technische Vergleich der betrachteten Standards EJB, COM+, CCM, .NET ergibt keinen eindeutig dominanten

Standard bezüglich allgemeiner Vorteile. Vielmehr existieren Standardaspekte, die alle Technologien in vergleich-

barem Maß anbieten.

*) Tabelle Vergleich "Herkömmliche Komponentenbasierte Technologie" vs. "SOA-Architektur"

Question:

A) Inwiefern löst SOA die herkömmlichen Komponententechnologien ab?

B) Welches sind die neuen Aspekte, die den Trend zu SOA begründen?

C) Welche Nachteile hat SOA gegenüber den etablierten Komponententechnologien?

Read:

A)

- Hingegen bildet SOA sich schnell verändernde Geschäftsprozesse ab.

- Die Arbeit an den Interfaces gestaltet die Arbeit mit etablierten Komponententechnologien so

aufwändig, dass Vorteile und Vereinfachungen wieder aufgewogen werden.

- SOA-Services sind prozessorientiert, während Komponenten funktionsorientiert sind.

- Herkömmliche Technologien zielen auf Beständigkeit der Komponenten ab.

- SOA zielt auf Flexibilität der Anwendung ab.

B)

- SOA bedient vor allem das Web-Economy-Umfeld.

- SOA-Services sind protokoll- und ortsunabhängig; haben keine präzise Peräsentationslogik;

haben ein definiertes Interface; sind lose gekoppelt

- SOA bietet einfache Nutzung von Legacy-Applikationen wegen Plattformunabhängigkeit, Beispiel:

COBOL-Applikationen auf Großrechnerarchitekturen

C)

- kein echter Nachteil, aber auch keine Erleichterung ggüber. Komponententechnologien: Legacy-

Applikationen müssen SOA-tauglich gemacht werden.

Reflect:

*) Gegenargument: das Web-Economy-Umfeld wird derzeit stark ausgebaut, aber die meisten

heute gängigen Betriebssysteme wurden nicht für prozess-, sondern anwenderorientierte

Applikationen designt; insofern ist der Einsatzbereich von SOA noch eingeschränkt

*) Die etablierten Komponententechnologien gehen v. a. auch auf Aspekte wie z. B. Sicherheit und

Wiederverwendung ein. Dieser Text äußert sich nicht, wie dies bei SOA behandelt wird.

Recite:

*) Die Geschwindigkeit, mit der sich vor allem Anwendungs-Software für Geschäftsprozesse

verändert, hat von der OOP zu Komponentenbasierter Software geführt.

*) Komponententechnologie ist aber für Anwendungen entworfen, die sich eher wenig verändern.

*) Vor allem die sehr flexiblen Webservices können durch SOA wesentlich besser erstellt werden.

Review:

Der Text weist auf einige Aspekte hin, wegen denen SOA im Web-Economy-Umfeld besser geeignet

ist als die etablierten Komponententechnologien.

*) Überschrift: Geschäfts- oder Transaktionszahlen kommen ins Spiel

*) Zwischenüberschrift: Die finanziellen Konsequenzen will niemand in Gänze tragen

Question:

A) Wie reagieren die SW-Anwender auf die Aufgliederung der Preise?

B) Wie schwierig gestaltet sich die Umstellung von bestehender monolithischer SW auf modulare,

komponentenbasierte SW?

C) Wie einfach lassen sich Preise für die einzelnen Komponenten festlegen?

Read:

A)

- Experte Dean Petracca von Pricewaterhousecoopers (PWC) sagt vorher, dass in Zukunft der

Anwender die Preise bestimmen wird.

B)

- Analystin Alexa Bona von der Gartner Group erwartet für die Anwender Preisaufschläge zwischen

30 bis 50%

- Die Aufspaltung der SW in Komponenten macht nur bis zu einem gewissen Grad Sinn - v. a.

Mikroprozesse sind nicht abrechenbar.

C)

- Preismodelle werden noch entwickelt; der Preis soll sich am Nutzen für den Kunden orientieren

- Die Kunden akzeptieren dieses Modell nur, solange sie keine zu hohen Beträge an die

SW-Entwickler abtreten müssen.

- Eine direkte Zuordnung zwischen Geschäftsperformance und Software ist schwer nachvollziehbar.

- Kosten von Mikroprozesse lassen sich nicht wirklich definieren.

Reflect:

*) Mietsoftware hat sich bislang auch nicht durchgesetzt.

*) Wie werden die SW-Entwickler Kundenbindung umsetzen? Z. B. in Hinblick auf Mix von SW-Komponenten

eines Entwicklers und seiner Konkurrenz. Wahrscheinlich werden die Hersteller dies im Pricing berücksichtigen.

*) Welche Gründe sollte es geben, dass jemand sein Monopol durch zu weitgehende Modularisierung und zu

offenes SOA-Design schwächt? Es ist wohl eher konservatives Vorgehen zu erwarten in solchen Szenarien.

Recite:

- Die Marktanalysten Gartner und PWC sind sich nicht einig, wie sich die Umstellung des

Preismodells auswirken wird.

- Beispiel SAP - Kundenbeziehungsmanagement und Produkt-Lifecycle-Management: Kunde aus

der petrochemischen Industrie zahlt für jedes umgesetzte Fass Benzin einen gewissen Betrag

- Beispiel Plexus - ERP-SW: Kunde zahlt nach Produkten, die über Versandsystem verkauft werden.

Sobald die Margen steigen, lehnen die Kunden das Preismodell ab.

- Eine direkte Zuordnung zwischen Geschäftsperformance und Software ist schwer nachvollziehbar.

- Tools für Asset Management unterstützen noch keine Prozesse auf Webservice-Ebene

- Für Mikroprozesse, Beispiel Anlegen einer Kundendatei, wird es keine Anbieter geben, so dass

wieder grobkörnige Prozesspakete kursieren werden, wobei der Kunde für Abläufe zahlt, die er nicht

nutzt.

- PWC: individuelle transparente Preise werden verhandelbar, statt dass es einheitliche Software-

lizenzen gibt.

- PWC: Inhouse-Entwicklungen werden wegen SOA preislich konkurrenzfähig zu externen SW-

Anbietern.

Review:

Die Aufspaltung von Anwendungen in Komponenten und Services ermöglicht neue Pricing-Modelle.

Allerdings muss sich noch zeigen, wie die Anwender diese neuen Modelle akzeptieren, bzw. ob es

für den Kunden mehr Marktmacht bedeutet.