Erste Frage: Ab wann ist SOA sinnvoll einsetzbar? Sprich: Brauch ich wirklich ein Datenbank Service und ein Email Service wenn ich eine Anwendung schreiben will die aus Datenbank Inhalten E-mails generiert. Sprich: Lohnt es sich für die kleine Anwendung oder aber erst ab größe N?
Zweite Frage: Ein Service läuft autark. Das bedeutet er arbeitet für sich selbst - Und wenn er grade viel zu tun hat muss man halt ein wenig warten bis man eine Antwort bekommt. Wie sind eure Erfahrungen in diesem Punkt?
Dritte Frage: Wie geht man vor wenn sich ein "Basis" Dienst ändert von dem ein oder mehrere Services orchestriert worden sind? Ist es dann üblich die orchestrierten Dienste zu überarbeiten? Oder geht man eher dazu 2 Versionen des Basis Dienstes zu haben?
Von mir erstmal eine komplette Runde +1 für alle. Schöne Diskussion hier. Bin leider im Moment etwas kurz angebunden, hoffe mich aber die nächsten Tage hier auch beteiligen zu können.
1.) SOA ist nach meinem Verständnis nicht dasselbe wie Verteilte Anwendung. Wenn Du nur eine einzelne Annwendung hast, bau sie so, wie es für die Anforderungen am sinnvollsten ist. SOA kommt dann ins Spiel, wenn ein oder mehrere Geschäftsprozesse durch die Interaktion mehrerer Anwendungen abbilden willst und Du Dich vor die Aufgabe gestellt siehst, diese Interaktion so zu standardisieren, dass sie bei sich ändernden oder neu hinzukommenden Geschäftsprozessen wiederverwendbar oder wenigstens gut handhabbar bleibt.
2.) Da hab ich nichts spezielles zu berichten. Natürlich kommt hier asynchrone Programmierung mit alle ihren Herausforderungen ins Spiel und auch Zuverlässigkeit (Reliability). Die jeweiligen Clients müssen so entworfen werden, dass Wartezeiten für den Benutzer verträglich gestaltet werden: Feedback, Benachrichtigungen, erst mal was anderes machen können, Abbrechen und später neu versuchen - das hängt vom Kontext ab.
3.) Keine eigenen Erfahrungen dazu, aber ich würde stark zu 2 Versionen tendieren. Eher früher als später wird ein gleichzeitiges Release der Basis-Änderung und der abhängigen Dienste organisatorisch nicht mehr möglich sein.
Ich freue mich übr die Kommentare und nutze die Gelegenheit, auf zwei Feedback-Posts zu verweisen: http://codekicker.uservoice.com/forums/21227-general/suggestions/1510383-reputations-bersicht (müßte es laut Ankündigung schon seit 8 Monaten geben...) http://codekicker.uservoice.com/forums/21227-general/suggestions/2323188-positive-und-negative-voten-getrennt-darstel
@Jürgen: magst Du noch die Idee einreichen, eine Begründung abgeben zu müssen? Das ginge ja im Prinzip sogar anonym.
mich würde mal interessieren, wie ihr darauf kommt, dass da überhaupt was negativ bewertet wurde? Wo sieht man das? Oder leitet ihr das "nur" aus einer gesunkenen Zahl ab (könnte ja auch +1 und danach -1 sein, also 0 *g*)?
Davon abgesehen würde mich es natürlich auch interessieren, was da negativ sein soll...
@Wolfgang: zu dem Zeitpunkt, als ich meinen Kommentar geschrieben habe, war die Antwort mit 0 bewertet, obwohl Nicolai laut seinem Kommentar +1 gegeben hatte. Außerdem hatte ich auf einmal 2 Punkte weniger (War zu der Zeit recht oft auf der Seite, da war mir das aufgefallen).
Ich habe gehofft diese Diskussion zu entfachen mit meinem "+1 Danke" Kommentar. Wenn jemand -1 gibt - von mir aus. Aber gleich allen Antworten in dem Thema? Ich glaube kaum ... Zumal das alles qualifizierte Beiträge waren. Vor kurzem war ich selbst davon betroffen bei einer anderen Frage - Schwups hatte jemand allen mal -1 gevotet obwohl ich mir viel Mühe gegeben hab,ist doch schade sowas. @Wolfang:Bei mir konnte ich es sehr schnell erkennen, da bei mir der "up" button orange war, die Beiträge jedoch alle eine 0 hatten. Vll wäre eine "Nur 1 Downvote alle 5 Min" auch schon hilfreich. Grüße
Danke für alle Antworten - Zu dieser Frage gab es eigentlich keine "Beste Lösung", nur viele gute Beiträge. Ich habe diesen gewählt um die schönen Kommentare oben zu halten. Wer noch mehr zu SOA schreiben möchte darf das natürlich gerne tun. Grüße
1. Immer ;) Für eine einzige Anwendung natürlich nicht. Angenommen Du hast die 2 angesprochenen Dienste so aufgebaut, dass diese nicht fix eine email-Adresse und eine Abfrage vorgeben, dann kannst Du die gleichen Dienste für hunderte Abfragen und 20 Email-Empfänger verwenden. Morgen soll dann noch eine Email versendet werden, wenn eine bestimmte Datei geändert wird und Du brauchst nur noch einen Dienst zu implementieren (Dateiänderung überwachen)...
Zusammen mit z.B. ESB (oder Message Queue oder sowas in der Richtung) ergibt sich eine schöne asynchrone Umgebung bei der laut Gartner nur noch die höheren Angestellten die Geschäftsprozesse orchestrieren (das ist allerdings ein Punkt, der ungefähr genauso funktioniert wie das papierlose Büro).
2. Ein Dienst macht nichts anderes, nur weil er mittels SOA eingebunden ist. Die einzigen Wartezeiten, die nicht Aufgaben-Abhängig sind, hättest Du also in jedem Fall (wenn z.B. die Datenbank ausgelastet ist oder der Webserver nicht schnell genug reagiert, von dem man die Daten haben will). Autark bedeutet hier eher, dass der Dienst ohne weiteren Abhänigkeiten zu anderen Diensten arbeiten "sollte". Dass das Erstellen eines Prozesses mehr Zeit kostet, als die Abarbeitung innerhalb eines Threads ist klar, kann aber vernachlässigt werden.
Du kannst nur sehr einfach eine asynchrone Verarbeitung forcieren (was auch stets zu empfehlen ist, wenn es geht). Ein muss ist das nicht.
3. Ein idealer Dienst ist sehr klein und ändert seine Aufgabe nie! Wie die Aufgabe implementiert ist, ist zweitrangig und darf sich jederzeit ändern. Aber wenn Du die Aufgabe eines Dienstes von "Email versenden" zu "Datei löschen" änderst ist ja klar, dass dann die Orchestration nicht mehr wie ursprünglich gewünscht arbeit (wenn überhaupt). Je "einfacher" ein Dienst ist (je weniger Aufgaben er hat), desto wiederverwendbarer wird er. Man kann es aber -wie mit allem- auch hier übertreiben...
1.) Aus meiner Sicht lohnt es dann, wenn eine oder mehrere der folgenden Bedingungen zutreffen:
Der Service-Teil soll wiederverwendbar sein
Zugriff über unterschiedliche Plattformen, z.B. von mobilen Endgeräten aus
Antwortzeit spielt eine untergeordnete Rolle
Der Service ist auf einen bestimmten Rechner / Topologie begrenzt, soll aber frei zugänglich genutzt werden können, z.B. wegen Sicherheitsrichtlinien
2.) Der Entwickler muss immer berücksichtigen, dass ein Service auch mal keine Antwort oder einen Fehler liefert. Aus meiner Sicht wird ein Gesamtsystem mit jedem Netzwerkzugriff anfälliger für Ausfälle
3.) Wir hatten hier ein ähnliches Problem beim Ändern eines Service für mobile Anwendungen. Ergebnis: Man braucht immer dann zwei Versionen wenn man nicht garantieren kann, dass Client und Service gleichzeitig aktualisiert werden können. Ändert man eine Service Signatur sind Zugriffe über unterschiedliche Versionen (in der Regel) nicht möglich.
