Tweet
Hallo.
In diesem Forum ist ja leider wenig los. Dennoch möchte ich zu oben genanntem Artikel Kritik losweren.
Diesen Artikel finde ich aber leider schwach. Sowohl Struktur und Grafiken / Tabellen als auch den eigentlichen Inhalt. Daher habe ich im Folgenden einige Anmerkungen, die mir aufgefallen sind:
Tabellen:
- sind Tabelle 2 und 3 ein Druckfehler? Fehlen dort Einträge?
- Was bedeuten die zwei zugehörigen Tabellenbenennungen "Kategorien" und "Subkategorien"? Ich verstehe nicht, wo nun ein Zusammenhang ist, und ob wirklich alle Einträge abgedruckt wurden ?
- Tabelle 2: Was ist der ESB "timestamps"?
Inhaltlich:
- Tomcat kann man sicherlich auch als Application Server einordnen, wenn auch nicht JEE-zertifiziert, da es eben "nur" ein Web-Container ist. Aber das Spring-Framework und Axis2 sind doch keine Application Server, oder? Vielleicht hätte eine Definition des Begriffes "Application Server" zum Verständnis beigetragen, was hier gemeint ist.
- Einige Kriterien aus Tabelle 1 verstehe ich nicht. Was ist beispielsweise mit "Standalone" gemeint? Soll der ESB auch ohne Application Server gestartet werden können? Wieso hat z.B. Sopera hier ein "Ja (Jetty)"? Läuft Sopera nun Standalone oder nur mit Jetty?
Oder ist damit so etwas wie Camel gemeint, welches dann innerhalb eines richtigen ESBs eingesetzt wird? Wieso ist dann z.B. WSO2 nicht standalone nutzbar?
- Was ist mit Nachrichtenpersistenz gemeint? Bei JMS kann ich mir noch etwas vorstellen, aber Nachrichtenpersistenz mit JDBC? Und mit BPEL?
- Ist es nun aufwendig (siehe OpenESB-Abschnitt) oder nicht aufwendig (siehe einige andere Abschnitte) JBI zu verwenden, um Komponenten verschiedener ESBs zu kombinieren?
Einige weitere Aspekte würde ich gerne diskutieren:
- Ist JBI nicht eigentlich tot? In der Theorie ist es super, praktisch gibt es aber nur große Probleme, wenn man Komponenten eines ESB in einem anderen verwenden will?
- Folgendes Zitat ist mir unklar:"wer keinen Support braucht, Lizenzkosten scheut und über eine eigene IT-Abteilung mit genug Personalressourcen verfügt, für den kommt Petals in Frage". Gilt das dann nicht für alle ESBs, wo man selbst viel Hand anlegen muss?
- Auch das Zitat "Camel selbst stellt keine ESB-Funktionalitäten zur Verfügung..." ist seltsam. Denn Camel ist doch in diesem Artikel ein ESB? Es steht aber nur auf Seite 67 aufgelistet unter "10 Produkte, die den Open-Source-ESB-Markt abdecken". Auf der nächsten Seite in der Tabelle 1 ist Camel nicht zu finden. Aber bei den drei (aus meiner Sicht seltsamen) ESB-Kategorien ist es unter "Frameworkartige ESBs" dann doch wieder dabei? Ist Camel nun ein ESB oder nicht? (ich persönlich würde es nicht als ESB kategorisieren)
Mich würde interessieren, wie der Autor und andere Leser zu diesen Fragen stehen. Eine Diskussion würde mich freuen.
Gruß
Kai Wähner
In diesem Forum ist ja leider wenig los. Dennoch möchte ich zu oben genanntem Artikel Kritik losweren.
Diesen Artikel finde ich aber leider schwach. Sowohl Struktur und Grafiken / Tabellen als auch den eigentlichen Inhalt. Daher habe ich im Folgenden einige Anmerkungen, die mir aufgefallen sind:
Tabellen:
- sind Tabelle 2 und 3 ein Druckfehler? Fehlen dort Einträge?
- Was bedeuten die zwei zugehörigen Tabellenbenennungen "Kategorien" und "Subkategorien"? Ich verstehe nicht, wo nun ein Zusammenhang ist, und ob wirklich alle Einträge abgedruckt wurden ?
- Tabelle 2: Was ist der ESB "timestamps"?
Inhaltlich:
- Tomcat kann man sicherlich auch als Application Server einordnen, wenn auch nicht JEE-zertifiziert, da es eben "nur" ein Web-Container ist. Aber das Spring-Framework und Axis2 sind doch keine Application Server, oder? Vielleicht hätte eine Definition des Begriffes "Application Server" zum Verständnis beigetragen, was hier gemeint ist.
- Einige Kriterien aus Tabelle 1 verstehe ich nicht. Was ist beispielsweise mit "Standalone" gemeint? Soll der ESB auch ohne Application Server gestartet werden können? Wieso hat z.B. Sopera hier ein "Ja (Jetty)"? Läuft Sopera nun Standalone oder nur mit Jetty?
Oder ist damit so etwas wie Camel gemeint, welches dann innerhalb eines richtigen ESBs eingesetzt wird? Wieso ist dann z.B. WSO2 nicht standalone nutzbar?
- Was ist mit Nachrichtenpersistenz gemeint? Bei JMS kann ich mir noch etwas vorstellen, aber Nachrichtenpersistenz mit JDBC? Und mit BPEL?
- Ist es nun aufwendig (siehe OpenESB-Abschnitt) oder nicht aufwendig (siehe einige andere Abschnitte) JBI zu verwenden, um Komponenten verschiedener ESBs zu kombinieren?
Einige weitere Aspekte würde ich gerne diskutieren:
- Ist JBI nicht eigentlich tot? In der Theorie ist es super, praktisch gibt es aber nur große Probleme, wenn man Komponenten eines ESB in einem anderen verwenden will?
- Folgendes Zitat ist mir unklar:"wer keinen Support braucht, Lizenzkosten scheut und über eine eigene IT-Abteilung mit genug Personalressourcen verfügt, für den kommt Petals in Frage". Gilt das dann nicht für alle ESBs, wo man selbst viel Hand anlegen muss?
- Auch das Zitat "Camel selbst stellt keine ESB-Funktionalitäten zur Verfügung..." ist seltsam. Denn Camel ist doch in diesem Artikel ein ESB? Es steht aber nur auf Seite 67 aufgelistet unter "10 Produkte, die den Open-Source-ESB-Markt abdecken". Auf der nächsten Seite in der Tabelle 1 ist Camel nicht zu finden. Aber bei den drei (aus meiner Sicht seltsamen) ESB-Kategorien ist es unter "Frameworkartige ESBs" dann doch wieder dabei? Ist Camel nun ein ESB oder nicht? (ich persönlich würde es nicht als ESB kategorisieren)
Mich würde interessieren, wie der Autor und andere Leser zu diesen Fragen stehen. Eine Diskussion würde mich freuen.
Gruß
Kai Wähner