praxisfrage: service-orientierte architektur

hallo,

mein frage wie service-orientiert mit wcf implementiert werden kann, habe ich bereits gefunden.

was ich mich jetzt aber frage bei folgendem szenario...

angenommen client kriegt von einem service viele daten, die auch visualisiert werden. was passiert, wenn man mit diesen daten jetzt arbeiten will...

habe mal gelesen: der preis der losen entkopplung/starken kohärenz geht auf redundanz von daten...

sprich ich will eigentlich nicht/ finde es unsinn in einer soa welt die daten die vorher selektiert wurden wieder an einen andren service zur weiterverarbeitung zu geben... sinnvoll wäre da doch sicherlich nur wenn dann die ids zu übergeben und der service müsste sich erneut die datensätze vom datenservice besorgen...

wenn jetzt aber die datensätze verändert wurden... irgendwie macht es mir bauchschmerzen in einer hochfrequenten anwendung immer viele daten hin und herzuschicken... die roundtrips machen doch alles kaputt?!

mhh wollte das einfach mal so in raum stellen und eure meinung dazu wissen!?

sprich ich will eigentlich nicht/ finde es unsinn in einer soa welt die daten die vorher selektiert wurden wieder an einen andren service zur weiterverarbeitung zu geben... sinnvoll wäre da doch sicherlich nur wenn dann die ids zu übergeben und der service müsste sich erneut die datensätze vom datenservice besorgen...

Dann wirst Du SOA generell nicht mögen.

Das ist nicht verwerflich, denn SOA ist nicht für alles und jeden geeignet. SOA verursacht einen sehr hohen Aufwand, viel Redundanz, jede Menge Infrastruktur und obendrauf sind SOA-Konstrukte definitiv recht träge.

SOA ist für Firmen geeignet, ...*... die komplexe Geschäftsprozesse haben *... deren Geschäftsprozesse sich oft ändern *... die sich das auch Leisten können und die nötige Infrastruktur haben

Und natürlich ist auch nicht jede Art von Anwendung für eine SOA geeignet.

Wenn man mit herkömmlichen Mitteln gut zurechtkommt, gibt es eigentlich keinen Grund, auf SOA umzusteigen. Es gibt ja auch keine einzige fertige Business-Anwendung, die wirklich nach SOA-Prinzipien funktioniert irgendwo zu kaufen.

In einer SOA-Umgebung müssen die Dienste autonom sein. Wenn alle auf die selbe Datenbank zugreifen und nur IDs austauschen, ist das nicht mehr der Fall. In einer echten SOA-Anwendung, müsste ich einen einzelnen Dienst einfach durch den eines anderen Herstellers austauschen können. Nur die Orchestrierungen und ggf. ein paar Mappings anpassen, und schon sollte es mit dem neuen Dienst laufen. Was das Produkt vom Hersteller X für eine Datenbank verwendet, oder ob überhaupt interessiert an dieser Stelle nicht.

Man muss, glaube ich, vom verbreiteten 3-Schichtendenken völlig weg, wenn man in Richtung SOA gehen will. Es steht da nicht mehr alles schön in Reih´und Glied im SQL Server, wo man es dann sofort mit SELECT x FROM y rausholen kann. Man muss Nachrichtenorientiert denken. Es werden nur och Nachrichten verschickt, empfangen, in Warteschlangen gestellt, transformiert und verarbeitet. Konsequenterweise, darf in einer SOA-Anwendung eine WCF-Operation NIEMALS direkt einen string oder einen DataContract zurückgeben. Alles muss mit MessageContracts gemacht werden. Nur so erhält man orchestrierbare und versionierbare Nachrichtentypen. Eine Dienstoperation kennt eine Anfragenachricht (request) und eine Antwortnachricht (response). Sonst nichts! Manchmal nicht einmal das, z.B. bei OneWay-Operationen. Damit wäre die Kommunikation zwar nachrichtenorientiert (also im Sinne von SOA), die eigentliche Implementierung der Geschäftslogik aber noch lange nicht.

Eine Möglichkeit in dieser Richtung weiterzukommen ist, die Anwendung in einer Infrastruktur aufzuhängen, die auch bei der Persistenz nachrichtenorientiert funktioniert. Z.B. ginge das mit dem BizTalk Server. Der hat eine sogenannte MessageBox, in der alle Nachrichten, die gerade irgendwo liegen, waren oder gerade eingegangen sind in einem großen Topf (unter der Haube ein SQL Server) abgelegt werden. Jede Nachricht hat ein Schema (XSD) und diverse Metadaten (welche auf dem Weg angesammelt wurden). Die Dienste von der Infrastruktur automatisch mit den Nachrichten versorgt, die für sie gedacht sind. Das ist aber eine ganz andere Art Software zu entwicklen, wie das die meisten von uns gewohnt sind.

Es ist aber am Ende nur Theorie. Solche Anwendungen existieren nicht (nur in einzelnen Teilbereichen wie z.B. EAI). Ob das wirklich so der Renner ist/wird, daran darf auch gezweifelt werden. Momentan ist der Aufwand zu hoch, um feingranulare Dienste (im Sinne von Bestandteile einer Anwendung) so autonom zu halten und über Orchestrierung zu verbinden.

Die meisten verstehen unter SOA, dass man die Geschäftslogik einer Anwendung über definierte Schnittstellen entfernt aufrufen kann. Man könnte diese Sichtweise auch vereinfacht so formulieren: SOA = (n-Tier + Webservices).

Die meisten verstehen unter SOA, dass man die Geschäftslogik einer Anwendung über definierte Schnittstellen entfernt aufrufen kann. Man könnte diese Sichtweise auch vereinfacht so formulieren: SOA = (n-Tier + Webservices).

verstehe 😃
danke für die erläuterung