Architektur Distributed System
Laurin Stoll
Ich stehe vor einer neuen Herausforderung. Und wollte mal fragen ob
jemand von euch hier einige Erfahrungen hat mit kürzlich realisierten
Projekten (Stolpersteine, Fehlentscheide, usw.).
Und zwar geht es um die Architektur einer Kundenmanagement-Software.
Diese soll zukünftig auf vielen Plattformen laufen (OS X, Android,
iOS, Windows). D.h. es sieht sehr nach einer SOA-Server - Client
Architektur aus. Ich sehe da eigentlich gerade nur XML WebServices als
mögliche Zugriffsvariante. Habt ihr noch andere Ideen?
Hat jemand gerade sowas gemacht? Lohnt es sich eventuell andere
Kommunikationswege in betracht zu ziehen als SOAP XML Webservices?
z.B. Jabber?
Wie habt ihr es mit dem Change-Tracking gemacht? Habt ihr in allen
Clients die Objekte aufgrund von WSDL generieren lassen? Wie war der
Server aufgebaut, wurden die WSDL Objekte am Ende in Domain Objekte
verpackt?
Ich wäre sehr froh über einige Erfahrungsberichte/Ideen/Anregungen/
Tipps :-)
Danke euch schonmal,
Viele Grüsse
Laurin
Ralf Ronneburger
eine Web-Anwendung (mit unterschiedlichen GUIs optimiert f�r das
Ausgabeger�t) ist wohl keine Option? Wenn Du f�r die verschiedenen
Clients jeweils Anwendungen deployen musst, machst Du Dich vermutlich
bei Wartung und Support kaputt...
Viele Gr��e,
Ralf
Am 04.08.2010 11:31, schrieb Laurin Stoll:
> Hallo zusammen,
>
> Ich stehe vor einer neuen Herausforderung. Und wollte mal fragen ob
> jemand von euch hier einige Erfahrungen hat mit k�rzlich realisierten
> Projekten (Stolpersteine, Fehlentscheide, usw.).
>
> Und zwar geht es um die Architektur einer Kundenmanagement-Software.
> Diese soll zuk�nftig auf vielen Plattformen laufen (OS X, Android,
> iOS, Windows). D.h. es sieht sehr nach einer SOA-Server - Client
> Architektur aus. Ich sehe da eigentlich gerade nur XML WebServices als
> m�gliche Zugriffsvariante. Habt ihr noch andere Ideen?
> Hat jemand gerade sowas gemacht? Lohnt es sich eventuell andere
> Kommunikationswege in betracht zu ziehen als SOAP XML Webservices?
> z.B. Jabber?
> Wie habt ihr es mit dem Change-Tracking gemacht? Habt ihr in allen
> Clients die Objekte aufgrund von WSDL generieren lassen? Wie war der
> Server aufgebaut, wurden die WSDL Objekte am Ende in Domain Objekte
> verpackt?
>
> Ich w�re sehr froh �ber einige Erfahrungsberichte/Ideen/Anregungen/
> Tipps :-)
>
> Danke euch schonmal,
> Viele Gr�sse
> Laurin
>
Laurin Stoll
Dessen sind sich die Auftraggeber bewusst. Das ist natürlich ein
grosses Risiko. Danke für den Hinweis.
Hast du sonst sowas schon des öfterne gemacht? Hast du einige Tipps
für mich auf die obigen Fragen? Du hast mir ja auch mal einige
antworten auf einen Thread hier mit dem Thema D-DDD gegeben... :-)
Viele Grüsse
Laurin
>
> - Zitierten Text anzeigen -
Ralf Ronneburger
das ist nat�rlich schwer, ohne die genaueren Anforderungen und
Rahmenbedingungen zu kennen. Erfahrungen auf dem Gebiet Fat-Client auf
mobilen Plattformen habe ich nicht, aber mit WebServices habe ich schon
oft gearbeitet.
F�r mich w�rde das erstmal nach einer JAVA-Gui f�r die Clients riechen,
wenn Du wirklich auf Fat-Client gehen musst. Die Kommunikation mit dem
Server w�rde ich auch �ber Web-Services machen, wobei ich die Services
selbst (die asmx-Files) so versionieren w�rde, dass ich bei �nderungen
z.B. am CustomerService aus einer CustomerServiceV1.asmx eine
CustomerServiceV2.asmx machen w�rde, dann kannst Du unterschiedliche
Versionen parallel betreiben (f�r alte Clients). Die
CustomerServiceV1.asmx m�sstest Du dann nat�rlich asap aus dem Rennen
nehmen, sonst hast Du irgendwann 10 verschiedene Versionen. F�r die
Clients w�rde ich versuchen, automatische Updates umzusetzen, dann hast
Du weniger Stress mit dem Support X verschiedener Versionen im
Zusammenspiel mit Deinem Server.
Auf dem Client w�rde ich dann auf jeden Fall die View vom Rest trennen
und nur die View f�r unterschiedliche Ger�te anpassen (Du wirst ja
vermutlich auf Android eine andere GUI brauchen als auf einem OS X oder
einem PC).
Viele Gr��e,
Ralf
Am 04.08.2010 13:12, schrieb Laurin Stoll:
> Hallo Ralf,
>
> Dessen sind sich die Auftraggeber bewusst. Das ist nat�rlich ein
> grosses Risiko. Danke f�r den Hinweis.
>
> Hast du sonst sowas schon des �fterne gemacht? Hast du einige Tipps
> f�r mich auf die obigen Fragen? Du hast mir ja auch mal einige
> antworten auf einen Thread hier mit dem Thema D-DDD gegeben... :-)
>
> Viele Gr�sse
Laurin Stoll
die Art und Weise wie ich mit Daten umgehe und die bearbeite. Wie
realisiere ich ein Change Tracking?
Habe ich Methoden wie
Customer GetCustomerById(Guid id);
und nachher
UpdateCustomer(Customer cust);
und der Server macht das ChangeTracking oder gibt es da allgemeine
Patterns?
Ralf Westphal
Warum denkst du in technologischen Kategorien zuerst? XML Webservice,
SOA Server (was immer das sein mag ;-), Change Tracking...
Viel wichtiger ist doch erstmal zu wissen, warum diese Clients auf
einen Server zugreifen sollen.
In welchen Fällen kommunizieren die mit ihm? Um welche Daten und
wieviele geht es?
Was sind dann die Anforderungen an Antwortzeiten, Robustheit,
Sicherheit?
Es gibt viele Alternativen zu XML Webservices (womit du WSDL/SOAP
Webservices meinst):
1. REST Service
2. Jabber Service
3. SQS Service
4. FTP
5. WebDAV
Dahinter steckt dann auch die Überlegung, ob die Kommunikation sync
oder async sein soll. (Du kannst dir denken, was da mein Standpunkt
ist ;-)
Aber zuerst: Wie sieht die Grob-Architektur aus? Wo sind die Bounded
Contexts? Wo sind die Partitionen? Und damit dann auch: Wo sind denn
eigentlich die Daten, auf die zugegriffen wird? In welchem Schema
liegen die dort?
Wenn du Klarheit über die BCs hast, dann kommt vielleicht raus, dass
du keinen Webservice brauchst, weil die Daten in SimpleDB liegen und
die Clients darauf direkt zugreifen können.
Bottom line: Entscheidungen bzgl Technologien lassen sich nicht
fällen, ohne Inhalte zu kennen.
Henning
neben den Hinweisen von Ralf bin ich die Tage über zwei Posts
gestolpert, die dir vielleicht auch Denkansätze liefern können:
"Building Distributed Apps with NHibernate and Rhino Service
Bus" (http://msdn.microsoft.com/en-us/magazine/ff796225.aspx) und
"Data access is contextual, a generic approach will fail" (http://
ayende.com/Blog/archive/2010/08/06/data-access-is-contextual-a-generic-
approach-will-fail.aspx). Auch wenn die nicht unbedingt den dort
genannten Tool-Stack verwenden willst, so sind die Überlegungen ja
auch auf andere Technologien übertragbar.
Laurin Stoll
Bitte entschuldigt die etwas späte Antwort. Die Arbeit.... O:-)
First of all: @Henning: Danke für die zwei äusserst interessanten
Links. Habe mir die Artikel gelesen. Sehr spannend! Eine Frage drängt
sich mir da grad auf. Ist der Rhino Service Bus interoperabel? Kann
ich den auch von Java aus konsumieren?
@Ralf. Danke für deine ausführliche Antwort. Ich wollte bewusst nicht
zuviele Background geben. Weil ich mich eben inspirieren lassen wollte
und hoffte einige Leute hätten hier vielleicht etwas zu einer Lösung
zu sagen die sie in letzter Zeit mal gebaut haben. Aber das holen wir
jetzt nach :-)
> Viel wichtiger ist doch erstmal zu wissen, warum diese Clients auf
> einen Server zugreifen sollen.
diversen Clients bedient werden soll: Smart Client, Web Client, PDA,
usw. Aber ansonsten finde ich die Frage etwas merkwürdig, was meinst
du genau?
> In welchen Fällen kommunizieren die mit ihm?
werden sollen. Das können Kontaktdaten, Aufgaben usw. sein. In vielen
Fällen sind das aber wohl eher CRUD szenarien.
> Um welche Daten und wieviele geht es?
> Was sind dann die Anforderungen an Antwortzeiten, Robustheit,
> Sicherheit?
Anforderungen gut abgedeckt sein. Es handelt sich um kritische
Kundendaten, da darf die Sicherheit nicht fehlen. Die Antwortzeiten
müssen schnell genug sein, dass ein Benutzer gerne täglich damit
arbeitet.
> Es gibt viele Alternativen zu XML Webservices (womit du WSDL/SOAP
> Webservices meinst):
>
> 1. REST Service
> 2. Jabber Service
> 3. SQS Service
> 4. FTP
> 5. WebDAV
>
> Dahinter steckt dann auch die Überlegung, ob die Kommunikation sync
> oder async sein soll. (Du kannst dir denken, was da mein Standpunkt
> ist ;-)
> Aber zuerst: Wie sieht die Grob-Architektur aus?
alles :-) Aber vielleicht ist das auch nur so, weil ich das schon oft
so gemacht habe? Deshalb eben die Frage nach weiteren Ideen/Ansätzen/
Erfahrungen =)
> Wo sind die Bounded Contexts?
Bounded contexts gelesen, unter anderem in Eric Evans buch. Habe mir
schon oft überlegt ob man davon mehrere hat in einem System das
letztlich einfach diverse Arten von Kundendaten verwaltet. Wie
identifiziere ich die am besten? Hast du mir da eine Hilfestellung?
> Wo sind die Partitionen?
Unter Partitionen verstehst du verschiedene UI Frontends?
> Und damit dann auch: Wo sind denn
> eigentlich die Daten, auf die zugegriffen wird? In welchem Schema
> liegen die dort?
Access geschrieben/gelesen.
> Bottom line: Entscheidungen bzgl Technologien lassen sich nicht
> fällen, ohne Inhalte zu kennen.
wenn auch immer noch dürftig. Aber vielleicht regts ja jemanden an mir
etwas von seiner Erfahrung mit solchen Systemen mitzugeben? Ein CRM
System ist ja jetzt ein relativ klassischer Fall.
Besonder interessiert mich aber auch meine obige Frage zu den Bounded
contexts und den Partitionen, hast du mir dazu noch ein paar Infos?
Natürlich habe ich dazu auch deinen Artikel vor einigen Monaten in der
dnp verschlungen :-)
Viele Grüsse vom wissenshungrigen Laurin
Henning
RSB ist ja open source, vielleicht kann man das ja nach Java
portieren :)
Ralf Westphal
Du bleibst sehr allgemein: es ist ein CRUD Szenario. Sagst du.
Dann kann bei solcher allgemeiner Anforderung auch die Antwort nur
sehr allgemein ausfallen: Na, wenn es CRUD ist, dann setze ein RDBMS
in der cloud auf und alle machen C/S Zugriff darauf. Mit Amazon RDS
sollte das doch einfach auch plattformübergreifend möglich sein.
Oder?
Zu Bounded Contexts kannst du hier was von mir lesen: http://bit.ly/c0NmOw
Der Zusammenhang ist zwar ein anderer, aber das macht nichts, denke
ich.
> > einen Server zugreifen sollen.
>
> Die Clients wollen auf den Server zugreifen, weil das System von
> diversen Clients bedient werden soll: Smart Client, Web Client, PDA,
> usw. Aber ansonsten finde ich die Frage etwas merkwürdig, was meinst
> du genau?
für alle?
Und wollen alle dasselbe? Wirklich?
> > Um welche Daten und wieviele geht es?
>
> Es geht um tausende von Kundendaten.
Tausende Kundendaten auf einem PDA darstellen zu wollen, ist natürlich
Quatsch.
Und damit sind wir wieder bei der mangelnden Differenziertheit deiner
Darstellung.
Das ist so, als würdest du fragen, "Wie kann ich meine Software
schneller machen?"
Darauf lässt sich in tausenderlei Weise antworten - oder besser gar
nicht, weil die Frage unpräzise, ohne Kontext ist.
> > Aber zuerst: Wie sieht die Grob-Architektur aus?
>
> Noch garnicht. Frontend .... Backend .... DB. Das ist eigentlich
> alles :-) Aber vielleicht ist das auch nur so, weil ich das schon oft
> so gemacht habe? Deshalb eben die Frage nach weiteren Ideen/Ansätzen/
> Erfahrungen =)
Aber lass dich doch nicht von der Pauschalität der Wünsche des Kunden
beeindrucken.
Suche die Differenzierungen.
Oder ist wirklich alles gleich und alles so einfach? Hm...
>
> Die liegen in einer SQL Server DB und werden da von Telerik Open
> Access geschrieben/gelesen.
Aber sollen so die verschiedensten Frontends damit umgehen?
Das bezweifle ich.