C++ Application-Server - Alternative zu EJBs

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.