Java Web Frameworks

[flaite]

Fing alles mal mit Struts an. Das ist jetzt aber überholt. Es gibt ein paar neue und nicht mehr ganz so neue.
Ich werde hier über JSF, wicket und struts2 berichten. Die wirken am vielversprechendsten.
Alle haben ihre Stärken und Schwächen. Man muß wohl pro Projekt entscheiden.
Ich prüf die alle als Webfrontends für mein Börsenspiel.

1. JSF (präferiere apache.jakarta myfaces und facelets)
+ gute Dokumentation, gute Bücher, viele user generated content im Internet, alles gut googlebar. 
+ Komponentenmarkt, wobei das alles nicht so einfach ist. Oracle hat apache seine adf-Komponenten geschenkt. Das sind zusätzliche Sachen, die man myFaces beigeben kann. Unter apache-Flagge heissen diese Zusatzkomponenten Trinidad. Soll sehr ausgereift sein. Ich halte das aber bis auf weiteres für nicht einfach. Gibt auch ajax-Komponenten (z.B. IceFaces). Man braucht da gar nicht javaScript programmieren. Die Ajax-Magic ist in den Komponenten. Jedoch kann die Integration teilweise recht komplex werden. Hab das sowieso noch gar nicht ausprobiert und bin eher mit den Basis-Komponenten unterwegs. Und ich hatte z.B. mit der Integration von facelets mit ein paar Tomahawk-Komponenten bei gegebenen Zeitrahmen für mich unlösbare Probleme.
+ irgendwie recht übersichtlich. Man definiert in einer faces-config.xml Navigationspfade, Validierer, Konvertierer, "Aktionen" (heissen Backing-Beans). Zum Zurechtfinden ist das besser als jede Doku.
+ Facelets hat einen absoluten brauchbaren Templating-Mechanismus. Man kann ein Template für direkt mehrere Seiten definieren. Z.B: Links ist der Navigationsbereich. Oben ein Header. Unten ein Footer und in der Mitte der Hauptbereich. Oder beliebig anders. Spezialisierte Html Designer können damit klarkommen.
+ wie überall in Java gute Unterstützung für Internationalisierung und Lokalisierung.
+ wirklich gute Integration mit Spring.
+ JBoss hat ein eigenes sehr interessantes Framework namens SEAM, um JSF mit EJB3 oder normalen Backend-POJOS zu verbinden.
+ Gibt einen guten Toolsupport. Ich mach aber erstmal ohne. Oft verwirrt das nämlich eher, wenn man sich noch nicht so gut mit einer Technologie auskennt.
+ JSF wird eine gute Zukunft vorausgesagt. Wohl v.a. auch wegen der Übersichtlichkeit. Das verspricht für Anwenderorganisationen leichte Erweiterbarkeit, Wartung, etc. und dem Komponentenmarkt, wobei auf diesem Markt vieles sowieso openSource ist.
+ oft sind die Fehlermeldungen ziemlich klar. Vor allem mit Facelets.

- wohl nicht geeignet für Seiten mit sehr viel Traffic. Es wird da so einiges in der Http-Session abgelegt und das skalliert dann zwangsläufig nicht so gut bei steigenden Anwenderpopulationen.
- Manche Sachen sind einfach kurios. Wenn man z.B. nicht ein paar Workarounds benutzt, stimmt die URL im Browser nicht mit der dargestellten Seite überein. Manche JSF-aficionados finden das nicht so schlimm. Ich schon. Gibt zwar workarounds, mir sind aber deren Nachteile noch nicht zur Gänze klar.
Oder sowas hier: http://sfjsf.blogspot.com/2006/03/usings-sets-with-uidata.html (hat mich 2 Stunden gekostet).
- Es gibt ein paar Kompatibilitäts-gotchas zwischen den benutzten Technologien, die mich ganz schön ins Schwitzen bringen. Google hilft oft.
- Backbutton ist problematisch. Das ist leider oft so. SEAM behauptet, es gelöst zu haben.
- Gibt zwar eine Menge Komponenten, die definitiv einiges leisten. Bisher hat das ausgereicht. Wenn nicht, muß man wohl selber tief da reingehen. Eine JSF-Komponente hat 7 Lebenszyklus-Schritte pro Aufruf. Das ist sicher nicht einfach.
- Anfänger sollten das imho nicht als erstes Java Web Framework nehmen. Default-mässig ist da JSP als Basis für die View. Das war mir - wie sehr sehr vielen - zu frustrierend. Zukünftige Versionen sollen JSF freundlicher werden. Wenn man sich mit Model View Controller und Schichten-Architekturen nicht so auskennt, kann es leicht zu einem Chaos-Design verleiten, auf das man nach einer Woche keinen Bock mehr hat.

[flaite]

Java Server Faces (JSF) ist nix, wovor man Angst zu haben braucht. Der Test für meinen Börsenhandelsplatz verläuft soweit überzeugend. Gut. Es gab Momente, in denen ich eine Menge Wasser geschluckt habe. Mittels google konnte ich aber immer eine Lösung finden. JSF ist einfach zu bedienen, im innern aber schon ziemlich komplex. Es mag sein, dass es Anwendungsfälle gibt, für die man tief in das Framework einsteigen muss und das wird bestimmt leicht komplex. Für die Börsenplattform reichts aber und das ist ein gutes Zeichen, weil Hello World ist das auch nicht. Ich werd den code irgendwann auf google code posten, falls jemand Interesse hat.
Eine gute Zusammenfassung einiger dunklen Gassen von JSF, denen ich auch begegnet bin, findet sich hier: http://typo.ars-subtilior.com/articles/tag/jsf
Die beiden guten Bücher sind oben genannt.

Integration mit Backendframeworks
Spring als Backendframework ist gut integrierbar. JSF arbeitet in seinen Backing Beans mit dem vom Spring massiv popularisierten dependency injection. Spring integriert JSF auch von sich aus so gut, dass
a) Spring Beans in Backing Beans deklarativ dependency injected werden können! und
b) Spring Beans sogar direkt als Backing Beans deklariert werden können.
Auch EJB3 lässt sich offenbar gut integrieren, wobei ich das noch nicht ausprobiert habe. Für JBoss gibts sogar mit SEAM ein extra Framework zur Integration von JSF mit EJB3 oder Pojos (Plain Old Java Objects). SEAM sieht sehr vielversprechend aus und erzeugt eine Menge Interesse.

Jedenfalls hat das für mich Lust gemacht weitere, reichhaltigere JSF Komponenten Frameworks kennenzulernen (ADF Faces/Trinidad, ICEFaces oder auch sowas wie ajax4jsf).

Mit entsprechender Literatur kann imho ein Junior Java Programmierer in 4 Wochen ein absolut brauchbarer JSF Designer werden, ohne dass es in Stress ausarten muss. Bei einem Projekt sollte aber ein erfahrener Java Architekt dabei sein, der sich umfassend mit Schichtenarchitektur, dem verwendeten Server, Webentwicklung und allgemein auskennt.

Gruß Axel

[Mark³]

ich bastel gerade mit ZK rum (http://www.zkoss.org Da hat man schnell eine schicke AJAX-Webgui hingebastelt. Allerdings die Integration mit Hibernate und anderen Sachen muss man selbst übernehmen (Habe noch nie mit Hibernate gearbeitet, will aber natürlich keine DB-Zugriffsschicht selbst basteln)

Werde nochmal JBoss SEAM kurz beleuchten und dann eins dieser Dinge nehmen, um die grausame Webentwicklung in Notes loszuwerden. Ich habe zwar in Notes auch AJAX-Sachen mit Prototype und Scriptaculous gebaut, aber das ist mir echt zu unübersichtlich: Die Logik ist verstreut in js-Libs, Forms, Agents, Pages, Subforms, Passthrough-HTML, da blick ich durch meine eigenen DBs nicht mehr durch.

[flaite]

Wolltest Du nicht Spring und Hibernate machen? Seam ist hauptsächlich für die Integration von JSF mit Hibernate3.
Am wichtigsten sind aus meiner Sicht die Basics. Versteht nur vielleicht jeder was anderes drunter.
Hab leider auch bei der Java Entwicklung erlebt, wie da fröhlich losgehackert wird und ohne Archtitektur endet das in einem noch größeren Chaos als Notes-Entwicklung.
Einen realistischen Schnelleinstieg liefert das Praxisbuch "Spring & Hibernate".

Ich bin jedenfalls aktuell Anhänger eines geschichteten kontrollierten POJO-mit-Spring Ansatz mit  JSF als Frontend und Hibernate für Datenbank Zugriffe. The greater picture.
Dabei kann ich JSF mit Struts2 oder whatever austauschen.
Dabei kann ich Hibernate mit IBatis SQL Maps oder Spring JDBC austauschen.
Wenn es nötig ist, kann ich zumindest in meiner Lieblings-DB Posgres problemlos stored procedures schreiben. Wenn ich das in Posgres beherrsche, ist der Schritt zu Oracle oder DB2 stored procedures klein. 
Aus meiner Praxis haben sich die folgenden Dinge als wichtig herausgestellt (viel wichtiger als Ajax Features oder das zufällig verwendete Framework):
- Schichtenarchitektur: Web-Schicht -> Service Schicht -> DAO Schicht und ein Domain Model mit gettern und settern, obwohl das überhaupt nicht OO ist.
- die benutzte Datenbank gut beherrschen.
- das Webframework bis zum best practice level beherrschen. (z.Zt. JSF und da hab ich am Anfang vieles nicht richtig verstanden).
- Integrations- und Unittests für alle Schichten. In Spring gibts für Integrationstests interessante Junit-Erweiterungen.
- Spring in einem hohen Grade verstehen (inkl. AOP Basics, verschiedene Bean Wiring Methoden, Aufteilung der application.xml auf verschiedene xml Dateien im Namen der Übersichtlichkeit, Bean Factories, Transactions, Spring im Web).
- Hibernate in einem hohen Grade verstehen (das ist das schwierigste: Inkl. Fetching Strategien, 1-n, n-1, m-n mappings, lazy loading, optimistic und pessimistic locking, caching, business keys in equals/hackcode Methoden für die Business Objekte).

Das ist ein völlig anderes Entwicklungs-Modell als mit Lotus Notes, aber sehr effektiv.
Diese Plattformen werden sehr viel benutzt und sind meiner Meinung nach eher noch bug-freier als Lotus Domino. Das Problem sitzt damit eher vor dem Bildschirm und v.a. die Hibernate Foren sind voll von Entwicklern, die immer die gleichen Fehler machen. Das sagt natürlich auch, dass es relativ einfach ist, in die Fallen zu tappsen.

Die Richtung stimmt aber. Zeigt allein schon, dass EJB3 soooo viel Hibernate und Spring ähnliche Features besitzt. Die Exit-Strategie ist also da. IBM seitig wird Websphere irgendwann auf EJB3 gehen müssen. Ich bin 2003 auf Javaranch von einem hohen IBM Websphere Architekten ziemlich massiv geflamed worden, als ich mich sehr positiv über Spring oder genauer über Rod Johnsons erstes Buch ausgesprochen habe. Unzählige negative Äusserungen von Rod Johnson über Websphere später, gibt es nun eine immer stärkere Zusammenarbeit zwischen den Websphere Classic Leuten und Spring. Viele Artikel von internen Autoren (keine extern gekauften), IBM Vortragende auf Spring.One Konferenz, Zusammenarbeit um Spring auf Websphere zu "zertifizieren".

[Mark³]

Spring und Hibernate steht auch noch auf der Liste. Momentan bin ich kurz davor, über eine ZK-GUI einen Datensatz mit Hibernate (auf MySQL) zu erzeugen. Wie immer gab es Myriaden fehlende Pfade zu irgendwelchen XML-Dateien etc aber ich nähere mich.
Einen CurrentSessionContext habe ich auch nicht, da muss ich momentan erstmal eine Session mit openSession aufmachen, alles mui komplex. Aber nun habe ich es geschafft, ein paar Datensätze anzulegen:

Code

<window title="Registration" border="normal">
        <zscript>{
            import zutritt.model.Person;
           	import util.HibernateUtil;
            import org.hibernate.Session;
            import org.hibernate.*;
                void submit() {
                
                        Person person = new Person();
       
                        person.setSmtpMail(email.value);
                        person.setFirstName(forename.value);
                        person.setLastName(surename.value);
                        person.setEmpNumber("12345678");
                        person.setCostCenter(cc.value);
                        try {
	                        Session session = HibernateUtil.getSessionFactory().openSession();
							Transaction tx = session.beginTransaction();
							session.saveOrUpdate(person);
							tx.commit();
							session.close();
							HibernateUtil.getSessionFactory().close();
                        }catch (Exception e) {
                        		e.printStackTrace();
                                alert(e.getMessage());
                        }
                }               
        }
        </zscript>
        <grid>
        <rows>	
                <row>Name : <textbox id="forename" value="Hans" /></row>
                <row>Surename : <textbox id="surename"  value="Meier" /></row>
                <row>Login Name : <textbox id="nickname" /></row>
                <row>Email: <textbox id="email" value="a@b.cd" /></row>
				<row>Costcenter : <textbox id="cc" value="DE61000327"></textbox></row>
                <row><button label="submit" onClick="submit()"/></row>
        </rows>
        </grid>
</window>

Code

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
	"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
	"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="zutritt.model">
  <class name="Person" table="PERSON">
  <id name="id" type="long" column="person_id" unsaved-value="0">
<generator class="identity"/>
</id>
        <property name="smtpMail"  column="SMTPMAIL"/>
        <property name="firstName" column="FIRST_NAME"/>
		<property name="lastName" column="LAST_NAME"/>
  		<property name="empNumber"  column="EMP_NUMBER" />
		<property name="notesMail"  column="NOTESMAIL" />
		<property name="costCenter"  column="COSTCENTER" />
  </class>
</hibernate-mapping>

[flaite]

Mark, das ist schön.
Aber diese DAO/Service Layer Geschichten sind echt nicht zum Spaß da.
Du machst ja jetzt quasi deinen Datenbankzugriff aus dem Frontend.

Bei mir sieht (als Beispiel ein Authentifizierungsfeature) so aus:

1. jsf Seite ruft Methode userReg.login in einem JSF backing bean auf (bei Klick auf "Anmelden button")

Code

<h:form id="login">
	<table class="infoTable" width="80%">
    	<tr>
    		<td class="infoTableTD" width="30%">
      			<h:outputLabel for="j_username" value="#{msg.name}"/>
     		</td>
     		<td class="infoTableTD" width="70%">
      			<t:inputText id="j_username" forceId="true" value="#{userReg.name}" required="true" size="40" maxlength="40">
      				<h:message for="j_username" styleClass="message"/>
      			</t:inputText>
	  		</td>
	 	</tr>
      	<tr>
      		<td class="infoTableTD">
      			<h:outputLabel for="j_password" value="#{msg.pwd}"/>
			</td>	
			<td class="infoTableTD">	
				<t:inputSecret id="j_password" forceId="true" value="#{userReg.pwd}" required="true" size="40" maxlength="40">
					<h:message for="j_password" styleClass="message"/>				
				</t:inputSecret>
			</td>			
		</tr>
		<tr>
			<td colspan="2" class="infoTableTD">
      			<h:commandButton value="#{msg.login}" action="#{userReg.login}"  />
			</td>
		</tr>
	</table>
</h:form>

Methode login in JSF Backing Bean, die wiederum die Methode login(String name, String pwd) in der Service Klasse userService aufruft.

Code

public String login() {
		user = userService.login(name, pwd);
		
		
		if (user == null) {

			message("j_username", "login_message_user_not_found", name); // internationalisiert
			return "failure";
			
		} else {
			context().getExternalContext().getSessionMap().put("user", user);
			setId(user.getId());
			return "success";
		}
	}

Methode userService.login(String name, String pwd), die wiederum als sagen wir wichtigste Methode userDao.findByNameAndPwd(String name, String pwd) aufruft.

Code

	public User login(String name,
			String pwd) {
		// initDeferredClose();

		User user = userDao.findByNameAndPwd(name, pwd);

		user = addStockpositionsToUser(user);
		user = addOffersOrdersToUser(user);

		return user;
	}

userDao:

Code

	/**
	 * @see de.aja.fussi.model.UserDao#findByNameAndPwd(java.lang.String, java.lang.String)
	 */
	public User findByNameAndPwd(String name, String pwd) {
		log.debug("getting user for name:" + name + "and PWD " + pwd);

		List<User> list = (List<User>) getHibernateTemplate()		
		.findByNamedQueryAndNamedParam("findUserByNameAndPwd",
						new String[] { "name", "pwd" },
						new Object[] { name, pwd });

		if (list.size() == 1) {
			return (User) list.get(0);
		} else {
			return null;
		}

	}

(der untere Teil ist zugegeben nicht so toll, weil ich nicht weiss wo ich in Spring das getUniqueObject Feature von Hibernate finde).

Sieht zuerst ein bischen nach overkill aus, bringt aber eine Menge Flexibilität und Stabilität in die Geschichte, da auch die DAO und Service Klassen alle unter Einbindung der Datenbank regressionstestbar sind.
D.h. Wenn ich da was ändere, starte ich den Test und der kann mir genau sagen, ob das noch wie erwartet funktioniert. Dabei wird die Datenbank automatisch auf einen erwünschten Zustand gebracht.
Das ganze wird mit Spring zusammengebunden. Ach ja. Die Transactions werden quasi auf einen Schlag in Spring definiert:

Code

 <bean id="transactionManager"
          class="org.springframework.orm.hibernate3.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory"/>
    </bean>

	<!-- deklarative Transaktion --> 
	<tx:advice id="txAdvice" transaction-manager="transactionManager">  
		<tx:attributes>
			<tx:method name="get*" read-only="true" propagation="REQUIRED"/> 
			<tx:method name="find*" read-only="true" propagation="REQUIRED"/> 
			<tx:method name="select*" read-only="true" propagation="REQUIRED"/> 
			<tx:method name="*" propagation="REQUIRED"/> 
		</tx:attributes>
	</tx:advice>
        <aop:config>
		<aop:pointcut id="txServiceMethodsUser" expression="execution(* de.aja.fussi.market.UserService*.*(..))"/>
		<aop:advisor advice-ref="txAdvice" pointcut-ref="txServiceMethodsUser"/>
	</aop:config>

Separation of concern:
- JSF-> Internationalisierung
- Service Layer -> Transaktionen, Aufruf der DAO Methoden, Validierung der Eingaben, Business Logic
- DAO Layer -> Hibernate Aufrufe

Die einzelnen Methoden sind übersichtlich. Jede Klasse hat klare Aufgaben (und nicht Web-Präsentation, DB-Zugriff, Transaktionen gleichzeitig).
In den Schichten gibt es keine zyklischen Abhängigkeiten.

Die JSF-Backing Beans sprechen nur die Service Klassen an, (aber nicht die DAO Klassen).
Die Service Klassen sprechen nur die DAO Klassen an (aber nicht die JSF Backing Beans)
Die DAO Klassen kennen die Klassen der beiden anderen Layer überhaupt nicht.

[flaite]

Und jetzt Testen. Ich möchte sichergehen, dass ich jederzeit prüfen will, dass die Methode login(String Name, String pwd) von UserService funktioniert.

In der Klasse UserServiceTest, die eine Spring-Klasse überschreibt, die wiederum von junit-Testcase erbt habe ich diese Methode, um die Daten der Datenbank in einen sauberen Status zu bringen:

Code

@Override
	public void onSetUp() throws Exception {
		
		jdbcTemplate = new JdbcTemplate(dataSource);
	
		JdbcHelper.cleanDatabase(jdbcTemplate);
		JdbcHelper.fillStocks(jdbcTemplate, "copa");

	}

und eine Methode, die die Funktionalität testet. Hier wird erst ein User registriert und dann per log-in geprüft, ob ein login funktioniert. Das alles ohne einen Web-Container wie Tomcat zu starten:

Code

public void testLogin() throws DataValidationException {
		User user = new User();
		String name = "axel";
		user.setName(name);
		user.setPwd("pwd");
		user.setMoney(20000.00);

		userService.registerNewUser(user);
		
		User user1 = userService.login(name, "pwd"); 
		assertEquals(user, user1);
	}

Ich kann dann auch noch Testmethoden schreiben, die prüfen wie die Anwendung reagiert, wenn eine falsche User/Passwort Kombination eingegeben wurde.

[flaite]

Wenn ich in meiner Anwendung jsf nicht mehr will und stattdessen struts2 oder zk. Ich kann das JSF Zeugs jederzeit rausschmeissen und stattdessen struts2 oder zk Zeugs schreiben, das meinen Service Layer anspricht.
Wenn ich keine Lust mehr auf Hibernate habe und stattdessen lieber ibatis-SQLmaps oder Spring-JDBC verwenden möchte, muss ich nur die DAO Schicht verändern und sicherstellen, das die Methoden gleich heissen wie früher. Das externe Interface der Klassen der DAO Schicht ist unabhängig von Hibernate.
Die Service Schicht selbst ist sowieso völlig entkoppelt von technischen Belangen wie zufällige Auswahl der verwendeten Frameworks.

[flaite]

Hi,

eigentlich meine ich was in diesen Ruby-on-Rails Werbespots 2 bis 4 thematisiert wird.
http://notepad.emaillink.de/2007/05/23/ruby-on-rails-vs-php-vs-java/

Für dieses Zusammenklumpen was nicht zusammengehört ist eigentlich jene "einfache" Plattform, die mit P anfängt und mit P aufhört berühmt. Jenes Framework, das 2003/4 sehr stark aber seitdem so gar nicht mehr bei dem von mir sehr geschätzten Enterprise-Architekten Volker Weber erwähnt wird (vowe.de, try search).

Komischerweise setzen sich die strukturierten Lösungen dann irgendwann gegen die "einfachen" Lösungen durch. Ruby-On-Rails setzt ähnlich wie Java auf einen geschichteten Ansatz.

Wenn ich in meiner Hibernate basierten Anwendung von Posgres auf eine andere DB wie Oracle oder DB2 umsteigen will, muss ich an diesen Stellen Änderungen vornehmen:
1. Datei jdbc.properties:
db.driverClass=org.postgresql.Driver
db.jdbcUrl=jdbc:postgresql:fussi
db.user=neil
db.password=wonttellucauseitsasecret
hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect

2. Die eine von mir benutzte stored procedure in Oracle neu schreiben.

3. Evtl. Automatic key generation Strategie in hbm.xml Dateien:

4. Evtl. bei den Queries.

[flaite]

Hallo Mark,

wenn ich eins in den letzten 4 Jahren gelernt habe sind es diese 3 einfachen Regeln:
1. Frameworks können nicht einfach so eingesetzt werden. Es gibt vielmehr einen Satz von best practices, die zu implementieren sind. Man kann dagegen verstossen, aber dann muss man wissen warum. Für Hibernate/Spring sind diese Regeln implementiert in den Beispielanwendungen CaveatEmptor (hibernate) und Petstore (Spring) oder in Anwendungen aus dem code-download von guten Büchern wie dem Spring & Hibernate Arbeitsbuch oder Richardson, Pojos in Action. Es gibt mehr Beispiele, aber die Regeln sind da sowieso alle gleich.
2. Die Regeln sind keine hyper-übertriebenen 3-fachen Ridberger mit gute B-Note sondern die Basics. Reale Anwendungen haben zusätzliche Anforderungen on top. Basics bedeutet: Die joseki-artigen Zugfolgen, die Du kennst. The safe haven. Lo fundamental.
3. Sobald Entwickler zu weit diese Regeln verlassen, wirds irgendwann unweigerlich Chaos geben (Unzufriedenheit, geplatzte Zeitplanungen, etc.)

Die Wahl von Frameworks ist THE LAW nachgeordnet. Ob ich jetzt Hibernate oder Spring-JDBC verwende? EGAL. Eine neue Dimension von EGAL ist mir gerade heute klargeworden. Die Anwendung verwendet Hibernate. Die Integrationstest Spring-JDBC. Vermutlich könnte ich das ganze in 4 Tagen nach EJB3 und SEAM umschreiben. All das hat sich soweit in Richtung eines UNIFIED LAW entwickelt, dass weite Teile der Struktur und des Codes der Anwendung gleich bleiben würden.

Gruß Axel

[Mark³]

Axel,

theoretisch hast du natürlich Recht und man sollte Anwendungen eigentlich nur nacheinem guten Modell entwickeln. Und natürlich ist das auch mein Ziel. Nun kommt da leider mal wieder die Realität dazwischen. Wir leben im ITIL-Zeitalter der Workarounds, hauptsache schnell und billig und es muss irgendwie laufen. Ich muss nun einen Kompromiss finden:
So schnell wie möglich und dabei trotzdem ein gutes Modell und eine gute Technik einsetzen. Wenn ich das sehr gut konzipiere und dabei eine langfristig günstigere Anwendung baue ist das schön. Wenn ich aber nach der Zeit x nicht fertig bin dann wird diese Anwendung gar nicht realisiert, daher benötige ich schnell was nutzbares was dann noch verfeinert werden kann.
Meine ersten Hibernate-Erfahrungen habe ich nun ja, ich denke ich werde daher Hibernate für die DB-Zugriffe einsetzen. Für das GUI möchte ich ZK nehmen, weil es damit extrem schnell ist, die benötigten Formulare zu bauen. GUI ist sonst nämlich sehr zeitraubend. Nun fehlt also noch eine Service-Schicht, die mir die Logik implementiert. Leider habe ich noch so kleine Randproblemchen, z.B. dass ein Teil meiner Stammdaten mittels einer DLL aus einem Fremdsystem importiert werden muss. Das geht mit vb oder LotusScript recht einfach, aber kann ich von Java aus über eine C-Schnittstelle Daten holen? Wenn das kompliziert ist werde ich die Daten über den Zwischenschritt Notes oder VB in die Datenbank schieben, da in Notes die Prozeduren schon existieren. Ein weiteres Problem sind die Berechtigungen:
In Notes hatte ich meine Leser- und Autorenfelder, und gut. Nun muss ich wohl die gesamte Berechtigungsstruktur selbst bauen.

[Mark³]

ich habe mir das CaveatEmptor-Beispiel mal angeschaut (leider ohne passendes Buch). Das sieht sehr gut strukturiert aus, allerdings ist es schon ziemlich abstrakt. Nun weiß ich auf jeden Fall, warum eine Anwendung, die man in Domino in 10 Tagen fertig hat, in Java mindestens 20 Tage Aufwand bedeutet. Irgendwie fehlt mir auch noch der Zugang zur echten OOP, da ich eigentlich nie Vererbung nutze. (Habe auch noch nie umfangreichere Java-Projekte erstellt).

[flaite]

Mark,

das hat nichts mit monate- oder wochenlanger Modellierung zu tun. Es geht einfach darum, sich vorhandene Beispielanwendungen in dein Eclipse zu laden und davon abschreiben.
Wenn das nicht so perfekt ist am Anfang, kannst du das immer noch refaktorieren. Eclipse behält hier einige interessante Unterstützungsfeatures bereit.

Die Servlet Spec unterstützt Authentifizierung, rollenbasierte Autorisierung und deklarative Sicherung des Transports (SSL). On Top gibts noch acegi security für Spring und J2EE Security. Eine praktische Umsetzung einer einfachen Umsetzung dieses in Tomcat findet sich auf Seite 151 ff des Arbeitsbuch Java Server Faces von Bernd Müller. Der benutzt natürlich auch eine geschichtete Architektur mit Service Layer und DAOs.

dlls können mit JNI angesprochen werden (z.B. http://dn.codegear.com/article/20679). Wenn das zeitgesteuert immer neu importiert werden soll, nimm quartz (hat super Spring Integration btw).

Ich werd das heute abend mal mit Service Layer und DAO implementieren.  Wenn du Spring benutzen würdest, wär das natürlich ein bischen einfacher. Warum benutzt du eigentlich kein Spring? Hier ist Beispielcode: http://zkoss.org/smalltalks/springdao/sdao.html

Ich benutze Unit-Tests und praxis-erprobte Architekturen, um schneller und zeitlich voraussehbarer business cases umzusetzen. Das passt prima zu ITIL. Zumindest aus meinem Verständnis. Ähnliche Pragmatismus-Debatten fanden hier vor 4 Jahren bezüglich Notes vs. J2EE oder PHP vs. J2EE statt. Ja ich weiss. Design von Java Anwendungen erfordert monatelanges obbbbjekkkkt-orrrrienttttiertes modellllierrrren. Die Kunden werden das irgendwann merken und zu "einfacheren" Lösungen zurückkommen. Genau das ist geschehen.  Im Enterprise Umfeld ist PHP ein großes Thema und J2EE, Spring, Hibernate und der ganze Java-Patterns Quatsch vergessen. Mit Java benötigt man doppelt so lange, weil das so abstrakt ist. Ja. Ich weiss. Die ITIL süchtigen Manager checken das einfach nicht. Und erstmal abstrakt aussehende Sachen werden nicht einfacher, wenn man sich eine Weile damit beschäftigt. Oh nein. Natürlich nicht.

Ich hab selbst die Erfahrung mit Hibernate gemacht:
Datenbankmodelle mit sehr wenig Tabellen und Beziehungen rechtfertigen kein Hibernate. Bei Datenbankmodellen mit einer Menge Tabellen und Beziehungen wirst du unweigerlich auf ein paar Dinge in Hibernate stossen, die ein profundes Verständnis von Hibernate einfordern. Du kannst ja mal dein Design auf dem Forum von Hibernate.org posten. Tipp: Nimm einen falschen Namen. Poste dann hier bitte die URL. Ich lese gerne Foren shoot-outs.

Gruß Axel

[Mark³]

ZK mit Spring sieht interessant aus. Ich hatte Spring bisher aussen vor gelassen, weil ich nicht alles auf einmal lernen kann während ich hier das normale Tagesgeschäft mache 
Für meine Anwendung wäre es evt. das schnellste, gar kein Framework zu nehmen, aber ich will so professionell arbeiten wie es unter den Umständen geht und auch in die Zukunft investieren. Der Small Talks-Artikel schlägt eine Lösung von ZK und Spring ohne Hibernate vor, korrekt? Meine Datenbank wird sicher nicht sehr komplex (etwa 10 Tabellen und ein paar Views) da wäre Hibernate wohl eh nicht so wichtig, oder? Oder ist es schneller, gleich Spring und Hibernate zu nehmen? Ich habe jedenfalls etwas Angst, dass ich nachher zig Frameworks nehme, die sich alle gegenseitig mit Abhängigkeiten überschlagen, so dass ich gar nicht dazu komme, meine Anwendung zu bauen. Mein Ziel ist ja immer noch, LifeRay und Alfresco als Plattform zu nehmen, aber die Plattform kann ich wohl erst nächstes Jahr nutzen. Daher will ich schnell was aufsetzen, um produktiv zu arbeiten und dabei wichtige DInge lernen, die ich später wiederverwenden kann. Ausserdem soll dann eine evt. Migration nach LifeRay einfach gehen. (Alfresco nutzt ja auch Hibernate und Spring, sollte also nicht so schlimm sein)

[flaite]

Bei Spring kannst du sehr problemlos zwischen verschiedenen RDBMS Zugriffsarten wechseln.
Spring JDBC erfordert  zwar ein bischen mehr Handarbeit als Hibernate, ist aber dafür deutlich transparenter. Hibernate sieht erstmal sehr einfach aus, hat aber - wie jeder Objekt Relationale Mapper seine interessanten Geheimnisse.
(Ted Neward hat O/R-M mal mit der Perzeption von Vietnam im pol. System der USA verglichen. Für mich als kolonial/Imperialismus-geschichtlich Interessierten und Apocalypse Now Bewunderer, inklusive des zugrundeliegenden Herz der Finsternis von Joseph Conrad ein Text, den ich für bemerkenswert halte.
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
)
Ich kann beides supporten.
Es ist schon richtig, dass das Zusammenspiel von Spring und Hibernate ein paar extra-Rätsel aufgibt. Es ist aber händelbar. Ich mach das. Viele machen das.
Ich würde definitiv eher auf Hibernate als auf Spring verzichten. (KORRIGIERT)
Vielleicht versuchst du mal diesen Artikel + Beispielcode. Dort ist ja der Stack Spring JDBC - ZK beschrieben (inklusive fertiger Beispielanwendung). Werd das auch mal versuchen.
 
Ich finde es übrigens eine Unverschämtheit, dass diese openSource Frameworks immer best practices in Form von laufenden Code liefern. Warum machen sie es nicht einfach wie IBM und Lotus? Ihre Lösung in Doktor-Arbeits-Form in den Himmel zu lösen. Für Beispielanwendungen gibts vielleicht Unterstützung in der Blogosphäre. Dieser abstrakte lauffähige Code verwirrt nur. 

[flaite]

Spring JDBC kann man sich etwa so vorstellen. So sieht das in einer statischen Helper Klasse für meine Integrationstests aus:
->

Code

// das sql statement -> alle offers für einen bestimmten Preis und eine bestimmte Aktie 
public static final String GET_OFFERS_FOR_STOCK_AND_PRICE = "select id, iduser, idstock, amount, price, creation from offerstock where idStock=? and price=?";

// gebe Liste für die Aktie und den Preis zurück
	public static List<Offerstock> getOffersForStockAndPrice(final SimpleJdbcTemplate simpleJdbcTemplate, Stock stock, double price) {

// ok. Das ist eine anonyme innere Klasse, die unten aufgerufen wird (no panic)
		ParameterizedRowMapper<Offerstock> mapper = new ParameterizedRowMapper<Offerstock>() {

			// notice the return type with respect to Java 5 covariant return
			// types
			public Offerstock mapRow(ResultSet rs, int rowNum)
					throws SQLException {
                               // für jedes einzelnen Wert des Resultsets wird ein Wert im Objekt gesetzt, das wiederum in die Liste kommt, die am Ende zurückgeliefert wird. 
				Offerstock stockOffer = new Offerstock();
				stockOffer.setId(rs.getLong("id"));
				int idUser = rs.getInt("idUser");
				User offerer = findUserById(simpleJdbcTemplate, idUser);
				stockOffer.setUser(offerer);
				int idStock = rs.getInt("idStock");
				Stock stock = findStockById(simpleJdbcTemplate, idStock);
				stockOffer.setStock(stock);
					
				stockOffer.setAmount(rs.getInt("amount"));
				stockOffer.setPrice (rs.getDouble("price"));
				stockOffer.setCreation(rs.getTimestamp("creation"));
				return stockOffer;
			}
		};

               // hier wird das alles aufrufsmässig zusammengeknotet. 
		return simpleJdbcTemplate.query(GET_OFFERS_FOR_STOCK_AND_PRICE, mapper,
				new Object[] { stock.getId(), price });
		
	}

Nicht so schwierig und Schema F. Spring JDBC ist eine der nicht allzu häufigen Sachen in Spring, in denen Java5 echt Vorteile bringt. Muss aber nicht.
Das ist schon die komplizierteste Methode, da es hier n:1 Beziehungen von offerstock zu user und stock gibt.

[flaite]

Ich versuche am WE meine Beispielanwendung Fussi-Börse in Google Code einzuschecken. Das ist auch ein brauchbares Beispiel (find ich).
Der Vorteil mit den Schichten besteht v.a. auch darin, dass Teile der Anwendung automatisiert testbar werden.
Z.B. gibts folgende Operation:
Ein User stellt ein Kaufgebot ein.
Das System sucht nach Verkaufsgeboten, der Preis >= dem Preis des Kaufgebots ist.
Wenn solche "matchende" Kauf- und Verkaufsgebote gefunden werden, findet eine Handelstransaktion statt, d.h.:
In der Datenbank wird ein Datensatz in die Tabelle Stocktransaction eingefügt.
In der Datenbank wird dem Geld-Konto des Verkäufers der Betrag der Handelstransaktion gutgeschrieben und dem Geldkonto des Käufers abgezogen.
In der Datenbank werden dem Aktien-Konto des Verkäufers die gehandelten Aktien abgezogen und dem Aktien-Konto des Käufers gutgeschrieben.
In der Datenbank wird der Preis der Aktie auf den Preis dieser letzten Aktientransaktion gesetzt.

Alles vom Business Case aus ziemlich kompliziert und wenn man für jede Änderung den Tomcat im Debug-Mode starten müsste, durch den Code fuhrwerken müßte und gleichzeitig 6 (hab gezählt) Tabellen der Datenbank im Auge behalten, die von dieser einen Operation betroffen sind... Da wird man wahnsinnig.

ABER: Die Funktion ist als Operation einer Klasse im Service-Layer definiert. Die ist völlig unabhängig vom (Web-) Frontend. Ich hab eine Testklasse, die die Test-Datenbank auf einen von mir kontrollierten Stand bringt. Und eine Test-Methode, die die Service-Methode selbst und jede Auswirkung auf die Datenbank per Knopfdruck testen kann.
Dies gibt dem Entwicklungsprozess eine ganz neue Art der Sicherheit. Normalerweise würde man von solchen komplexen Operationen änderungsmässig die Finger lassen. Und vielleicht ist man nie ganz sicher, ob das tatsächlich wie erwartet funktioniert und ob da nicht vielleicht doch irgendwo ein kleiner bug... Mit solchen isolierten und wiederholbaren Tests ist das alles kein Problem mehr. Ich brauch nicht mal Tomcat hochzufahren.
Natürlich ist das auch eine leckende Abstraktion, weil in eine Webanwendung solche Kauf und Verkaufsoperationen multithreaded durchgeführt werden und das hat Auswirkungen auf Datenbanklocks mit z.Zt. hohen Deadlock Risiken. Aber dafür gibts auch Test-Tools (da arbeite ich noch dran). Und gegen eine Menge Bug-Möglichkeiten kann ich mit meinen aktuellen Werkzeugen per Knopfdruck aufdecken. 

Aus meiner Sicht sprechen gerade diese Unterstützungen für einen zielgerichteten Entwicklungsprozess für Java/J2EE. Besonders kompliziert ist es auch nicht.

Spring unterstützt btw. immens beim einfachen Zusammenlöten einer geschichteten Architektur. Im Grunde ist der "Anfang" des Springframeworks (der dependency injection fähige Bean Container) dafür gebaut.

Gruß Axel

[Mark³]

nach meinen Kurzausflügen in Spring mit ZK und Hibernate (ich habe jeweils kleine laufende Beispiele hinbekommen) frage ich mich nun wieder, ob ich nicht doch gleich meine Anwendung als LifeRay-Portlet entwickeln kann, da dort ja Spring und Hibernate schon drin ist. Es gibt auch ein oder zwei Artikel darüber, aber das ist alles sehr unübersichtlich. Schon die EXT-Entwicklungsumgebung genau so hinzubekommen, dass man den Beispielen folgen kann, ist kaum möglich.
Mein revidierter Fahrplan sieht nun erstmal so aus:

LifeRay auf MySQL umstellen (fast fertig)
meine Datenbank oder Tabellen mit Hibernate in LifeRay integrieren und ein Portlet schreiben, was darauf zugreift. Wenn das einigermassen klappt werde ich so fortfahren. 

[Mark³]

ich bin dabei, nach der Anleitung für JSF-Portlets meine Anwendung als Portlet mit Datenbankanbindung zu basteln. Hab gerade bemerkt, dass ich mit Teil e angefangen habe, die Teile davor aber als Grundlage nötig waren. Naja, klappt aber trotzdem recht gut, werde die Teile a-d nun nachholen. Man deklariert ein bisschen Kot in XMLs und LifeRay macht mit ant-Tasks dann alle DAO-Klassen und SQL-Skripte.

[Mark³]

ich habe mein Portlet nun soweit funktionsfähig, dass ich mit JSF in LifeRay Datensätze in meiner MySQL-DB anlegen kann. Leider klappt die Anzeige der vorhandenen Datensätze nicht. Die gesamte Zugriffsschicht mit Hibernate generiert LifeRay selbst, beim Anlegen neuer Datensätze klappt das sehr gut. Aber beim Auflisten der vorhandenen Sätze bekomme ich eine leere Seite im Portlet. Kein Fehler, keine Überschrift mit leerem Datentable, einfach gar nichts.
Ich suche hier schon ewig rum, vergleiche das immer mit dem Beispiel 'JSF Portlet Database interaction' von LifeRay, sieht alles korrekt aus, aber klappt nicht.
Das muss doch ein gravierender Fehler sein, wenn die komplette JSF-Seite nicht angezeigt wird, es kommt aber nirgendwo eine Meldung:

Code

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>

<f:view>
	<h1>Display Access Models</h1>

	<h:dataTable headerClass="portlet-section-header"
		rowClasses="portlet-section-body,portlet-section-header-alternate"
		value="#{access.getAllAccessEntries}" var="accessItem">

		<h:column>
			<f:facet name="header">
				<h:outputText value="Access Number" />
			</f:facet>
			<h:outputText value="#{accessItem.accessNo}" />
		</h:column>
		<h:column>
			<f:facet name="header">
				<h:outputText value="Employee ID" />
			</f:facet>
			<h:outputText value="#{accessItem.employeeId}" />
		</h:column>

		<h:column>
			<f:facet name="header">
				<h:outputText value="Create Date" />
			</f:facet>
			<h:outputText value="#{accessItem.createDate}">
				<f:convertDateTime type="both" dateStyle="short" timeStyle="short" />
			</h:outputText>
		</h:column>
	</h:dataTable>

	<br />
	<br />
	<h:form>
		<h:commandButton action="back" value="Back" />
	</h:form>
</f:view>

Ich hatte auch schon probiert, die Werte mit accessItem.access.employeeId anzusprechen (analog zu anderen Beispielen) aber beides klappt nicht und nix Fehler