Anmelden

View Full Version : Java



Seiten : 1 [2]

RobertPic
17-07-08, 20:11
Nunja, Java als plattform-neutral zu bezeichnen halte ich für ein Gerücht.
Es gibt nun doch zu viele Implementierungsabhängigkeiten.


Das halte ich wiederum für ein Gerücht. Die i5 ist zwar wirklich die einzige Javaimplementation mit Abstrichen (Desktop-GUI) aber das wars dann schon auch.

Ich habe schon allerhand auf der i5 installiert bzw. gestestet (PDF Wandler, Mail, Excelwandler, FTP, Drucker auf Cups/IPP, Ajax-Webanwendungen, Javadatenbanken) und hatte dabei keine Probleme.

Vielfach rennen Teile meines Javacodes auf der AS/400, Windows und Linux.



Was den seltenen Fall von Java auf der AS/400 angeht, so meine ich damit kommerzielle Applikationen.

Das kommt wohl darauf an, ob man auf die kleinen oder großen Kunden schaut. Mit der Verbreitung von Java bei SAP, wird der Java-Applikationsserver (bei den SAP-Kunden) stärker zum Einsatz kommen.

Wenn ich nur aktuelle Software berücksichtige, könnte ich genauso behaupten: Native, neuere kommerzielle Applikationen (Tools abgesehen) sind auch ein seltener Fall auf der AS/400 ...

Auch von der IBM wird umgestellt: Der Webquery ist bereits in Java (auf der i5), der Navigator soll's noch werden.



... sehe ich kein Problem, C++ und Delphi Kenntnisse sind vorhanden. Ich bin heil froh, wenn ich von dem Cobol/RPG ... weg bin.

Mit dieser Einstellung und den Vorkenntnissen sollte der Javaumsteig kein Problem sein. Mit Objektorientierung hast da dann ja schon zu tun gehabt, auch mit den vielen Details, mit welchen man sich, herumschlagen muss (im Gegensatz zur GreenScreen Entwicklung).

Um nicht allzuviel von diesen Details (z.B. Datenbankquelle laut Config öffnen, Verbindung holen, SQL-Befehle absetzen, ResultSet mappen..) selber zu machen, verwendet man im Normfall ein oder mehrere Frameworks. Das bringt mich gleich zu deiner nächsten Frage:



Das einzige was ich zur Zeit halt nicht weis ist welche "Pakete" im Java was taugen, bzw. von welchen man lieber die Finger lassen sollte. Deshalb suche ich hier tips.

Ein einzelnes Paket (z.B. XML-Parser, Logger) ist noch nicht das Problem. Schlimmer ist schon die Framework/Technologieauswahl:
bei der Darstellung:
JSP, JavaServerFaces, Ajax-Komponenten

Persitenz:
Hibernate, iBatis, EJB3 vom Applikationsserver

Allgemein:
J2EE oder Spring

Wenn ihr das in Auftrag gegeben habt, wurde euch diese Entscheidung u.U. schon abgenommen.

Während der Einstieg in Java noch recht einfach (wenn man schon objektorientiert gearbeitet hat) ist, kann der Einstieg in ein Framework "ausgeben".

Den Anforderungen entnehme ich, dass hier wahrschein mit J2EE gearbeitet wird. Ich bin da mehr ein Fan von J2EE-light = Spring + Hibernate.

Aber die Vor- und Nachteile einzelner Frameworks würden diesen Rahmen hier sprengen.

Auch um den WAS (Webshpere Application Server) habe ich einen Bogen gemacht. Da ziehe ich doch 2 geclusterte Tomcat's (oder JBOSS) auf LinuxServern vor. Die Datenbank und die alten Teile der Geschäftslogik (via stored Procedure) liegen auf der AS/400.

Die vergleichbare CPU/Speicherleistung auf der AS/400 dürfte wahrscheinlich das 10-20 fache von x86 Hardware kosten. Die Kosten sind wohl der Hauptgrund, die AS/400 nicht als optimale Java(Server)plattform zu bezeichnen. Wenn die Kosten nicht das Thema sind, erhält man eine stabile 32 oder 64Bit Umgebung und braucht sich nicht mit anderen Plaattformen bzw. Clustern herumschlagen.


/Robert

BenderD
20-07-08, 09:54
Hallo,

WAS 4.0 := WebSphere Application Server

hier sollte man auf standardisiertes Deployment Wert legen (WAR oder EAR File) und festschreiben, dass die Applikation auf der Referenz Implementierung (früher mal Tomcat/JBoss heute SUN Glasfish Nachfolger) laufen muss

MQ Series := IBM proprietäre Komponenten Architektur aus der Mainframe Welt, arbeitet mit asynchronen Nachrichten

würde ich in einer jetzt noch zu entwickelnden Anwendung nicht verwenden, hier werden Altlasten neu geschrieben. Da gibt es CORBA und im Java Umfeld EJBs. Zumindest würde ich hier genausestens hinterfragen wofür das gebraucht wird (vielleicht gibt es da bereits Komponenten?)

JMS := Java Messages Services, arbeitet mit asynchronen Nachrichten

riecht nach Java Schnitstelle zu MQ Series, was mich stutzig macht ist, dass es explizit benannt wird; in der aktuellen J2EE gehört das zum Standard mit hinzu.

Bei zu verwendenden Paketen sollte man immer darauf achten, dass sie im Java Mainstream verwendet werden, damit ist gute Qualität und vor allem Verfügbarkeit von Unterstützung sicher gestellt.

Was das externe erstellen und anschließende übernehmen angeht: das kann gut funktionieren, wenn die erstellte Anwendung konsequent Java Standards folgt und geht sicher schief, wenn die Qualität der fremd erstellten Anwendung nicht so toll ist. Ich würde bei dieser Perspektive empfehlen von Anfang an selber mitzumischen und sich dann Schwerpunktmäßig mit den Punkten Design und Java Standards beschäftigen.

Was die AS/400 als Java Plattform und die Austauschbarkeit angeht, hat Robert das wesentliche ausgeführt. Ergänzend von mir noch der Aspekt, dass der Mainstream in Qualität, Servce und Performance im Vorteil ist. Für kleinere Applikationen rangiert dann Windows und Linux weit vor der AS/400 und wenn es um reges Geschäft geht, dann AIX, SUN und mit Abstrichen HP und Linux.

D*B

Xanas
25-07-08, 10:09
So, herzlichen dank schon mal für die ausführlichen Antworten. Dann warte ich mal das nächste Treffen ab.