C++ Application-Server - Alternative zu EJBs

Hallo,

noch was vergessen:

Artchi schrieb:

Ein stichhaltiges Argument, warum Java/.NET für Businessserver besser geeignet ist, konnte mir bisher leider niemand liefern. Mein Tischnachbar hier sagt auch, das Java und .NET besser sind (wir machen ja Projekte auf WebSphere, so ist das ja nicht). Aber Argumente, die das C++ aus der Bahn werfen, konnte mir keine liefern. Klar, es gibt mittlerweile mehr Produkte für Java in dem Bereich, keine Frage. Aber das ist nur eine reine Geldgeschichte, keine mit technischen Hintergrund.

Sorry, aber das ist quatsch. Lies Dir mal Beispielsweise
http://atlas.web.cern.ch/Atlas/GROUPS/SOFTWARE/OO/tools/java/misc/ACritiqueOfC++.pdf durch. Und wenn Du danach noch immer davon überzeug bist, dass C++
Java (ich lass das .NET jetzt mal immer weg, ist ja sehr ähnlich) das
Wasser reichen kann, dann lies es nochmal

Gruss,

Stefan

Artchi

Das Problem ist, du kannst nicht einfach in einem C++ Forum auftauchen, und einen C++-ist-nicht-geeignet-Beitrag schreiben. Da mußt du verständlicherweise mit Gegenwind rechnen.

Hardwarenahe Programmierung: also ich programmiere nun ca. 6 Jahre C++, und ich habe noch nie in C++ hardwarenah programmiert. Außer Pointer hin und her geschoben. Gerade C++ ist geeignet um die Hardware zu verstecken. Ich habe auch noch nie jemanden gesehen, der für Netzwerk-Programmierung direkt auf seine Ethernetkarte gegriffen hat (wird auf Windows z.B. eh nicht gehen). Ich kann nur sagen, ich benutze dann fertige Socketklassen, die sogar platformunabhängig sind.

GC in C und C++: was heißt nicht optimal wie in Java oder .NET? Mono, DotGNU und (ganz wichtig!) die Xerox Industriedrucker DocuPrint Serie benutzen Hans Boehms Garbage Collector. Laut Hans Boehm hält sein GC mit den kommerziellen Java-Hotspots mit, was die Performance angeht.

http://www.xerox.com/go/xrx/equipment/product_details.jsp?prodID=DP92C&Xcntry=USA&Xlang=en_US (die Dinger laufen bestimmt nicht nur 2 Stunden am Tag und werden dann resettet)

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Das was du erzählst, sind einfach nur Marketingsprüche, die natürlich Globalplayer wie SUN und IBM von sich geben. Das machen die natürlich, um ihre Java Produkte zu verkaufen. Die Firma eines Kollegen von mir ist jetzt SUN Partner geworden, und entsprechend gab es auch eine Präsentation von SUN im Hause der neuen Partnerfirma. Die Herren vom Marketing sind ein paar Mal ins Stottern geraten, als ihnen ein paar kritische Fragen bzw. Java und der Strategie gestellt wurde. Denn ausnahmsweise sassen im Publikum nicht nur Manager und Chefs meines Kollegen, sondern auch er selbst. Die von SUN haben einem das blaue vom Himmel erzählt, wie toll und schnell und billig alles mit Java-Technik erzählt. Mein Kollege hat aber dann mal vom alltäglichen Leben eines Java-Coders erzählt, natürlich als provokative Fragen. Die von SUN haben ganz schön geschwitzt. Die Chefs meines Kollegen wären natürlich nie auf sowas gekommen, weil sie das natürlich glauben müssen, was man ihnen erzählt. (sind ja keine Entwickler)

Artchi

nixregistered schrieb:

Sorry, aber das ist quatsch. Lies Dir mal Beispielsweise
http://atlas.web.cern.ch/Atlas/GROUPS/SOFTWARE/OO/tools/java/misc/ACritiqueOfC++.pdf durch. Und wenn Du danach noch immer davon überzeug bist, dass C++
Java (ich lass das .NET jetzt mal immer weg, ist ja sehr ähnlich) das
Wasser reichen kann, dann lies es nochmal

Das Dokument ist von 1996!!! Hallo? C++, die Tools und Libraries haben sich seit 1996 nicht weiter entwickelt, oder wie? Wir haben 2006, zeig mir mal ein aktuelles Dokument. 1996 war gerade mal Windows als 32bit Version auf den Markt gekommen.

Das ich hier mit Gegenwind rechnen muss ist mir schon klar - das ist ja
auch das shcöne an sonem Forum, man bekommt ein Problem aus vielen Blickwinkeln
betrachtet - je nach Forum eben auch leicht gefärbt.

Was ich so nicht hinehmen kann, ist die Behauptung nur Marketinggeblubber
wiederzugeben. Nach 6 Jahren Erfahrung (nach dem Diplom, die C-unter-Unix-
Studentenhackerzeit lass ich mal aussen vor, da war ich noch jung und dumm
mit Java und C++ (4 Jahre Java, 2 C++) kann ich glaube ich schon selbst
vergleichen.

Marketinggeblubber ist wohl eher, was Hans Böhm da von sich gibt - denn sobald
gegen etwas gelinkt wird, dass nicht mit seinem GC gebaut wurde, ist das Ding
praktisch nutzlos. Das auch SUN und Konsorten blubbern ist eh klar -
welche Firma macht das nicht - das macht das Produkt nicht schlechter. Das
Beispiel mit den Sockets ist speziell schlecht gewählt, denn
Plattformunabhängigkeit erreicht man nur mit a) einer Milliarde ifdefs oder
b) einer weiteren Abstraktionsebene wie wxwindows etc. Winsock kompiliert
unter Linux jedenfalls nicht so ohne weiteres

Zum Dokument von 96 - klar hat sich was weiterentwickelt, aber wenn Du
es _lesen_ würdest, dann dürfte speziell Dir mit deiner C++ Erfahrung
auffallen, dass die Kritik eben immer noch zutrifft.

Deine Meinung und das Forum hier in allen Ehren - ich hab
hier schon ne Menge toller Infos gefunden - aber schau doch auch mal
über den Tellerand hinaus. Ich kenne niemanden, der von Java nach C++ zurück
wollte, aber ne Menge die von C++ wieder zu Java wollten. Und für
den Einsatzbereich AppServer halte ich Java eben aus den angesprochenen
Gründen für geeigneter. Das C++ für andere Sachen seine Berechtigung hat - keine Frage!

Stefan

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