Der längste Tag...

[eknori]

@Axel: Danke für die Info. Ich hatte zwar nach einer Referenzinstallation gefragt, allerdings schweigt man sich zu dem Thema aus.

Irgendwie werde ich das Gefühl nicht los, solten wir das dann jemals unter Tomcat stabil zum Laufen kriegen, irgendso eine Brausebirne um die Ecke kommt und uns erzählt, wir hätten das doch besser unter WebSphere realisieren sollen.

Ich hatte ja letzte Woche geschrieben,daß ich die SW unter TomCat installieren und auch laufen lassen konnte. Ich habe dazu den BigApache ( http://www.bigapache.org ) verwendet. Heute Morgen habe ich dann erst mal meinen rechner neu starten dürfen. Habe die Installation mal über das WE laufen lassen. Scheint aber ein gewaltiges Memory Leak vorhanden zu sein. CPU und Speicher waren am Anschlag. Ich habe das aber auf einen Pentium II mit 192 MB Ram und 700 MHz betrieben. denke, da muß eine andere Platform her, um da wirklich eine Aussage treffen zu können.

Aber heute soll ja "unsere kleine Serverfarm" geliefert werden. Und dann lehne ich mich  entspannt zurück und schaue nur ab und zu mal in den Raum, wo dann die SW installiert wird.  Ach ja, uns steht dann auch ein Supporter der Herstellerfirma zur Seite; telefonisch, wenn ich das Geräusch des SAPlers am Freitag richtig gedeutet habe

in diesem Sinne, eine schöne und erfolgreiche Woche. Jetzt mache ich erst einmal das erste Türchen an meinem AzWenz Calender auf.

eknori

[Axel Janssen temp]

Für mich hört sich das nach einer klassischen Unternehmensberatung an, die sich wg. Auftragsflaute im eigenen Kerngeschäft ihre Consultants in Dinge schickt, die sie nicht beherrschen.
Keine Gedanken dieses Projekt zu kapern.

Eine extrem gefährliche Konstellation.
Die Integration von Tomcat mit Apache ist nicht unbedingt trivial, funktioniert aber.

Die Tomcat/Apache Integration kannst du auch von Hand machen. Ich hab das in meinem Professional Tomcat Guide auf O'Reilly Safari Bookshelf.
Hier ist eine umsonst-Anleitung, wie man das von Hand macht:
http://www.galatea.com/flashguides/apache-tomcat-4-win32.xml

Vorschlag: Frag die Berater doch mal, welche J2EE Version von dem SAP J2EE Server unterstützt wird. J2EE1.2 oder noch schlechter bringt extreme Performance-Nachteile gegenüber J2EE1.3 (keine local interfaces von EJBs, weniger support für asynchrone Methoden: Message Driven Beans, meines Wissens keine Unterstützung für JCA).
Es ist einfach nicht einzusehen, warum man für die doch irgendwie überschaubare Kundenzahl sowiel Server braucht.  

[eknori]

erst mal Danke für den Link.

habe gerade aus den Nebenbüro eine Geräuschemmission vernommen, die sich darum drehte, daß die das so hinbekommen wollen, daß der Tomcat mit dem IIS verheiratet werden soll  
Und im nächsten Satz war dann davon die Rede, den IIS abzuschalten und den Tommi alleine laufen zu lassen...

Sag mir bitte, daß das irgendwie ein ganz gruseliges Vorhaben ist, damit ich noch rechtzeitig die netten Herren mit den "Hab-mich-lieb"- Jacken bestellen kann.

Es ist noch nicht einmal Mittag und ich bin schon wieder reif für ne Session in der Gummizelle.

Ulrich

[pd]

Da hilft nur eins:
SAP-Beraterweitwerfen!

Frag mal den Progger von dem Weihnachtsmannweitwerfen, ob du ihm ein Bild von dem Berater schicken kannst, dann kann er den Weihnachtsmann ersetzen ;-)

Patrickle

[Axel Janssen temp]

erst mal Danke für den Link.

Es ist noch nicht einmal Mittag und ich bin schon wieder reif für ne Session in der Gummizelle.

glaub mir, ich habs hier auch nicht einfach.

Tomcat hat einen internen http-Server. Dann brauchst du weder IIS noch Tomcat.
Mittlerweile ist der auch gar nicht so schlecht. In jedem Fall aber von der Performance schlechter als Apache (und sehr vermutlich besser als Domino). Da sich bei euch aber die gleichzeitigen http-Zugriffe wohl sehr im Rahmen halten, dürfte das vermutlich ausreichen. Es ist ja nicht www.kicker.de Samstags um 17.10, sondern eine Art extranet-Anwendung, wo die gleichzeitig anwesenden User weniger als 10.000 ist.  
In jedem Fall würde ich das Testen. Es gibt da Tools für Server-Last-Tests.
Tomcat auch als http-Server zu benutzen, dürfte dich von einem Problem befreien (so es performance-mässig ausreichend ist). Dieses einpluggen des Tomcat Webcontainers (=Servlet-Engine + JSP-Engine) in andere http-Server gilt als zwar möglich und stabil, aber ein bischen kompliziert zu einrichten.
Ich persönlich halte Tomcat für stabil. Btw. welche Version brauchen die Herren eigentlich. Sind die sich darüber im klaren?

Tomcat 3.2 unterstützt (JSP1.1, Servlet2.2) isMemberOf J2EE1.2
Tomcat 4.0 unterstüzt (JSP1.2, Servlet2.3) isMemberOf J2EE1.3
Tomcat 5.0 unterstützt(JSP1.3, Servlet2.4) is MemberOf J2EE1.4

Die wohl beste Anleitung zur tomcat-standalone installation findest du hier: http://www.moreservlets.com/Using-Tomcat-4.html

Für tomcat3.2 ist es genau gleich, nur die Umgebungs-Variable CATALINA_HOME heisst dann TOMCAT_HOME.

viel spass noch
 
Kommando Ashik Uzzaman

[eknori]

@Axel: Noch einmal Danke für die wirklich hervoragende Installationsanleitung.

Die Installation habe ich nun hinbekommen; die SW läuft ( auf meiner Workstation   )
Die Sapler saßen um 17:15 immer nocj mit rauchenden Köpfen vor dem Server.

Ich glaube, ich zeige denen dann morgen mal, was ich gemacht habe.
Nach der Anforderungsmatrix war die einzige richtige Kombination ein

Tomcat 3.2 und Java SDK 1.4.x ( warum ich allerdings das SDK brauche ist mir noch nicht klar; da auf dem Server ja nicht entwickelt werden soll )

Die Software habe ich dann gem. Anleitung de Herstellers instaliert und die Parameter für die SQL Anbindung eingegeben. Dann noch schnell die web.xml der Appl. entsprechen angepasst und auch die server.xml desTomcat.

Tomcat starten, Appl im Browser aufrufen... und siehe   da, et lüppt  

Für die ganze Installation braucht man nach HerstellerAngeben ca 2 Manntage ! Realistisch ist das in etwas 3 Stunden zu schaffen, wenn man den Download des Katers und des SEK ( äh sorry, SDK ) mit einbezieht.

Okay, ich habe jetztnicht hunderte von Screenshots gemacht und jeden Furz beschrieben; aber das kriege ich jetz sogar blind mit Krückstock hin...

Nochmals herzlichen Dank an alle angeschlossenen Mitglieder an den Geräten zuhause für euren seelischen Beistand und insbesondere Axel für die wie immer kompetente Hilfestellung in Sachen JAVA, J2EE und den ganzen Rest.

Und was das mit den 4 Servern auf sich hat, erkläre ich euch nach der nächsten Maus...

Gruß

Ulrich

[koehlerbv]

Tjoa, da hamma jetzt den "inneren Vorbeimarsch" mal wieder ;-) Das ändert nicht immer was an der realen Situation, hilft aber offensichtlich nicht nur mir ;-) über derartige Probleme mit überbezahlten beschlipsten Nieten-in-Nagelstreifen hinwegzukommen.

Herzlichen Glückwunsch jedenfalls, Ulrich - und ich habe da sehr mitgefühlt, und es tat mir sehr leid, nicht so wie AxelJavaMensch ;-) mithelfen zu können.

Bernhard

[Axel Janssen temp]

Hi Ulrich,

@Axel: Noch einmal Danke für die wirklich hervoragende Installationsanleitung.

... ist die beste auf diesem Planeten und um ehrlich zu sein, ist es auch nicht so schwierig.  

Tomcat 3.2 und Java SDK 1.4.x ( warum ich allerdings das SDK brauche ist mir noch nicht klar; da auf dem Server ja nicht entwickelt werden soll )

Gute Frage. Hab schon angefangen auf der Ranch zu posten bis ich das fand: http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg104766.html
Es hat was mit den startup-Skripten zu tun, die auf die filestruktur des JSDK ausgerichtet ist. Man könnte dieses Skript (in deinem Fall wohl startup.bat) anpassen. Das ist aber unnötige Arbeit.
 

Die Software habe ich dann gem. Anleitung de Herstellers instaliert und die Parameter für die SQL Anbindung eingegeben. Dann noch schnell die web.xml der Appl. entsprechen angepasst und auch die server.xml desTomcat.

Das hört sich gut an.

Gruß Axel

[eknori]

so, jetzt noch schnell zu den 4 Servern.

Das ganze system sieht folgendermaßen aus:

1 Stück SW, um den TeileKatalog ( z.B. Conrad ) einzulesen ( 1. Server )
die Daten werden dann in einer SQL DB gespeichert ( 2. Server )
1 Stück SW ( 3. Server ), um aus der ersten Datenbank die Positionen in eine weitere Datenbank zu schaufeln ( 4. Server ) , die dann wiederum mit dem SAP verknipelt ist.

nun ja, man wird sehen, inwieweit das noch eigedampft werden kann; zumindest sind die Rechnerchen heute nicht wie angekündigt angeliefert worden. Da besteht noch Hoffnung, daß bei dr Anlieferung ebensoviel schief geht, wie bei der Installation der SW.
Und wenn ich viiiieeeel Glück habe, haben alle beteiligten SW Produkte zu Weihnachten eine schuckeliges Zuhause auf einer MehrprozessorMAschine mit genügend Dampf und RAM.

[Axel Janssen temp]

Und wenn ich viiiieeeel Glück habe, haben alle beteiligten SW Produkte zu Weihnachten eine schuckeliges Zuhause auf einer MehrprozessorMAschine mit genügend Dampf und RAM.

... auf der dann zweifelhafte Software eines offenbar vom Hersteller selbst nicht mehr ernstgenommenen EJB-Containers nach einer veralteten Spezifikation läuft.  
Hell. J2EE1.3 hat mit local Interfaces für EJBs gerade einen wichtigen Schritt Richtung Pragmatismus genommen. Es macht einfach keinen Sinn wenn jeder call remot....
Der Schritt bei der EJB-spec, der zwischen dieser J2EE-Version und der anderen Lösung, die jeder normahle J2EE Server seit spätestens Anfang 2002 erfüllt war der Sprung EJB1.2 --> EJB2.0

viiiiel zu langer link wird vernünftig verhackstückelt
hat wirklich wichtigste Auswirkungen auf die Performance, v.a. die neuen local interfaces.

[eknori]

OK, kannst du das bitte noch einmal so erklären, daß auch ich das als JAVA Dau verstehe ??.
Du meinst frei übersetzt, das ist ja schön und gut, das es jetzt endlich läuft, aber so eine schei..sse kommt MIR nicht auf einen Kundenserver ! Ist es das, was du ausdrücken wolltest ??  
ch würde das gerne auch meinem OberGuru ( Ssseffe ) erklären können.

[Axel Janssen temp]

in dem oben eingefügten Link wird das ein bischen, aber nicht wirklich erläutert. EJB ist schon ziemlich spezial.
Ich hab mal selbstgeschriebene Websphere-Schulungen gegeben (damals übrigens wohl eine Überforderung). Model View Controller ging noch, aber wie ich angefange habe die Funktionsweise von EJBs zu erklären, hätte ich am besten vorher jedem Beteiligten 5 Aspirin oder 0.2 Valium (die pennten eh schon halb) gegeben.

<vereinfachend_gesprochen>
Eine J2EE app ist schichtenmässig aufgebaut.
Der Web/Frontend-Layer leitet die User-Aktionen an
den Business Layer weiter, der wiederum
mit dem Entity-Layer kommuniziert (eine Art OO-Sicht der RDBMS).

Problem ist, dass dies alles remote-calls sind, d.h. keine by-reference-calls, sondern die Parameter der Methodenaufrufe werden by value erst in ein rmi-Corba (heisst anders,schau jetzt nich nach) Protokoll serialisiert und beim aufgerufenen Objekt wieder deserialisiert (was einfach Ressourcen verbraucht).
In EJB2.0 können die Methodenaufrufe zwischen Bussiness-Layer (EJB Session Beans) und Entity-Layer(EJB-Entity Beans) by reference sein (was wesentlich schneller ist und die sich daraus ergebenen Probleme hätte man angeblich von CORBA schon wissen müssen)
</vereinfachend_gesprochen>

Auch die in J2EE1.3 eingeführten Java Connector Architecture und Message Driven Beans können für eine solche SAP-Anbindung mit langen Transaktionen über den Datenbestand des SAP Systems eine gute Sache sein.

[eknori]

das heißt dann laienhaft ausgedrückt: Die SW entspricht nicht mehr dem heutigen Stand der Technik, korrrrekt ?

[Axel Janssen temp]

sage ich doch die ganze Zeit <big_grin_smiley/>
(bei mir funktionieren die smileyes momentan nicht).
oder wie mein deutsch-russischer Kollege Igor sagen würde auf jedem fall.

Spezifikationsmässig ist das Websphere4. Der Übergang zu J2EE1.3 wurde Ende2001/2002 vollzogen (und J2EE ist eine junge Technologie).
Heute ist J2EE1.4 bei manchen Herstellern fertig. Da wäre man aber ein bischen early adopter.
Die KGBM Leute können auch nicht damit argumentieren, dass J2EE1.3 nicht stabil wäre (wie gesagt 2002 war der Wechsel).

V.a. finde ich bedenklich, dass SAP offenbar nun Websphere empfiehlt, man von diesem Server nix in newsgroups hört und er offenbar keinen upgrade auf J2EE1.3 spendiert bekommen hat, zumal alle sich einig sind, dass J2EE1.3 wirklich wichtige Neuerungen gerade für die immer noch nicht so super ausgereifte Idee der EJBs brachte.

Wenn das seine Aufgabe erfüllt, soll das egal sein. Einen solchen Server für einen weiteren Ausbau der J2EE Infrastruktur zu nehmen halte ich für keine gute Idee.

SAP scheint jetzt auf einen netweaver zu bauen (keine Ahnung ob das eine IDE ist, eine Zwischenschicht oder whatever). Jedenfalls fällt da immer wieder der Name Websphere. Such mal auf der SAP.de nach websphere.
Vielleicht solltest du Rücksprache mit eurem Ansprechpartner bei SAP halten, falls ihr einen habt.

Gruß Axel

[eknori]

Danke, das werde ich dann morgen mal so verkaufen  

[Axel Janssen temp]

such einfach nach dem Server, den die euch anbieten auf der SAP Seite.
Ich meine, ich bin wirklich kein Experte für die J2EE Strategie von SAP, aber es sieht echt merkwürdig aus.

[eknori]

nicht das wir jetzt aneinander vorbei reden:

dem J2EE 6.10 von SAP setzen wir ja nun nicht ein, sondern den TomCat 3.2

[Axel Janssen temp]

nicht das wir jetzt aneinander vorbei reden:

dem J2EE 6.10 von SAP setzen wir ja nun nicht ein, sondern den TomCat 3.2

nur Tomcat3.2  
Das ist ein dramatischer Architekturwechsel.

Dann kann es ja nicht so mega-complex sein. Wieviel kostet das insgesamt ?
Tomcat3.2 ist auf jeden Fall auch veraltet. Seit 2001 gibt es Tomcat4 mit einer völlig neuen und besseren Architektur.

Wie ist dann die Anwendung programmiert?
Frag sie, ob sie standardisierte, kostensparende, erweiterbare, von Experten programmierte Frameworks wie Struts, WebWorks2 oder das (hähä) Spring-Framework verwenden.

Zugriffe auf Datenbanken und das im Web darzustellen ist ein ziemlicher Standard-Task. Ich kann das mal über die Weihnachtsferien durchexerzieren.