Agile Entwicklung und ESBs

stimmen
1

Ich arbeite unser Unternehmen technologisches Paradigma zu Agile Entwicklung auf verschieben. Es ist ein harter Prozess, aber wir sind fast da! :)

Wir haben Legacy-Systeme für unsere Datenbankverwaltung (verbreiteten Access, jetzt zu .NET und MS SQL portiert werden) und wir einen Rahmen für unsere Zukunftsvision zu entwickeln. Wir wollen so viel wie möglich auf die Bahn migrieren. Aber wir wollen das derzeitige System mit dem „kommenden“ eines integrieren. Wir werden nicht überlappende Aufgaben und Funktionen.

Meine Vision ist es, alle Kontaktinformationen auf unserer Benutzer in eine andere Datenbank zu bewegen, diese „Profile“ zurück in die MS SQL für ihre Geschichte und Rechnungswesen Informationen zu verknüpfen. Wir werden alle Abrechnungssysteme auf dem Desktop App halten, aber es gibt viel mehr Funktionalitäten, die wir über uns, dass hinzufügen wird stark auf die Bahn angewiesen, vor allem Ruby on Rails.

Ich denke, die Frage ist: Warum ESBs? Gibt es eine Möglichkeit, eine SOA ohne Umweg Gung-Ho mit komplexen ESBs Systemen zu erstellen. Die ganze Idee ist auf jeden Fall zu küssen. Kann eine SOA in eine Art und Weise erstellt werden, die die Desktop / Web / Mobile ermöglicht Schnittstellen zu sein, die Funktionalitäten auf der Business-Logik zu halten (natürlich würden einige Funktionalitäten auf der Schnittstelle implementiert werden, aber das auf ein absolutes Minimum zu halten). Und passen ESBs sogar eine Agile Philosophie? Je mehr ich lese und studieren, desto weniger glaube ich so! : /

Vielen Dank für Ihre Eingabe Leute! Wenn Sie mich brauchen, um zu verdeutlichen, machen nur ein paar Fragen, und ich werde mein Bestes tun, um zu tun! :)

Veröffentlicht am 09/12/2008 um 23:51
quelle vom benutzer
In anderen Sprachen...                            


3 antworten

stimmen
3

ESBs passen gut mit agilen, sobald der Rahmen / Infrastruktur vorhanden ist. Sie werden feststellen, dass Sie ein neues System in Stücke erstellen, die neuen Stücke parallel mit dem alten System eine Zeit lang laufen, und schalten Sie nach und nach die alten Teile des Systems, bis nur noch das neue System bleibt, und niemand wird jemals kennen den Unterschied

eine grundlegende SOA definiert nur Dienste anstelle von Anwendungen; ein ESB verwaltet die Dienste in Kanälen, um die Endpunkte zu verstecken, so dass Upgrades und Ersetzungen viel mehr „agilen“

Beantwortet am 10/12/2008 um 00:24
quelle vom benutzer

stimmen
1

Ich habe ziemlich schnell gelernt aus dem Begriff „ESB“ zu scheuen als itis sehr überlastete und bedeutet, verschiedene Dinge für verschiedene Menschen (und manchmal andere Dinge auf die gleiche Person :-))

Das Wichtigste, natürlich, ist, sich zu fragen, was es ist, dass Sie tatsächlich benötigen.

Wickeln Sie Ihre Datenbank (en) als Dienstleistung ist wahrscheinlich eine kluge Wahl sein, vor allem, wenn Sie mehrere Client für diese Daten haben; Sie wird eine gute Menge an Zeit, um über Ihre Verträge und Scoping denken verbringen müssen, aber agile hier sehr helfen können.

Die Frage ist nun, wie diese Dienstleistung zu tun bekommen genannt, und ich glaube, Sie brauchen die Wahrscheinlichkeit der Kunden und Dienstleistungen ändern wiegen und wie Sie Ihr System wird sich entwickeln.

Ein Linienbus hilft maskieren, die Dienste von ihren Kunden (die anderen Diensten sein kann), und dies kann „Maskierung“ auf Position relayte, Protokoll, Formate, Codes usw. einige Formen eines Service-Bus auch die Reiseroute halten (was sein muss genannt, und wenn), aber ich mag nicht generell die Idee.

so - die Frage, die Sie brauchen, um sich zuerst zu fragen, denke ich, ist das, was benötigen Sie mit und wie viel vorne Investition beginnen Sie wollen machen (und rechtfertigen)

Zum Beispiel, wenn Sie anfangs glücklich mit einem Punkt-zu-Punkt-Ansatz sind, können Sie Ihre Kunden den Service direkt anrufen; zu einem späteren Zeitpunkt, als der Dienst entwickelt, können Sie die „mittleren Menschen“ einzuführen, um die Anfrage und Antwort zu vermitteln (ja - Sie können es ESB anrufen, wenn Sie mögen).

Alternativ können Sie mit einem einfachen „mittleren Menschen“ beginnen, so dass die Kunden niemals direkt den Service anrufen, haben aber nur die Eigenschaften, mit denen Sie beginnen müssen und erweitert seine Möglichkeiten als Anforderungen Form; es kann auch als eine einfache Weiterleitung Maschine starten.

Im Idealfall würden Sie auf ein Produkt bauen, die in viele Funktionen eingebaut hat; BizTalk Server ist eine gute matchif Sie auf MS Stack sind (aber es hat Kurve lernt)

so - entschuldige mich, wenn dies nicht eine sehr konkrete Antwort ist - aber ich denke, mein Hauptpunkt ist, dass „ESB“ muss nicht zuviel des Guten sein, es kommt einfach darauf an, was Sie am Tag haben wollen, ein, und agile (und SOA ) hilft definitiv, indem Sie nach und nach, anstatt etwas wie big-Bang zu entwickeln.

(Wenn über alles ist völliger Unsinn oder einfach nur ein wenig unklar, es ist wegen des Mangels an Schlaf mit einem neuen in dem Haus geboren! Entschuldigungen :-))

Beantwortet am 10/12/2008 um 11:40
quelle vom benutzer

stimmen
0

Die gesamte Wanderung ist, was mich zu ESBs ... Aber die ganze Idee eines ESB scheint bis hin zu komplexen, ein Problem zu lösen, die rund 30.000 Profile beinhalten! Wir sind am Rande von einigem Exponencial Wachstum (um ein paar Millionen Profile) und vielleicht auf einem neuen Weg beginnend am besten wären. Wie einfach ist es, einen Eintrag zu verknüpfen, die auf MS SQL DB gespeicherten Daten auf einer MySQL-DB sitzt? Ich will natürlich nicht Doppik, aber es könnte ein agiler Weise als „Ganzes“ ESB ... Ich verstehe, dass eine SOA mit einem ESB kann in Form von Upgrades und Ersetzungen ziemlich agil sein, aber es wäre zuviel des Guten? :)

Beantwortet am 10/12/2008 um 00:41
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more