SOA-Patterns

Ich suche Patterns für SOA. Was ich nicht suche ist: "SOA mit MS Web Services" oder sowas. Ich muss eine komplett eigene SOA aufsetzen und implementieren.

Ich hab zuhauf Dokumente, die Anforderungen an SOA stellen, aber ich brauche eher generische Muster-Architekturen.

SOA ist einfach ein MS-Buzzword. Neu ist SOA nicht, seit ca. 95 wird versucht sowas zu Vermarkten(ungefähr da fing's an mit Schichtenarchitektur und verteilten Anwendungen(also SOA). Ten years ago, wird dann angefangen sowas als Technologie zu vermarkten(blöd ist nur das Standards immer noch nicht existieren).
Ein Pattern wäre "Asynchrone Transaktion", was nicht heisst das du das brauchst.
Kommunikationsstandards gibts auch kaum(jedenfalls nicht im Sinne jede App kann mit jeder). Der Webservicehype ist auch lustig(fehlende Standards).
Echtes SOA gibts nicht. Innerhalb einer Lösung(gleiche Firma) kann sowas gemacht werden(Firmenstandard).
Zum Beispiel wurde bei Reuters ein Servicebus festgelegt, und es funktioniert gut. Offengelegt wurde der Standard(nicht wirklich nur Technologie) auch(Gazette: ObjectSpectrum). Es bleiben bis heute nur nicht anerkannte Lösungen. Treffsichere Patterns kanns also nicht geben. Für das Allgemeine kann man die sogenannten Enterprisepatterns zu Rate ziehen.

Das wäre was ich allgemein dazu sagen kann, für den Rest(im Detail) bräuchte ich mehr Details.
Ich bin an solchen Sachen auch sehr interessiert. Experte bin ich da nicht(nach meinen Recherchen gibts auch keine) aber mich plagen ähnliche Probleme. An Erfahrungsaustausch wär ich daher sehr interessiert.

SOA heißt für mich letztlich so viel wie Contract First Design und Nicht-Stack-basierte Kommunikation .... mehr ist das eigentlich nicht.

Vor allem bedeutet SOA: Aus Anwendungssicht ist die Architektur technologie-frei, Implementierungen sind nur lose gekoppelt, am besten via Dependency Injection. Eine einheitliche Service-Beschreibung (WSDL bietet sich sicher an).

Bin gerade dabei mit Indigo anzuschauen, aber ich hab das Gefühl, das Teil adressiert nur die Server-Seite und scheint doch recht kompliziert zu sein, weil ich leider etliche Bindings und Protokolle per Hand implementieren muss (sowohl WebServices als auch MSMQ bieten mir zu wenig QoS). Zudem läuft Indigo nur auf MS-Server-BS. Ich kann aber nicht ausschließen, den Server auch auf einem XP Prof. und vor allem auf einem embedded Device laufen zu lassen (WM5.0). Da WM aber keinen managed Service-Host anbietet, müßte sowas ebenfalls Teil der Architektur sein.

Ich brauche also was leichtgewichtiges, was vor allem die Entkopplung der verwendeten Transportechnolgien sicherstellt.

"Am besten via Dependency Injection" .... nein. Am besten via Inversion of Control, aber ob man da nun besser DI oder einen Service Locator verwendet, hängt vom Szenario ab.

Wie schreibt Fowler so schön: "As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection."

Der Locator-Ansatz wäre im Prinzip auch tragbar, weil die Abhängigkeit vom Locator in meiner Anwendung unkritisch ist. Entscheidend ist nur die Implementierungsenkopplung. Zudem hab ich wohl keine Chance, ein IoC/DI-Franework wie Spring einzusetzen, weil ich das nicht in mein embeded Device bekomme.

Da bin ich wieder ganz bei Fowler: "The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application."

SOA ist mittlerweile ein Marketing "buzz word". Ich war gestern auf der CeBit. Dort hatte eigentlich jeder plötzlich SOA. Es ist zur Zeit einfach angesagt SOA zu machen bzw. zu haben.

Was möchtest Du wissen:

Wie Komponenten/Dienste in verteilten Anwendungen miteinander kommunizieren?
Wie man SOAP verwendet, um Remoteprozeduraufrufe zu machen?
Wie man Schnittstellen mit XSD Schemas definiert?
Wie Anwendungen plattformunabhängig kommunizieren?
Wie SOAP-Nachrichten aufgebaut sind?
Wie WSDL-Beschreibungen aufgebaut sind?
Wie man den Nachrichtenverkehr absichert zw. verschlüsselt?

Wie Rainbird auch sagte, ist leider SOA ein Buzzword. Wie damals Multimedia, kaum wrs erfunden schon war jeder PC Multimediafähig, und man wünschte sich den C64 zurück.
Ein Pattern zur Komponentenverwaltung wäre vielleicht noch ECC. Leider hab ich dazu noch nichts praktikables gefunden.
Scheint ein Pattern ohne Sinn zu sein. Ist es nicht, wohl eher der Zeit voraus, die Idee wird vielleicht auchmal zum Buzzword.
Ich hab den Text noch nicht voll durchgelesen(vermisse den konkreten Bezug(war für die VB6-Sektion in MSDN) und weder für die Sprache selbst relevant und noch nicht für die Praxis konkret).
Ich hab es nur überfliegen können. Lesenswert im Sinn von Ideenanstoss find ichs schon.

Den Locator werd ich mir in den nächsten Tagen bestimmt anssehen(so zwischendurch). Derzeit beschau ich mir Westphals Softwarezellen als Ableitung des vielfach interpretiierbaren Softwareuniversums.

Für dein Problem(Kommschicht austauschbar), kann ich nur den Rat geben einfache DLLs zu benutzen(einfach im Sinn der Public/Shared-Methods) und die Komm.-Schichten selbst dünn zu halten.
Factories beim Start sind derzeit kaum praktikabel(Server). Höchstens Clientseitig und dann doch lieber per Konfiguration. Die Konfiguration der Clients(Frontends unter Entwicklung deiner Person/Firma) kann durchaus bei Serverinstallation/Konfiguration erfolgen.

Es ist wie bei WebServices, da war im Prinzip auch nur ein Buzzword. Ich will mir ja auch keine angeblichen "SOA-Lösungen" verkaufen lassen, ich brauche einfach eine service-orientierte Architektur, leichtgewichtig, technologieneutral, konfigurierbar. Ich brauche praktisch keine Unterstützung für Lastverteilung oder Failover. Nichts weiter als ein paar Patterns für die Implementierung eines Service-Hosts, die Bindung und allem Security. Mich interessieren Musterlösungen, die mal explizit keine WebServices oder Messaging-Lösungen in Buzzword-Kleid sind.

Ich muss die Connectivity-Architektur für ein Produkt machen, ich möchte einfach eine tragfähige Architektur für die nächsten 8 Jahre.... und ich möchte keinesfalls eine Architektur, die bedingungslos auf einer Technologie aufsetzt.

Am besten beginnst Du gleich mit WCF (Windows Communication Foundation; vormals "Indigo"). WCF läuft definitiv auch auf Windows XP. (Siehe http://www.microsoft.com/germany/presseservice/detail.mspx?id=531558)

ASPX Webservices, Web Service Enhancements, Enterprise Services und .NET Remoting werden nicht mehr weiterentwickelt (Aussage Microsoft auf der CeBit am 10.03.2006). All diese Technologieen werden unter EINEM Programmiermodell zusammengefasst. Das zu verwendende Protokoll und die Sicherheits- und Transporteinstellungen werden über Bindungsattribute und XML-Konfigurationsdateien gesteuert. Funktionen wie
*Rollenbasierte Sicherheit *SSL-Verschlüsselung *Authentifizierung mit X.509 Zertifikaten *Verteilte Transaktionen *Automatische Verteilte Transaktionen über DTC *Performante Binärserialisierung

sind verfügbar und warten darauf per Attribut aktiviert zu werden. Mit WCF bist Du sehr flexiebel, was unterstützte Protokolle etc. betrifft. Wenn Du jetzt was neues machst, solltest Du gleich auf das richtige Pferd setzen. Hier ein Webcast zum Thema WCF:

http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=118767531

Ich hänge meine Komponenten momentan in einem selbstgeschriebenen .NET Remoting Host (Windows NT Service) auf. Die Komponenten werden per Reflection zur Laufzeit geladen und über .NET Remoting veröffentlicht. Transaktionale Komponenten laufen als ServicedComponents (Bibliotheksanwendungen). Wichtig ist, dass die Schnittstellen der Komponenten in separate Assemblies ausgelagert sind. Auf den Clients werden nur diese Schnittstellenassemblies benötigt. Eine zentrale Factory-Methode sorgt für die Erzeugung der Objekte mittels Activator und implementiert die Clientseitigen Sicherheitsfeatures (Identity in den CallContext schreiben etc.). Diese Architektur lässt sich sehr leicht nach WCF migrieren. Sobald die Beta-Phase von WCF abgeschlossen ist, werde ich alles auf WCF umstellen.

WCF ist nett, wäre auch meine erste Wahl (ein anderes Projekt hier setzt WCF schon ein), aber leider muss ich eben PDAs als Clients anbinden, und WCF läuft eben nicht auf CF. Ggf. könnte ich wenigsten die Server-Seite in WCF machen und dann den Client hartverdrahtet, aber das bringts irgendwie auch nicht. Zudem sehe ich mich jetzt schon in ein Interoperabilitätsdrama einlaufen, wenn ich WSE einsetzen möchte (bzw. muss). Hier war es schon immer schwer .NET und CF zusammenzubringen. Ich befürchte, WCF bürdet mir bei einer eventuellen Anpassung der Web Services-Implementierung auf Server-Seite mehr Arbeit auf, als bisher (wegen stärkerer Kapselung der Implementierung).

Argh..
WinXPE - Plattform ist nicht möglich?(wahrscheinlich ne rethorische Frage)
So Stapeln sich Probleme.

Edit: smilie deaktiviert.

Nee, das Teil hat auch ein paar Echtzeit-Aufgaben. In .NET soll nur die Connectivity laufen. Ist auch ne Preisfrage. Eine CE-Lizenz kostet ein paar Euro...

@Rainbird

Original von Rainbird

Eine zentrale Factory-Methode sorgt für die Erzeugung der Objekte mittels Activator

Wie machst du das? Wie bestimmst du den Typ des Objektes, den du jetzt gerade zurückbekommen möchtest? Übergibst du ein Interface?

Original von Rainbird
und implementiert die Clientseitigen Sicherheitsfeatures (Identity in den CallContext schreiben etc.).

An dem Problem häng ich gerade. Würde auch gerne über nen Windows Dienst per Binär-Serialisierung gehen. Allerdings hätte ich gern ein IPrincipal Objekt an den Server überspielt. Das IPrincipal Objekt ist von mir um Rechte noch erweitert. Allerdings kann man das Principal Objekt leider bei dem Weg über Windows Dienste nicht mit geben. Wie machst du die Identitätsübergabe?

@svenson

Echtzeit? nehmt ihr da zusätzliche Software? M.E. kann das Ce allein nicht wirklich.
Der Preis spielt natürlich auch ne Rolle. XPE kostet noch eine paar Euronen mehr.
Nur die Lizenz. Dann kommen noch Ressourcenverbrauch und dergleichen. Schlägt sich dann auf die Hardware nieder...
Von Echtzeitfähigkeit braucht man XPE allerdings nicht reden(braucht man dafür dann wieder schlauere Hardware).
Bei korrespondierenden Sytemen kann sich letzteres(XPe) lohnen, da es die Softwareentwicklung billiger machen kann. Ist aber nicht immer der Fall.
Im anderen Fall ist die Software teurer und die Hardware billiger.
Bei Software für fertige Geräte stellt sich auch nicht die Frage. Man kann dann nur Fluchen wenn man ähnliche Klassen(bei unterschiedliecher API) pflegen muss.

@Generalissimo: Factories und Abstract Factories sind Patterns(Entwurfsmuster).
Um eins zu erklären muss man nen ganzen Artikel schreiben.
Ne kurze Erklärung ist schwierig(da sie viele Einzelfälle zusammenfassen).

Wiki:
http://de.wikipedia.org/wiki/Fabrikmethode
(sehr kurz)

http://www.codezone.de/DetailPage.Codezone?GUID=92011fc8-5b42-41fd-ace7-0e267049cee3
kleines Beispiel

http://www.amazon.com/gp/product/0201633612/qid=1061459864/sr=8-2/ref=sr_8_2/002-5042627-5008811?n=507846&s=books&v=glance
Ein Buch über solche Muster
http://www.empros.ch/buecher/muster/01b895931a0df3901.html
(in deutsch)

Zum Principal: sowas remote zu übergeben ist nicht vorgesehen. Username und Passwort sind wenn nötig(aber nur wenn unbedingt nötig) zu übergeben. Entweder ist das Prinzipal aufgrund vorhandener Rechte da(Infrastruktur bietet einiges) - der User wurde Aufgrund der Verbindungsart identifiziert - oder die Anwendung(deine) muss sich um die Impersonation kümmern(dafür die Userdaten). Je nach Art der Übertragung auch um die Sicherheit der Datenübermitllung usw.
Du hast leider vergessen zu sagen was du wie übermittelst. Webapp, Webservice und Remotinghost können(müssen aber nicht) vom IIS profitieren.

@Rainbird
Wobei die Chain of Responsibilty manchmal auch ein starker Konkurrent sein kann gegenüber einer Factory, je nach Schwerpunkt halt.

Weiterentwicklung von xy. Soweit mir bekannt ist soll WCF die Technologien bündeln zu einer mehr oder weniger einheitlichen Schnittstelle. Die erste Indigobeta(mit der konnte ich mich noch beschäftigen) schaffte das auch. Die Parametrierung hingegen konnte nicht wirklich überzeugen(imho).
Ich nehme an es hat sich verbessert. Weiss es aber leider nicht.

Meine Schwerpunkte liegen derzeit anders(Ich hoffe auf Änderung 😉 )

Original von ikaros
Echtzeit? nehmt ihr da zusätzliche Software? M.E. kann das Ce allein nicht wirklich.

CE kann das durchaus. Die Latenz-Zeiten sind deutlich kürzer und anders als Windows ist der Scheduler deterministisch, d.h. CE kann nicht - wie Windows das manchmal tut - das ganze System für Sekunden lahmlegen. Man hat auch 256 Prioritätsstufen und nicht nur 5 (4, 6? egal).

Natürlich wird dieser Teil nicht mehr mit CF gemacht, schon wegen des GC.

Klar ist CE in dem Bereich besser.
Aber echte Echtzeit? Ich weiss gerade die Firma nicht mehr(Name), die damit ihre Brötchen verdient dass sie CE erweitert.
Hatte vor ein paar Monaten mal den Spass des googlens(macht manchmal keinen).
Nach meinen Erkenntnissen ist CE nicht Echtzeitfähig(da hatte ich mal das kurzfristige Vergnügen der API(nicht nur Standard) und Geräte(nein keine fertigen(Treiber etc.)). Das ist aber 26 Monate her...- die Alpträume verfolgen mich noch.

Original von Generalissimo

Original von Rainbird

Eine zentrale Factory-Methode sorgt für die Erzeugung der Objekte mittels Activator

Wie machst du das? Wie bestimmst du den Typ des Objektes, den du jetzt gerade zurückbekommen möchtest? Übergibst du ein Interface?

Ich übergebe ein Interface. Interrfaces lege ich immer in separaten Assemblies ab.

Original von Generalissimo

Original von Rainbird

und implementiert die Clientseitigen Sicherheitsfeatures (Identity in den CallContext schreiben etc.).

An dem Problem häng ich gerade. Würde auch gerne über nen Windows Dienst per Binär-Serialisierung gehen. Allerdings hätte ich gern ein IPrincipal Objekt an den Server überspielt. Das IPrincipal Objekt ist von mir um Rechte noch erweitert. Allerdings kann man das Principal Objekt leider bei dem Weg über Windows Dienste nicht mit geben. Wie machst du die Identitätsübergabe?

Ich verwende reine Windows Authentifizierung. (In der DOTNETPRO ist mal ein Artikel zu diesem Thema erschienen)

Stell am besten auf .NET 2.0 um, dort ist Sicherheit in Remoting integriert. Oder migriere Deine Projekte schnellst möglicht auf WCF (indigo). Beides sollte nicht schwer sein. Die fertigen Sicherheitsimplementierungen sind meistens besser, als selbstgebasteltes.

@ikaros

Hi,

wollte eben nicht über IIS wegen der Performance gehen. Hab mir aber jetzt mal, wie Rainbird empfohlen hat, Net 2.0 Remoting angeschaut. Werd es darüber machen.

Bezüglich der Factories: Hab schon viel darüber gelesen. Nur war ich mit meiner Umsetzung im Unklaren. Allerdings hab ich jetzt nach Rainbirds Antwort und den nochmaligen lesen der Links festgestellt, dass ich es scheinbar richtig umgesetzt hab.

@Rainbird

Reine WindowsAuthentifizierung wollt ich nicht machen, da ich es schon oft erlebt habe, das sich jemand am PC frühs sich anmeldet, dann weg geht und einfach ein anderer sich an den PC setzt und dort dann weiterarbeitet.

Hab gestern gelesen, dass Indigo nicht mit WSE 2.0 (was eigentlich nur heissen kann, dass WSE 2.0 niemals W3C-konform war) zusammenarbeitet. Damit ist Indigo ein Plattform, die schlicht nicht mit Win CE zusammenarbeitet. Da wirkt der Begriff "Service" wie Hohn. Toll, dass MS vollmundig Produkte bastelt, die untereinander interoperabel sind. Ein Hoch auf die Verpeiler des MS-Produktmarketings. Da kommt man wirklich in Versuchung mit Java zu arbeiten.....

MS sollte mal langsam begreifen, dass Interoperabilität das A&O ist. Das nichtmal bei den eigenen Produkten hinzukriegen ist echt ein Armutszeugnis. Grummel.

Wo hast Du das gelesen?

Kann ich mir nicht vorstellen. Auf den mobilen Geräten läuft doch das Compact Framework. Das kann auf jeden Fall mit Indigo-Diensten arbeiten. Du kannst doch einfach ein entsprechendes Binding auf der Serverseite verwenden, oder?

Tja, vorstellen konnte ich mir das auch nicht, aber es ist leider so:

http://weblogs.asp.net/cibrax/archive/2005/11/25/431528.aspx
http://codenameamber.blogspot.com/

Wie sagt MS so schön, "selbst schuld wer WSE eingesetzt hat. Das waren ja alles nur Zwischenschritte auf dem Weg zu Indigo".

Wie gesagt, hier geht es um WS-*. Ungesicherte WS laufen. Trotzdem bitter, weder Security, noch Transaktionen.

Carl Franklin: Okay, another question from the
chat room from Garry Durosh and he asks, “I
have heard WSE 3.0 will be wire compatible with
Indigo but WSE 2.0 will not, how is this possible.
Is WSE 2.0 using propriety or non-finalized
protocols?”

Michele Leroux Bustamente: It’s not about the
protocols. Okay, WSE 2.0 implements the WS
security based on the standard as it is today. But,
in the __ how I can describe this because I mean
the wire comparability really has to do with, Oh
God I had only been on one call with this so, it’s a
kind of hard to remember wire compatible I don’t
know. I think it this is a little bit out of my league
probably.

Richard Campbell: It’s got to be a minimum
requirements issue that WSE 2.0.is not making.

Michele Leroux Bustamente: Because I mean
what’s a wire compatible? I mean you are going
to ..

Carl Franklin: Implements all the features of the
protocol, that’s all or that particular version of the
protocol.

Michele Leroux Bustamente: Well, any
messages, so in terms of messages going live
and may be you can edit this or whatever so
someone has to think this through. But, so let’s
say WSE 3.0 implemented on 2005 and I want to
send them a message that has WS security
around it. That will work against in Indigo end
point.

Carl Franklin: Oh yes.

Michele Leroux Bustamente: Serialization will
be compatible. But, it still won’t have all of this
stuff that’s in Indigo. That’s my understanding of
it.

Carl Franklin: Yeah, that’s what it means – wire
compatible.

Richard Campbell: So most likely we are going
to be able to...

Michele Leroux Bustamente: So, 2.0 just
doesn’t have all of that finalized. I mean 2.0 is
certainly ahead of its other competitors in terms
of implementing WS security. But, it’s not
complete.

Carl Franklin: Right.

Richard Campbell: So, the point is that while it
may not be wire compatible out of the shop.
You’re going to be returned Indigo down to be
compatible with WSE 2.0 if you want just going to
be harder to do. It’s not a simple thing to get
under the pluming inside of Indigo. I know, all
that’s going to be exposed and you (voice
overlapping) switch is switch is.

Michele Leroux Bustamente: Compatibility is
an issue, though I guess for people’s that are
early adaptors and using WSE 2.0 and then
wondering well how do I deploy that when I am
now on 2005, which you can except to have the
runtime bits for 2003 as well.

Carl Franklin: But, those also made very clear
though with WSE 2.0 that it’s an early adoption. It’s a temporary stopgap until we hit Indigo.