C++ Application-Server - Alternative zu EJBs

Artchi

Ich brauche ganz bestimmt nicht über den Tellerrand schauen, denn ich prorgammiere beruflich seit 5 Jahren in Java täglich. Die letzten zwei Jahre auf IBMs WebSphere Application Server. KEINER hier in unserem Team mag die Arbeit damit! Wir machen das nur, weil es dafür Geld gibt, weil der Kunde WebSphere und Java als Konzernstrategie hat und wir uns nach dem Kundenwunsch richten müssen, weil irgend ein Vorstandsidiot 1998 Java als IT-Strategie im Konzern festgelegt hat.

Hört sich für mich so an, als ob Du die Probleme mit WAS auf Java
überträgst. Ich kenne WAS auch ganz gut - hab das Ding auch hassen
gelernt. Das hat aber nicht primär mit Java zu tun - schau Dir mal
kleine und schlanke AppServer wie Jboss an - damit arbeitet es sich
ganz anders.

Vermutlich musst Du Dich auch mit WSAD oder neuerdings RAD rumschlagen.
Auch hier gilt - durch Java sind komfortable IDEs wie Eclipse erst
möglich, wenn IBM das Ding aufbläst, bis es länger für den Start braucht
als eine 747 (ab Terminal bis zum Ereichen der Reiseflughöhe )
ist das nicht der Fehler von Java!

Und den "Vorstandsidioten" würde ich zu seiner Entscheidung beglückwünschen!
Wobei sich hier die grundsätzliche Frage stellt, ob eine solche Entscheidung
auf Vorstandsebene getroffen werden sollte oder ob das nicht eher
Abteilungs/Projekt-bezogen entschieden werden müsste

Hallo und danke für die vielen Beiträge!

Artchi schrieb:

Was ist zur Zeit der Hype? SOA mit WebServices (SOAP)! Das ist das was zur Zeit alle großen der Branche pushen und sogar zusammen arbeiten (IBM, Microsoft und BEA!) und gemeinsam die Specs setzen. JEE bzw. Java ist nur noch das Werkzeug, Javas RMI spielt hier absolut keine Rolle mehr.

Kannst Du etwas mehr dazu aus der Praxis erzählen, hast Du eventuell auch Links dazu? Das grade SOAP stark im mommen ist liegt doch aber mehr in der Natur, dass es die einfachste Möglichkeit ist, verschiedene Anwendungen miteinander kommunizieren zu lassen(Stichwort: EAI). Aber das SOAP gepusht wird, war mir neu.

Du redest von Konzern - daraus folgere ich mal das es sich um ein größeres Unternehmen handeln müsste. Habt ihr denn eine homogene Softwarelandschaft, oder einfach eine Menge unabhängiger Teilsysteme? Kommuniziert eure Software(im WAS) mit anderen Programmen(C++, Assembler, COBOL)? Wär mal interessant ein paar Meinungen aus der Praxis dazu zu hören - besonders falls ihr eine SOA habt.

@HumeSikkins: Danke für den Link - werde mir das mal genauer anschauen!

Prof84

@Artchi:
Man kann Dir ja nicht vorwerfen, dass Du nicht lernfähig bist:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-66483-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html

@all:
Warum es Applicationsserver überwiegend nur in Java oder .NET gibt, ist die TYPENSICHERHEIT ! Deshalb gibbet bis jetzt kein J2EE 1.5.xx.

Die Service-orientierung ist ein sprachenunabhängiges Paradigma.

Warum C++ in einen Enterprise-Applicationsserver nicht verwendet wird ist auch logisch - ein Wilde Pointer and der richtigen(falschen) Stelle und Tschüss ... Aber das wurde hier schon erwähnt.
C++ ist immer noch vorne bei der Performance-Optimierung, HW-nahen Bereich und Grid-Computering.

Prof84 schrieb:

Die Service-orientierung ist ein sprachenunabhängiges Paradigma.

Das schon, aber verwendet man nicht in der Praxis meistens einen J2EE AppServer als zentrale Stelle wo die einzelnen Dienste zusammenlaufen? Dabei ist dann auch wieder die Frage warum J2EE oder warum nicht.

Artchi

@Leon123! Ja, es ist ein Konzern, ist wohl einer der größten in Europa. Entsprechend ist da viel im Gange bzgl. IT. Systeme gibts hier viele, hauptsächlich IBM-Mainframes die natürlich ein paar Mio. EUR kosten. Die tauschen hauptsächlich Daten über MQSeries aus. Es gibt dann noch OracleDBs und SAP-Systeme. Letztendlich tauschen alle irgendwie Daten untereinander aus. Meistens Nachts in einem Batchlauf, per Filetransfer oder sowas. Je nach Lust und Laune.

WebServices sind erst seit kurzem bei uns am kommen. Wir sind seit zwei Jahren mit die ersten die das im Konzern machen.

Das eigentliche neu definierte Ziel im Konzern: Servicebus. D.h. ein Client fragt einfach nach, was er will, und der Servicebus weiß wo er wo was herbekommt. Der Client selbst hat keine Ahnung wo er das ganze herholen muß. Er schickt mehr oder weniger nur eine Beschreibung seines Wunsches los und bekommt das Ergebnis dann zugestellt.

OK, hört sich ziemlich nach Phantasterei an. Und das wird es wohl auch erstmal bleiben. Weil die Entwicklung (für uns Implementierer) leider nicht so einfach ist, wie es einem erzählt wird. Im Konzern gibt es alleine hier am Standort ca. 140 Firmen, die für den Konzern arbeiten. Du kannst ja mal die IT'ler und Projektanzahl hochrechnen, wenn da auch Größen wie IBM und SAP dabei sind. Ich kenne ca. 4 weitere Projekte in denen Kollegen involviert sind. Wir sind bisher die einzigen von diesen, die WebServices implementieren um dem Servicebus-Ziel näher zu kommen. Aber es wird noch dauern, bis der KOnzern mit allen Projekten auf diese Technologie migriert ist.

Die MIgration kostet unsummen von Geld! (und damit meine ich nicht ein paar Millionen, du kannst da gerne zwei Nullen dran hängen!) Und wird wohl noch ein Jahrzent dauern, wenn man wirklich alles migrieren will.

Deshalb halte ich die ganzen J2EE-Sprüche für eine große Lüge. Weil ich täglich sehe, das Java kein Wundermittel ist (es gibt genug Projekte in meinem Umfeld, da alles neue in Java implementiert wird).

Artchi

Prof84 schrieb:

@Artchi:
Man kann Dir ja nicht vorwerfen, dass Du nicht lernfähig bist:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-66483-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html

Wie darf ich das verstehen?

Prof84 schrieb:

@all:
Warum es Applicationsserver überwiegend nur in Java oder .NET gibt, ist die TYPENSICHERHEIT ! Deshalb gibbet bis jetzt kein J2EE 1.5.xx.

Wie darf ich das mit der Typensicherheit verstehen? (ich glaube wir verstehen nicht das gleiche darunter!)

Prof84 schrieb:

Die Service-orientierung ist ein sprachenunabhängiges Paradigma.

Ein Grund mehr, das der Service auch in C++ oder Cobol oder Pascal oder... implementiert werden kann.

Prof84 schrieb:

Warum C++ in einen Enterprise-Applicationsserver nicht verwendet wird ist auch logisch - ein Wilde Pointer and der richtigen(falschen) Stelle und Tschüss ... Aber das wurde hier schon erwähnt.

Aha, und eine Java/.NET-Anwendung kann nicht abstürzen? Sorry, aber es kommt mir immer so vor, als ob mir jeder erzählen will das C++ die eizige Sprache ist, in der ein Programmablauf unbeabsichtig aus der Bahn fliegen kann.

Prof84

Artchi schrieb:

Prof84 schrieb:

@Artchi:
Man kann Dir ja nicht vorwerfen, dass Du nicht lernfähig bist:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-66483-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html

Wie darf ich das verstehen?

Positiv!
Ich sehe, dass Du Dich weiterentwickelt und das, was Du etwas was Du früher kategorisch abgelehnt hast, zu deinen Stärken machtest.
Erkenntnis - Neubewertung - Verbesserung!
Nach 4,5 Jahre Mitgliedschaft beobachtet man einige Stammgäste hier.
Einige entwickeln sich weiter, Andere stagnieren.

Artchi schrieb:

Prof84 schrieb:

@all:
Warum es Applicationsserver überwiegend nur in Java oder .NET gibt, ist die TYPENSICHERHEIT ! Deshalb gibbet bis jetzt kein J2EE 1.5.xx.

Wie darf ich das mit der Typensicherheit verstehen? (ich glaube wir verstehen nicht das gleiche darunter!)

Let me tell it in this way:
http://madbean.com/anim/jarwars/

Artchi schrieb:

Prof84 schrieb:

Warum C++ in einen Enterprise-Applicationsserver nicht verwendet wird ist auch logisch - ein Wilde Pointer and der richtigen(falschen) Stelle und Tschüss ... Aber das wurde hier schon erwähnt.

Aha, und eine Java/.NET-Anwendung kann nicht abstürzen? Sorry, aber es kommt mir immer so vor, als ob mir jeder erzählen will das C++ die eizige Sprache ist, in der ein Programmablauf unbeabsichtig aus der Bahn fliegen kann.

Habe ich auch nicht behauptet.
Die gesamte Speicherverwaltung ist Java-intern (Garbage-Collector).
Aus dem Packages kannst Du Klassen nur aus den Basisklassen/Funktionen ableiten - LEGO-Steine->Ritterburg!
Wobei bei der JDK 1.5 wohl zugegebenermassen mittlerweile schon fasst alle erdenklichen Eventualitäten für Basisklassen abgedeckt hat.

Mit C++ kannst Du selber fundamentale Basisklassen und Funktionen entwickeln
- Plastikgranulat -> LEGO-Steine!

.NET - see Java.

Die Legosteine sind standardisiert, unverwüsslich, kindersicher ...
Plasikgranulat ist weniger userfriendly.
Du kannst Java selbst nicht abschießen, sondern nur was auf Java läuft.
Mit C++ hast Du keine abgesicherte Plattformverwaltung.

Gregor

Prof84 schrieb:

Du kannst Java selbst nicht abschießen, sondern nur was auf Java läuft.
Mit C++ hast Du keine abgesicherte Plattformverwaltung.

Naja, es gibt auch Möglichkeiten, Java so weit zu treiben, dass man es als "abgeschossen" bezeichnen könnte. Was ist zum Beispiel, wenn man einen "StackOverflowError" oder einen "OutOfMemoryError" provoziert? Ich habe da im Hinterkopf, dass bei Auftreten eines "Errors" (im Gegensatz zum Auftreten einer "Exception") nicht mehr gewährleistet ist, dass sich die JVM in einem konsistenten Zustand befindet. Ich habe da bisher auch immer nur gehört, dass man aus diesem Grund Errors besser nicht fängt, sondern besser das Programm beendet. Aber ich kenne mich da zugegebenermaßen nicht so gut aus. Kann auch sein, dass man soetwas irgendwie begrenzen kann. Auf einen Thread oder so. ...weiß nicht. Aber man hat in Java sicherlich weniger Möglichkeiten, solche schwerwiegenden Probleme einzubauen.

Artchi

Errors kann man in Java garnicht abfangen! Wenn z.B. ein OutOfMemoryError kommt, dann kann man noch soviele try-Catch-Blöcke einbauen, die lassen sich nicht abfangen. Schon alles erlebt, z.B. auch bei einer zu tiefen Rekursion... StackOverflowError.

Gregor

Artchi schrieb:

Errors kann man in Java garnicht abfangen! Wenn z.B. ein OutOfMemoryError kommt, dann kann man noch soviele try-Catch-Blöcke einbauen, die lassen sich nicht abfangen. Schon alles erlebt, z.B. auch bei einer zu tiefen Rekursion... StackOverflowError.

Klar geht das:

Zum Beispiel bei nem StackOverflow:

public class ErrorTest
{
   public static void main(String[] args)
   {
      try
      {
         test();
      }
      catch(StackOverflowError e)
      {
         System.out.println("Gefangen! :)");
      }
   }

   public static void test()
   {
      test();
   }
}

Output:

gregor@linux:~/JavaProjects/Test/ErrorTest> /usr/java/jdk1.6.0/bin/java ErrorTest
Gefangen! :)

...Oder zum Beispiel da:

public class ErrorTest
{
   public static void main(String[] args)
   {
      try
      {
         int[] a = new int[500000000];
      }
      catch(OutOfMemoryError e)
      {
         System.out.println("Gefangen! :)");
      }
   }
}

Output:

gregor@linux:~/JavaProjects/Test/ErrorTest> /usr/java/jdk1.6.0/bin/java ErrorTest
Gefangen! :)

Artchi

Hem, dann hab ich da wohl was durcheinander gebracht.

Aber zumindest, wenn man diese nicht abfängt, ist das Programmverhalten nicht mehr kontrolliert. Als wenn ich z.B. bei einer NumberFormatException kontrolliert reagiere. Denn abfangen tue ich errors nicht, da ich dazu vom Compiler nicht gezwungen werde. Natürlich könnte ich bei jedem new entsprechend ein try-catch rum bauen, aber ich bezweifel das dies gängige Praxis ist?

Gregor

Artchi schrieb:

Aber zumindest, wenn man diese nicht abfängt, ist das Programmverhalten nicht mehr kontrolliert. Als wenn ich z.B. bei einer NumberFormatException kontrolliert reagiere. Denn abfangen tue ich errors nicht, da ich dazu vom Compiler nicht gezwungen werde. Natürlich könnte ich bei jedem new entsprechend ein try-catch rum bauen, aber ich bezweifel das dies gängige Praxis ist?

Ne, es geht ja gar nicht darum, soetwas um jedes new oder jeden Methodenaufruf herumzubauen. Der Gedanke war eher, dass man gewisse Programmteile hat, die das Programm nicht insgesamt abschießen sollen. So dass man möglicherweise um diese Programmteile herum ein entsprechendes try-catch baut, in dem dann zum Beispiel RuntimeExceptions gefangen werden. Dann kann man in dem catch immer noch darauf reagieren, dass in diesem Programmteil ein Bug aufgetreten ist, ohne die grundsätzliche Funktionsweise des Programms zu beeinträchtigen. Das macht natürlich nur dann Sinn, wenn solche Programmteile und der Rest des Programms relativ unabhängig voneinander sind.

...und mit Errors ist das, wie schon gesagt, etwas problematischer: Die kann man zwar fangen, man sollte das aber nicht machen. Zumindest nicht, solange man nicht ganz genau weiß, was das für Auswirkungen auf die JVM usw. haben könnte.

Prof84

@Gregor:
Verstehe Deine Vorbehalte bei der JVM nicht:

Wenn die Instanzbildung einen Error wirft, löscht die JVM die Instanz des übergeordneten Objektes und wirft eine Exception/Error. Das ist natürlich eine Kascade die zum Exit führen kann, wenn sie ohne try-catch bis main läuft. Aber der Java Heap bleibt unangetastet. Genau aus diesen Grund setzt man ja Java bei unternehmenskritischen Systemen ein. Stell Dir mal vor, ein Eintwickler wäre besoffen und crashed/de-stableized die Java-Plattform im Finanzsektor . Und genau aus diesen Grund hat man bei EJB 2.0+ XML-Schmierstoff zwischen den Komponenten eingeführt. Wenn eine Komponente abgeschossen wurde, hat das nur noch Einfluss auf Stream-Ebene.

Middleware-Technologien, wie CORBA, RMI, (D)COM(+) und IDL, haben auch komplizierte Systeme für Error/Exception Handling. Aber die waren a) nicht kindersicher, b) schwer zu handhaben und c)unübersichtlich.

Und aus dem selben Grund setzt sich heute XML-basierte Service-Orientierung durch. Früher setzte man binäre Austauschformate wie EDI, EDIFACT ein, die extrem kritsch waren bei Wartung und Erweiterung der Systeme. Und angesichts moderner Bandbreiten und Server-Performance ist der Geschwindigkeitsverlust mittlerweile vernachlässigbar.

jox

Hi,
es gibt als Application-Server den XSPD, sogar für C !
Schau mal unter:

http://home.arcor.de/joachimschulze/xsp/index.html

oder einfach google'n mit "XSPD"

Der XSPD unterstützt z.Zt. Programme bzw. Servlets in C, Java und/oder Shell-Scripts, läuft unter diversen Unix/Linux-Derivaten. Ein Interface für C++ sollte auch kein großes Problem sein, für Java gibt es bereits eine shared Library als Schnittstelle, die man ggf. auch für C++ benutzen könnte.
CORBA wird nicht unterstützt, Web-Server-Dienste gehen über den "normalen" Web-Server (z.B. Apache). Was verstehst Du unter Caching im Zusammenhang mit einem Application-Server?

Der XSPD ist sau-schnell, mit simplen C-Programmen zum Performance-Test bei etwa 1500 request/sec (5 Mio request/hour), bei Java etwa 1000 request/sec, alles auf einem normalen PC gemessen.

Alle Applikationsprogramme werden als separate Prozesse gestartet, deswegen verstehe ich die Diskussion im Forum wegen Absturz bzw. gemeinsamer Adressbereiche nicht. Das kann man auch vernünftig realisieren. Wenn ein Programm abstürzt, dann halt nur das, aber nicht der Rest, basta!

Die neueste XSPD-Version kommt demnächst, aber die aus dem Netz rennt auch schon gut (und wird seit Jahren im produktiven Betrieb genutzt).

Schau mal rein, oder mail bei Bedarf bzw. weiteren Fragen zurück.

kartoffelsack

XSPD scheint aber eher ein Web(Application)Server als ein Application-Server zu sein (d.h. entspricht eher einem Tomcat als einem JBOSS).

Ein anderer interessanter WebApplicationServer für C++: http://www.opents.com/retro2.html

jox

Einen Unterschied zwischen einem Web-Application-Server und einem Application-Server gibt es nicht wirklich. Beide Begriffe sind äquivalent.

Der Begriff "Application Server" ist zwar sehr schwammig und ist nicht genau definiert, ich verstehe hierunter aber (in der heutigen Begriffswelt) zumindest einen Session-Bezug zwischen aufeinanderfolgenden HTTP-Requests, so dass man hierüber einen Sitzungs-spezifische Workflow abbilden kann inklusiver Session-spezifischer Variablen oder Session-Objekten (so etwas bietet z.B. tomcat, der sich auch als "Application Server" bezeichnet). Wie gesagt, über den Begriff "Application Server" kann man sich trefflich streiten.

Etwas anderes ist ohne Zweifel ein "J2EE kompatibler" Application-Server (wie z.B. jBoss). Wie man so etwas für C/C++ abbilden soll, ist mir schleierhaft (die "Kompatibilität" beinhaltet nämlich auch die Java-Schnittstelle). Hingegen läßt sich so etwas wie EJB's (als Bestandteil von J2EE) natürlich auch mittels C/C++ nachbilden.

Retro scheint nach meinem Kenntnisstand bzw. meinem Verständnis KEIN Application-Server zu sein, ich vermisse hier jedenfalls den sonst üblichen Session-Bezug zwischen mehreren HTTP-Requests, bzw. es gibt hier kein Session Object. Ich finde in der Dokumentation jedenfalls keinen Hinweis hierauf.

Der XSPD hingegen verwaltet jedenfalls Sessions, und das übergreifend zwischen Java, C und Shell-Skripts. Siehe hier für Java z.B. http://home.arcor.de/joachimschulze/xsp/xspjsys/doc/index.html mit der Klasse XSPSession, vergleichbar mit der Java Servlet Klasse HttpSession. Für C- und Shell-Programme gibt es ähnliche Zugriffe auf Session-Komponenten. Der XSPD ist vergleichbar mit dem tomcat, allerdings auf Basis C und für C, und kann somit als Application-Server mithalten.