[Java] J2EE app. met web-based en swing front-end (beginner)

[twiekert]

Ik zit op dit moment in een wat inventariserende fase voor een webshop applicatie die een webbased front-end heeft voor de internetbezoeker, en een swing-based beheer applicatie voor het beheer van de artikelen, orders etc. Nu heb ik zelf geen ervaring met J2EE ontwikkeling, op wat testgedoe met swing UI components na. Ik heb alleen ervaring met scripttalen zoals PHP/Javascript. OOP werken is geen probleem, ik mis alleen de basiskennis wat betreft J2EE coding en hoe het nu alle tiers aan elkaar geplakt worden.

De volgende setup heb ik in gedachten:

Application Server
JBoss of Sun Application Server. Voordelen van of verschil tussen deze 2 is mij niet echt duidelijk. Liefst draai ik de nieuwste JEE 5 versie zodat dingen als generics en jsf ook goed werken.

Webbased front-end
JSP icm met JSF components. In hoeverre is JSF al echt uitontwikkeld, zijn er al standaard componenten zoals de .NET/PRADO datagrids, calender choosers, datasource based repeater components e.d. of moet je die zelf ontwikkelen of 3rd party components voor gebruiken?

Swing/desktop app front-end
De swingbased desktop app. wordt in principe alleen gebruikt voor artikelbeheer, orders beheren, financieële rapportage e.d. de website heeft deze functionaliteit dus niet (eigenlijk geen overlapping van functionaliteit) ze moeten alleen wel van dezelfde back-end / code gebruik maken.

Database
PostGreSQL 8.1 als database. Laatst in een project gebruikt en bevalt stukken beter als MySQL, alleen jammer dat dingen als full text search standaard niet geinstalleerd zijn en een SQL_CALC_FOUND_ROWS functie niet bestaat.


J2EE, EJB, Hibernate?
Wat J2EE nu eigenlijk is wordt nergens goed uitgelegd, alleen dat het een subset/uitbreiding is van de J2SE SDK. Kan ik zonder gebruik te maken van EJB (Session beans, stateless/statefull beans, whatever beans) ook een 3-tier applicatie opzetten die over het netwerk babbelt met mijn swing applicatie en webbased frontend? Welke componenten heb je daarvoor nodig, gaat dat via RMI of CORBA (?). Hoe maakt een swing client of de JSP front-end (als deze op een aparte machine zou draaien ipv dezelfde VM als de app. server) nu eigenlijk contact met de services/remote objecten van de application server?

Voor de persistent objects wil gebruik maken van 'hibernated' POJO's die de client krijgt en weer terug stuurd. Het nut van aparte DTO's met daarbij weer een extra conversielaag zie ik het nut niet zo van in, of zijn er nog security issues of grote voordelen aan het gebruik van DTO's?

Waar kan ik het beste mijn business rules kwijt? Een gedeelte van deze business rules kunnen geimplementeerd worden in de POJO's, maar een rule zoals 'een bestelling op rekening mag alleen de status verstuurd krijgen als de klant zijn openstaand saldo met x bedrag niet overschrijdt' hoort niet in een POJO thuis maar in een aparte laag. Waar moet ik dit stoppen? in de DAO, een Service layer of in de database als trigger, of beide?


Zijn er goede boeken/websites die een vergelijkende situatie behandelen of kleine J2EE voorbeeld applicaties? Er zijn zat stukken code te vinden met best practices voor bijv. het DAO pattern maar hoe alles nu samenvalt en in de praktijk werkt ben ik nog niet achter.

Iemand tips / goede ideeën ?

[BalusC]

Application Server
JBoss of Sun Application Server. Voordelen van of verschil tussen deze 2 is mij niet echt duidelijk. Liefst draai ik de nieuwste JEE 5 versie zodat dingen als generics en jsf ook goed werken.

JBoss AS is gebaseerd op Apache Tomcat. SAS is op zichzelf staand. De huidige Tomcat 5.5 release ondersteunt (nog) Servlet 2.4 en JSP 2.0. Voor J5EE en JSF 1.2 heb je echter minimaal Servlet 2.5 en JSP 2.1 nodig. Dus SAS9 is op het moment een handigere keuze wanneer je J5EE wilt doen en niet aan de Tomcat configuratie wilt/kunt rommelen om het compatibel te maken. Echter qua server engine prefereer ik persoonlijk Tomcat ivm de snelheid en de eenvoud.

Webbased front-end
JSP icm met JSF components. In hoeverre is JSF al echt uitontwikkeld, zijn er al standaard componenten zoals de .NET/PRADO datagrids, calender choosers, datasource based repeater components e.d. of moet je die zelf ontwikkelen of 3rd party components voor gebruiken?

JSF kent de h:dataTable en de h:panelGrid. De calendar choosers moet je voorlopig even lenen van Apache MyFaces.

Swing/desktop app front-end
De swingbased desktop app. wordt in principe alleen gebruikt voor artikelbeheer, orders beheren, financieële rapportage e.d. de website heeft deze functionaliteit dus niet (eigenlijk geen overlapping van functionaliteit) ze moeten alleen wel van dezelfde back-end / code gebruik maken.

Ik zie geen vraag? Ach, ik heb verder toch geen ervaring met Swing

Database
PostGreSQL 8.1 als database. Laatst in een project gebruikt en bevalt stukken beter als MySQL, alleen jammer dat dingen als full text search standaard niet geinstalleerd zijn en een SQL_CALC_FOUND_ROWS functie niet bestaat.

Ik zie ook geen vraag? Anyway, PGSQL is geen slechte keuze.

J2EE, EJB, Hibernate?
Wat J2EE nu eigenlijk is wordt nergens goed uitgelegd, alleen dat het een subset/uitbreiding is van de J2SE SDK. Kan ik zonder gebruik te maken van EJB (Session beans, stateless/statefull beans, whatever beans) ook een 3-tier applicatie opzetten die over het netwerk babbelt met mijn swing applicatie en webbased frontend? Welke componenten heb je daarvoor nodig, gaat dat via RMI of CORBA (?). Hoe maakt een swing client of de JSP front-end (als deze op een aparte machine zou draaien ipv dezelfde VM als de app. server) nu eigenlijk contact met de services/remote objecten van de application server?

JEE bevat extra API onder de hoofdpackage javax, zoals JSP, JSF, servlets, XML parsers, mailer, etc.

EJB is niet noodzakelijk bij een simpele webapp. EJB kan dingen wel vergemakkelijken, maar het heeft een zeer hoge leercurve en als een beginner word je zo wel in een diepe put gegooid. Beans zijn overigens niet per definitie EJB. JSF kent bijvoorbeeld ook backing beans en er zijn verder ook eenvoudige (non-enterprise) JavaBeans.

Voor de persistent objects wil gebruik maken van 'hibernated' POJO's die de client krijgt en weer terug stuurd. Het nut van aparte DTO's met daarbij weer een extra conversielaag zie ik het nut niet zo van in, of zijn er nog security issues of grote voordelen aan het gebruik van DTO's?

Wanneer je zeker weten genoeg hebt aan de ongewijzigde Hibernate POJO's, dan zijn DTO's lichtelijk overbodig. Echter wanneer je in de toekomst denkt te uitbreiden en/of een aantal elementen wil toevoegen zonder dat de database aangepast moet worden, dan zijn DTO's handiger. Zelf gebruik ik gewoon DTO's die één complete invoerformulier representeren, al dan niet subclassed en/of voorzien van referenties naar andere DTO's. Soms worden ze allemaal gemapt naar Hibernate POJO's, maar er zijn ook gevallen waarbij maar gedeelten daarvan worden gemapt naar 1 of meer Hibernate POJO's en/of juist helemaal niet (hulpvariabelen, etc).

Dus: Hibernate POJO's kunnen het beste 1:1 de DB te representeren en de DTO's kunnen het beste 1:1 één invoerformulier te representeren. Het ligt uiteindelijk ook maar aan jouw eisen.

Waar kan ik het beste mijn business rules kwijt? Een gedeelte van deze business rules kunnen geimplementeerd worden in de POJO's, maar een rule zoals 'een bestelling op rekening mag alleen de status verstuurd krijgen als de klant zijn openstaand saldo met x bedrag niet overschrijdt' hoort niet in een POJO thuis maar in een aparte laag. Waar moet ik dit stoppen? in de DAO, een Service layer of in de database als trigger, of beide?

Configureerbare instellingen die niet in een DB opgeslagen kunnen (of mogen?) worden kun je het beste in propertiesfiles in de classpath plaatsen. Anders kun je het beste een aparte DB tabel en class maken voor dat soort dingen en de zooi static inladen à la propertiesfiles.

Zijn er goede boeken/websites die een vergelijkende situatie behandelen of kleine J2EE voorbeeld applicaties? Er zijn zat stukken code te vinden met best practices voor bijv. het DAO pattern maar hoe alles nu samenvalt en in de praktijk werkt ben ik nog niet achter.

Iemand tips / goede ideeën ?

Sja, ik ken helaas niet van die websites. Het is gewoon lezen van afzonderlijke documentatie en het zelf bijeenvoegen van de puzzelstukken. JEE tutorial, Core J2EE patterns (DAO), Hibernate reference, JSF TLD docs, etc..

[twiekert]

EJB is niet noodzakelijk bij een simpele webapp. EJB kan dingen wel vergemakkelijken, maar het heeft een zeer hoge leercurve en als een beginner word je zo wel in een diepe put gegooid. Beans zijn overigens niet per definitie EJB. JSF kent bijvoorbeeld ook backing beans en er zijn verder ook eenvoudige (non-enterprise) JavaBeans.

Ik lees net dit op de sun java EE site:

Remote Clients
A remote client of an enterprise bean has the following traits:

It can run on a different machine and a different Java virtual machine (JVM) than the enterprise bean it accesses. (It is not required to run on a different JVM.)
It can be a web component, an application client, or another enterprise bean.
To a remote client, the location of the enterprise bean is transparent.
To create an enterprise bean that has remote access, you must annotate the business interface of the enterprise bean as a @Remote interface. The remote interface defines the business and lifecycle methods that are specific to the bean. For example, the remote interface of a bean named BankAccountBean might have business methods named deposit and credit. Figure 20-1 shows how the interface controls the client's view of an enterprise bean.



Bron: http://java.sun.com/javae...EJBConcepts5.html#wp80011


Betekent dat ik zoiezo iets met EJB moet maken om remote clients te hebben, of mis ik nu wat? Ik heb op zich niets tegen EJB, maar hoor links en rechts constant verhalen over moeilijk dit, complex dat, en ik maak liever dingen dan dat ik dagen in documentatie gedoken zit en er nog geen reet van snap .
Als ik even een EJB Entity Bean vergelijk met een hibernated POJO (juiste vergelijking toch?) Wat is dan qua database afhandeling, configuratie e.d. het makkelijkst te gebruiken: Hibernate of EJB3? Mijn gevoel zegt Hibernate omdat er nogal wat mensen lyrisch over zijn, maar aan de andere kant ik heb ze zelf nog nooit beide gebruikt

Wanneer je zeker weten genoeg hebt aan de ongewijzigde Hibernate POJO's, dan zijn DTO's lichtelijk overbodig. Echter wanneer je in de toekomst denkt te uitbreiden en/of een aantal elementen wil toevoegen zonder dat de database aangepast moet worden, dan zijn DTO's handiger. Zelf gebruik ik gewoon DTO's die één complete invoerformulier representeren, al dan niet subclassed en/of voorzien van referenties naar andere DTO's. Soms worden ze allemaal gemapt naar Hibernate POJO's, maar er zijn ook gevallen waarbij maar gedeelten daarvan worden gemapt naar 1 of meer Hibernate POJO's en/of juist helemaal niet (hulpvariabelen, etc).

Dus: Hibernate POJO's kunnen het beste 1:1 de DB te representeren en de DTO's kunnen het beste 1:1 één invoerformulier te representeren. Het ligt uiteindelijk ook maar aan jouw eisen.

En wat als je deze POJO's nou ook op de client wilt bewerken? wat ik begrepen heb van Hibernate is dat mogelijk maar dan moet je of een select-before-update doen om te kijken of het object is gewijzigd en gepersist moet worden of property change support inbouwen en afvangen of object properties zijn gewijzigd.
Als ik er even over nadenk dan zijn DTO's idd wel makkelijker (zoals authorization security inbouwen) maar in de meeste gevallen komen ze zowat 1-op-1 overeen met een hibernate POJO, ik vindt het zo zonde van mijn tijd om aparte DTO's te schrijven en ook nog eens een 2-kanten-op conversie laag

Configureerbare instellingen die niet in een DB opgeslagen kunnen (of mogen?) worden kun je het beste in propertiesfiles in de classpath plaatsen. Anders kun je het beste een aparte DB tabel en class maken voor dat soort dingen en de zooi static inladen à la propertiesfiles.

Wat ik eigenlijk bedoelde is iets als dit:

Java:

public void placeOrder(Order order) {
    Boolean isOverDrawn = CustomerDingesBean.isOverDrawn(order.getCustomer());
    if (isOverDrawn) {
        throw new OrderException("bla kan niet, geld op!");     
    }


    HibernateSession.saveOrUpdate(order); //ofzoiets
}

Hoort die method placeOrder met credit check in een DAO thuis of in een laag ervoor zoals een Session Bean (net gelezen ).

[Ti_Uhl]

twiekert schreef op maandag 16 oktober 2006 @ 14:00:
...

Swing/desktop app front-end
De swingbased desktop app. wordt in principe alleen gebruikt voor artikelbeheer, orders beheren, financieële rapportage e.d. de website heeft deze functionaliteit dus niet (eigenlijk geen overlapping van functionaliteit) ze moeten alleen wel van dezelfde back-end / code gebruik maken.

...

Zie hier niet onmiddelijk een vraag staan maar ik zou voor een client meer naar native widgets gaan, namelijk SWT + JFace. Deze werken veel vlotter en passen een pak beter bij de rest van je os, wat die ook mogen zijn. Swing lijkt mij een beetje verouderd en sloom. Dus als ik van jou was zou ik zeker eens kijken naar SWT.

Meer info over swt kan vindt je hier : http://www.eclipse.org/swt/

[JKVA]

EJB moet je niet willen als je net komt kijken. Zelfs ervaren ontwikkelaars zijn de kluts weleens kwijt bij EJB programmeren. Ik zou sowieso niet beginnen ontwikkelen met allemaal onbekende technieken. Dan zie je door de bomen het bos niet meer. Het voordeel van EJB's merk je pas echt sterk als je dingen als clustering en zo wil gaan regelen en container managed transactions.

Als je gewoon je hele app op 1 server draait, kijk dan naar Spring framework of programmeer het gewoon in plain Java. Je moet eerst ervaring met frameworks hebben wil je er een zinnig oordeel over kunnen vellen.

Voorstel:
JBoss 4 (en dus Tomcat) Is J2EE 1.4 compatible, dus Java SE 5, dus Generics.

Weblaag
- Apache MyFaces 1.1.2 (misschien dat 1.1.3 ook nog werkt, maar dat weet ik niet zeker)
- Apache MyFaces Tomahawk voor coole widgets
- Facelets voor templating (absolute aanrader, JSF zuigt zonder Facelets)

Daaronder
- Eventueel Spring of gewoon plain Java
- Hibernate

PostGreSQL 8.1 werkt idd prima en is stukken beter dan MySQL.

BTW: Als je deze opstelling gebruikt, heb je zelfs niet eens een zware applicatieserver nodig, maar is Tomcat voldoende.

[twiekert]

Als ik JBoss 4.0.4 gebruik dan zit Apache MyFaces al ingebakken volgens de jboss site. Dan zou Tomahawk als toevoeging er nog bijkunnen, kan dat? Het liefst hou ik zoveel mogelijk de sun specs aan, SWT ziet er wel leuk uit maar is geen sun spec en echt groot voordeel t.o.v. swing zie ik eigenlijk niet?

En wat is Facelets nou precies? Een template systeem met extra tags die JSF uitbreidt, en soms vervangt?

Zonder application server moet ik dus zowel de hibernate archive en mijn eigen POJO code op de webserver zetten en ook meeleveren met de desktop client toch?

[JKVA]

Facelets is onmisbaar als je JSF versie < 1.2, anders is het gewoon een zeer goede toevoeging.

Ik bedoel dat je met mijn opzet geen 'echte' applicatieserver nodig hebt, maar dat een web container genoeg is, zoals Tomcat of Jetty.

[Verwijderd]

je kan je 'business laag' ook scheiden dmv webservices...

En Spring (werd hiervoor reeds genoemd) kan je objecten die je business methoden accepteren exporteren als webservice zonder dat je je daar zorgen om hoeft te maken.
jibx onder xfire gebruiken om je dto's naar XML te (de)serializeren enzo...

Webservices & stateless session beans vind ik de properste scheiding. Met het laatste heb ik ervaring, het eerste niet. Maar het laatste zag jij niet zitten dus vandaar .

Maar met de annotations driven config van EJB 3.0 zie ik ook nog geen problemen (maar: daar heb ik ook nog geen ervaring mee ).

edit: misschien even verduidelijken dat het voordeel van XML versturen als request de leesbaarheid is. Of je moet voor elk object een volledige uitgebreide toString implementeren en onderhouden. Je verzoek dat je over de lijn stuurt is dan leesbaarder. (gewoon XML waar je meestal toch wel tamelijk wat controle over hebt).

[ Voor 21% gewijzigd door Verwijderd op 18-10-2006 15:23 ]

[ronaldmathies]

[quote]BalusC schreef op maandag 16 oktober 2006 @ 15:06:
[...]
JBoss AS is gebaseerd op Apache Tomcat. SAS is op zichzelf staand. De huidige Tomcat 5.5 release ondersteunt (nog) Servlet 2.4 en JSP 2.0. Voor J5EE en JSF 1.2 heb je echter minimaal Servlet 2.5 en JSP 2.1 nodig. Dus SAS9 is op het moment een handigere keuze wanneer je J5EE wilt doen en niet aan de Tomcat configuratie wilt/kunt rommelen om het compatibel te maken. Echter qua server engine prefereer ik persoonlijk Tomcat ivm de snelheid en de eenvoud.
[...]

JBoss is niet gebaseerd op Apache Tomcat, Apache Tomcat draait als een service binnen de JBoss Application Server. Tomcat verzorgt de web container deel van JBoss. Het is echter gewoon mogelijk om Tomcat uit JBoss te halen en alleen het overige deel van JBoss te gebruiken. (JBoss heeft een soort van plugin model).

[Cuball]

Wijzelf hebben voorlopig voldoende met een Tomcat Web server, maar als we een AS zouden nodig hebben zou ik toch eens kijken naar JOnAS. Ik vind dat je er trouwens zo weinig over leest, zijn er bepaalde zaken die nog onvoldoende werken in een JOnAS application server of dergelijke ?