C++ Application-Server - Alternative zu EJBs

Ich bin auf der Suche nach einem guten Application-Server. Ich befinde mich gerade in der Recherchephase für ein mögliches Diplomarbeits Thema. Der Einsatz von J2EE Application Servern boomt. Die ehemaligen Großen im CORBA Bereich wie Bea, IBM oder Sun bauen nur noch Java basierte Application Server.

Der gesuchte C++ Application-Server sollte folgendes können:
- CORBA IIOP
- Webserver
- Caching
- Security-Management

Im Prinzip sollte dieser vergleichbar mit gängigen J2EE Application-Servern sein.

Meine recherche hat bisher leider nur folgende Systeme ergeben:
- http://zild.org/index.csp
- selber schreiben auf Basis von TAO

TAO scheint sogar sehr gut zu sein, dafür ist das aber mit einem enormen Aufwand verbunden.

Spielen in der Industrie(<=Mittelstand) nur noch J2EE konforme Application eine Rolle? Auf wikipedia konnte ich eine interessante Matrix(
http://en.wikipedia.org/wiki/Matrix_of_Application_Servers ) finden. Die zeigt aber nur, dass alle großen der Branche J2EE befürworten. Meine letzte Hoffnung war noch SAP die bei R3 C++ einsetzten, nach einer Recherche konnte ich bisher jedoch auch nur herausfinden das C++ seit NetWeaver keine Rolle mehr spielt.

Ich bin aber sicher das ich doch etwas übersehen habe. Welcher ist das?

Artchi

Es ist leider tatsächlich so, das alle Firmen praktisch kein CORBA mehr supporten. J2EE bzw. jetzt JEE ist nur noch als Platform ein Thema, EJBs sind eigentlich auch schon fast out. SUN versucht sich jetzt noch mit EJB3.0 zu retten, wenn das scheitert, ist EJB wohl gestorben. (abgesehen von Altanwendungen) Denn EJB ist einfach viel zu kompliziert und keiner mag wirklich EJB freiwillig machen. Wir haben EJB in unserem aktuellen Projekt einfach nicht eingesetzt. Denn die EJB2.1-Spezifikation hat mittlerweile einen größeren Umfang als die Verfassung der EU! (eine Aussage des ix-Magazins)

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.

Vorteil von WebServices: Sprachunabhängig! D.h. du kannst dir VisualC++ 2003 (oder neuer) schnappen und in C++ einen WebService bauen. Ein Hello-World!-WebService ist mit VC++2003 in ein paar Sekunden zusammen geklickt und ab gehts auf dem IIS (MS Internet Information Server).

Von Apache.org gibts AXIS-C++, eine WebService-Implementierung mit einem Mini-WebService-Server. Kannste mit 5 C++-Zeilen einen WebService coden und laufen lassen.
http://ws.apache.org/axis/

Wie gesagt, WebServices sind zur Zeit hipp. JEE-Server wird zwar von allen Herstellern angeboten, aber das ist nur das Werkzeug. Java als solches ist nur Mittel zum Zweck, hätte auch Cobol sein können.

Achja, TAO wird von Siemens Medical und SAP produktiv eingesetzt, aber halt nur in ihren Enduserprodukten. Also nicht in Produkten für Entwickler. TAO ist also sehr wohl zu gebrauchen. Ob es heute für neue Projekte Sinn macht und vorallem, ob es einfach zu erlernen ist, ist eine andere Geschichte.

Noch was zum C++ auf Servern: die ATL (Active Template Library) von MS im VisualC++ unterstützt es, das man C++ Applikationen auf dem IIS deployed (auch unterbrechungsfrei on-the-fly).

Noch was: es hat zwar nichts mit Applikationservern zu tun, aber es gibt mittlerweile eine sehr mächtige und doch einfache C++-Library für WebAnwendungen, die sogar AJAX macht, ohne das sich der C++-Coder darum kümmern muß: http://witty.sourceforge.net
Aber daran sieht man, das C++ in Sachen Netzwerk und Web noch oder besser gesagt wieder eine Rolle spielt.

rüdiger

ACE

Artchi

ACE -> TAO

Nichts neues für den Fragesteller, denke ich.

HumeSikkins

Hallo,
jemand eine Ahnung, wie weit ICE mittlerweile ist?
Und wie sieht es mit CCM (Corba Component Model) aus? Als ich mich das letzte Mal damit beschäftigt habe, gab es noch mehr Spezifikationen als tatsächliche Produkte (Qedo z.B. hatte mehr Features auf der Todo-Liste, als auf der Already-Done-Liste)

C++ macht im Appserver nicht den geringsten Sinn - dort sind
Sprachen wie Java/C# schon deshalb besser, weil sich Server-Anwendungen
sehr gut mit JIT/HotSpot Technologien beschleunigen lassen - die
lange Startup-Zeit ist da ziemlich egal. Auserdem soll eine kaputte
Komponente ja nicht gleich den AppServer abschiessen. Und zu
guter letzt ist das Deployment mit Reflection/Runtime-Class-loading usw
mit Java/C# einfach wesentlich sicherer zu bewerkstelligen. Ist also nicht
nur Politik, sondern macht auch technisch Sinn!

Gruss,

Stefan

Artchi

Ja ja, das führen die Java/C#-Leute immer gerne als Argument an. Aber lass mal die Profis (wie Siemens Medical, Alcatel usw.) über Sinn und Unsinn von C++ im Serverbereich entscheiden.

Ich glaube nicht, das Siemens Medical im hochsensiblen und lebenswichtigen Bereich, wie die Medizin, eine angeblich unsichere Technologie bevorzugt. Alcatel benutzt auch für ihre Telekommunikations-Technik auch TAO und ACE, und da kommt es auch auf Hochverfügbarkeit an.

Und seit wann schiesst eine C++-Komponente einen ganzen Server ab, wenn jedes vernünftige Server-OS einen Speicherschutz hat?

Das Deployment funktioniert auch mit C++ reibungslos, das macht der IIS mit ATL-Serverkomponenten sehr gut vor.

Artchi schrieb:

Ja ja, das führen die Java/C#-Leute immer gerne als Argument an. Aber lass mal die Profis (wie Siemens Medical, Alcatel usw.) über Sinn und Unsinn von C++ im Serverbereich entscheiden.

Diese "Profis" haben zum Teil andere (durchaus wichtige) Gründe wie
bereits bestehende Code-Basis, etc. Und IBM/BEA/Oracle/SAP/Jboss/... sind
ja nun auch keine Anfänger. Im Serverbereich generell mag es ja
auch Anwendungen geben, die sich gut in C++ realisieren lassen, nur
ging es hier ja um AppServer - und die typischen Aufgaben für eben solche
sind nunmal optimal mit Java/.NET/<insert_next_Intermediate_Code_Language_here>
zu lösen.

Artchi schrieb:

Ich glaube nicht, das Siemens Medical im hochsensiblen und lebenswichtigen Bereich, wie die Medizin, eine angeblich unsichere Technologie bevorzugt. Alcatel benutzt auch für ihre Telekommunikations-Technik auch TAO und ACE, und da kommt es auch auf Hochverfügbarkeit an.

Wie gesagt, hier spielen sich auch andere Gründe eine Rolle. Auf jeden
Fall sind diese Anwendung _trotz_ und nicht _wegen_ C++ hochverfügbar und
sicher.

Artchi schrieb:

Und seit wann schiesst eine C++-Komponente einen ganzen Server ab, wenn jedes vernünftige Server-OS einen Speicherschutz hat?

In der Theorie hast Du da vollkommen recht - nur setzt das auch getrennte
Adressbereiche für jede im AppServer laufende Komponente voraus - schon
bei Multithreading statt Aufteilung in Prozesse geht die Rechnung nicht mehr
auf. Und wie gut der Windows-Speicherschutz funktioniert sieht man an den
(zugegbenermassen seit XP sehr viel seltener auftretenden) Bluescreens mit
anschliessendem Reboot. Bei anderen OS ist das besser, aber auch nicht
wirklich perfekt.

Artchi schrieb:

Das Deployment funktioniert auch mit C++ reibungslos, das macht der IIS mit ATL-Serverkomponenten sehr gut vor.

Hier hast Du auf jeden Fall Recht, das Beispiel hatte ich nicht bedacht.

Noch was zur Java-Welt und EJB. EJB 3.0 macht vieles besser, aber ich stimme
zu, dass der Standard zu spät kommt. Wenn nicht J2EE Spezialitäten wie
Clustering etc gebraucht werden, ist die Kombi Tomcat/Spring/Hibernate oder
ähnliches viel einfacher und bietet auch ne Menge.

Viele Grüsse,

Stefan

Artchi

nixregistered schrieb:

Wie gesagt, hier spielen sich auch andere Gründe eine Rolle. Auf jeden
Fall sind diese Anwendung _trotz_ und nicht _wegen_ C++ hochverfügbar und
sicher.

Was deine Aussagen, das Java/.NET optimaler sind ausser Kraft setzt. Also sind auch C++ Anwendungen kein Problem...

nixregistered schrieb:

In der Theorie hast Du da vollkommen recht - nur setzt das auch getrennte
Adressbereiche für jede im AppServer laufende Komponente voraus - schon
bei Multithreading statt Aufteilung in Prozesse geht die Rechnung nicht mehr
auf. Und wie gut der Windows-Speicherschutz funktioniert sieht man an den
(zugegbenermassen seit XP sehr viel seltener auftretenden) Bluescreens mit
anschliessendem Reboot. Bei anderen OS ist das besser, aber auch nicht
wirklich perfekt.

Eine VM ist in meinen Augen einfach nur eine Alternative zu einem gesamten Server-OS-System. Anstatt das ich eine Java ServerVM starte, starte ich ein UNIX-System (in Hardware) oder VMware. Anstatt mehrere JARs oder besser gesagt EARs zu starten, starte ich auf einem UNIX mehrere ausführbare Binaries, die natürlich ihren eigenen Adressraum (weil eigener Prozess) haben.

Die ganze Java/.NET Geschichte ist doch nur eine andere Abstraktionsebene, nicht mehr und nicht weniger.

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.

Artchi schrieb:

Die ganze Java/.NET Geschichte ist doch nur eine andere Abstraktionsebene, nicht mehr und nicht weniger.

Gratulation, Du hast den entscheidenden Punkt erkannt - nur nicht
wie wichtig das wirklich ist Ohne besondere Notwendigkeit
(Hardwarenahe Programmierung, etc) auf C++ zu setzten macht einfach
unötige Arbeit und verursacht unötige Risiken. Und genau _das_ macht
Java/.NET eben doch optimaler, zusätzlich zum schon angesprochenen
Performance-Gewinn durch HotSpot/JIT.

Und wie ebenfalls schon gesagt - klar bekommt man das mit C++ (teilweise)
auch hin, nur eben mit wesentlich mehr Aufwand. Eine Sprache, die nichtmal
nen Garbage-Collector hat (jaja, ich weis, es gibt sowas für C++, aber
das funktioniert eben nicht optimal) ist schon aus dem Grund für
langlaufende Anwendungen wie AppServer eben ungeeignet.

However, bevor das hier in eine Java/C++ Grundsatzdiskussion ausartet,
lassen wir die Beiträge doch so stehen, der Threadersteller kann sich
dann ja seine Meinung bilden

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).