Archief - Java Web Development: wat is wat en waar te beginnen

Ik heb op school J2SE geleerd en op men werk tot nu toe ook enkel J2SE projecten gedaan.
Ik heb dus nog nooit met J2EE gewerkt of wat daar ook bij komt kijken. Het interesseert mij wel en kan van pas komen voor toekomstige projecten hier opt werk. Een tool een webinterface geven, of meerdere tools over het netwerk met elkaar laten communiceren.

Er zijn echter zodanig veel subdomeinen binnen J2EE, dat ik door het bos de bomen niet meer zie. Ik weet niet wat wat is, waar het bij komt kijken, en met welk boek over welk onderwerp ik best begin om hier in te duiken, want wat zijn:
- Enterprise Java Beans
- Java Server Pages
- Java Server Faces
- Servlets
- Facelets
- Portlets
- Web Services
- RESTful web services
- SOAP
- WSDL
- JSTL
- JAX-B
- JAX-WS
- JAX-RPC
- UDDI
- RMI
- Struts
- Tomcat<->Glassfish
- etc, etc ...

Ik heb een zeer grof idee wat die zaken zijn, maar er ontbreekt nog teveel.
Als iemand al die termen kort kan plaatsen, by all means, be my guest.

ja dat is al geen makkelijke vraag.

- Enterprise Java Beans :
Java beans voor J2EE, eigenlijk precies hetzelfde als de gewone J2SE beans, maar met meer APIs, zoals JMX (java managment extensions), zeer handig voor remote and server-oriented services.

- Java Server Pages
- Java Server Faces
Beide zijn zowat het antwoord op ASP.net en is een manier om webpages, meestal met server toepassingen erachter, te tonen.

- Servlets
- Facelets
- Portlets
Situeren zich meer low-level in het webgebeuren, maar zijn belangrijk. Een servlet bijvoorbeeld zal beschrijven "hoe antwoord ik op een HTTP POST", zit je bezig met de headers van packets te kijken wat er in zit enzo.

- Web Services : Redelijk algemene term.

- RESTful web services
- SOAP
- WSDL
- JSTL
deze 4 ben ik niet echt thuis in

- JAX-B
- JAX-WS
- JAX-RPC
JAX is interactie van Java en XML (dacht ik). Dit houd zich bezig met vooral datastructuur van gegevens.

- UDDI
ben ik niet thuis in.

- RMI
Remote method invocation. JMX hoort hierbij. Zeer belangrijk voor remote managed applications, en voor een stuk ook voor distributed computing.

- Struts
ook niet thuis in.

- Tomcat<->Glassfish
wel tomcat is meer een launch platform voor servlets en webapps.

thx voor de info. Ondertussen ook nog wat info opgezocht...

- Blijkt dat JSF een framework is om gemakkelijker met JSP te werken?

- En dan dacht ik dat Servlets de "back end" van een JSP pagina zijn. Dat je die schrijft, zoals je zegt, om requests te behandelen, en hun output wordt dan in een JSP pagina geplakt. Zo was mijn idee daar toch van. Dat een JSP pagina een html template is waar je op bepaalde plaatsen servlet functies aanroept...
Echter, blijkt nu dat JSP eigenlijk XML is, en de JSP compiler de servlets aanmaakt........

-Portlets en servlets zijn min of meer hetzelfde (waarom bestaan ze dan alletwee?); enkel facelets kan ik nog niet plaatsen.

-Een JSP pagina met een servlet achter, is dat dan een vb van een Web Service?

- JAX is Java API for XML ofzoiets, inderdaad, maar waarom bestaat er JAXB, JAXRPC, JAXWS. En blijkbaar zelfs nog JAXP, JAXM en JAXR en waar komen die bij kijken binnen het hele J2EE gebeuren?

- Tomcat is dus een Java webserver. Glassfish is een "Application server". Glassfish kan dus ook gebruik worden als webserver, correct? Welke meerwaarde heeft glassfish dan t.o.v. tomcat?

-P|b-SqUeaLeR zei:

- Blijkt dat JSF een framework is om gemakkelijker met JSP te werken?

Klik om te vergroten...

Is niet helemaal juist. JSF is een totaal nieuwe technologie.. alhoewel ze wel verder bouwt op de JSP. JSF is geen framework!

SOAP en WSDL hebben op zich niet veel met java te maken. Die worden door bijna alle moderne talen ondersteund.
SOAP is meer een algemene term waar web services een manier is om SOAP te implementeren.
SOA = service oriented architecture en de gemakkelijkste manier om services aan te spreken is het web = webservice.

Een wsdl (web service description language ofzo iets) is de beschrijving van een webservice. Het geeft aan welke functies de webservice heeft en welke parameters (in en uit) er zijn.

Portlets ga je veel zien in software voor het ontwikkelen van portals. Bijvoorbeeld oracle portal. Een portlet is dan eigenlijk een module die beantwoord aan een aantal specificaties zodat je die gemakkelijk kan integreren in de portal en zodus eigen functionaliteit toevoegen.

Facelets hoort bij JSF dacht ik en als ik het niet mis heb is dat iets om de theming of layout te doen maar ik kan hier ook grandioos mis in zijn

Portlets en servlets zijn min of meer hetzelfde (waarom bestaan ze dan alletwee?); enkel facelets kan ik nog niet plaatsen.

Klik om te vergroten...

Klopt niet helemaal...
Een portlet is specifiek een module die je kan hergebruiken op een portal. Meestal zal een portlet ook bepaalde settings hebben die de gebruiker zelf kan aanpassen terwijl een servlet eigenlijk niet bedoeld is voor die functionaliteit.

SOA = service oriented architecture en de gemakkelijkste manier om services aan te spreken is het web = webservice.

Klik om te vergroten...

aha! service oriented architecture had ik al tegengekomen op wikipedia, en daar werd dit van gezegd :

SOAP once stood for 'Simple Object Access Protocol' but this acronym was dropped with Version 1.2 of the standard, as it was considered to be misleading. Version 1.2 became a W3C Recommendation on June 24, 2003. The acronym is sometimes confused with SOA, or Service-oriented architecture; however SOAP is quite different from SOA.

Klik om te vergroten...

Maar SOAP zou dus eigenlijk een standaard zijn om netwerk messages (zijnde, method calls en return values) te versturen ?

SOAP is meer een algemene term waar web services een manier is om SOAP te implementeren.

Klik om te vergroten...

Maar daarmee is mij nog altijd niet duidelijk wat een web service precies is. Als ik het nu goed op heb, heeft JSP/JSF/servlets niets met web services te maken?

Is niet helemaal juist. JSF is een totaal nieuwe technologie.. alhoewel ze wel verder bouwt op de JSP. JSF is geen framework!

Klik om te vergroten...

Dus moest ik mij een boek kopen, moet het een JSF boek zijn, aangezien dat ook wel wat JSP zal vermelden?

Dus moest ik mij een boek kopen, moet het een JSF boek zijn, aangezien dat ook wel wat JSP zal vermelden?

Klik om te vergroten...

Een hele basis... maar het is niet omdat je JSF kan, dat je daarom JSP gaat kunnen hoor...

Maar daarmee is mij nog altijd niet duidelijk wat een web service precies is. Als ik het nu goed op heb, heeft JSP/JSF/servlets niets met web services te maken?

Klik om te vergroten...

Een webservice is een eigenlijk een verzameling van functies die je volgens de SOAP standaarden implementeerd en waar andere applicaties of services van gebruik kunnen maken.
Kijk... een applicatie bestond vroeger uit modules. Een module was een functionele uitbreiding op die applicatie. Een module was meestal enkel maar geschreven voor 1 bepaalde applicatie
SOA gaat het anders aanpakken. SOA zegt dat je een applicatie schrijft, door gebruik te maken van services. ZO kan je bijvoorbeeld een service gebruiken voor het inloggen, een service voor bepaalde gegevens op te halen, een andere service voor weet ik veel wat. De services zijn allemaal volgens standaarden en op die manier kan je die gemakkelijk implementeren. De beschrijving van een webservice vind je in een WSDL.

Je kan perfect met JSF, JSP,PHP of what ever een webservice schrijven. Je moet gewoon de SOAP standaarden volgen. Wat wil zeggen dat je JSF, JSP,... pagina XML moet genereren volgens de SOAP standaarden en volgens wat je gedefinieerd hebt in je WSDL zodat de applicatie die de service gebruikt, weet welke parameters die moet meegeven en wat hij van de service terug kan verwachten.

Tomcat is dus een Java webserver. Glassfish is een "Application server". Glassfish kan dus ook gebruik worden als webserver, correct? Welke meerwaarde heeft glassfish dan t.o.v. tomcat?

Klik om te vergroten...

Glassfish is een volledige J2EE server. Je kan dus zoals je zei volledig web applicaties deployen, maar ook gebruik maken van Enterprise Java Beans, Queue's enz. Kortom alles wat in de J2EE spec staat kan je gebruiken met Glassfish.

Langs de andere kant heb je Tomcat, die enkel maar het web gedeelte van de J2EE spec bevat.
Devolgende guideline zou ik je willen aanraden: voor eenvoudige web applicatie gebruik je best Tomcat. Wil je echter meer kan je altijd overschakelen op Glassfish.

http://www.javapassion.com/j2ee/

vind je ook wel veel info ivm j2ee

Struts is een MVC framework om web applicaties te bouwen. Gebruikt nogal weinig J2EE componenten en ook geen EJB. Alles is gratis en is / was in het verleden één van de meest gebruikte frameworks althans het nu verouderd begint over te komen. Ondersteunt actieservlets, form beans, en heeft veel componenten om in uw jsp's te gebruiken, heel makkelijke internationlization, error validatie, etc etc.

Ondertussen is Struts 2 eral die alle rompslomp en tekortkomingen van Struts heeft weggewerkt. Maar 'k heb geen flauw idee of het tegenwoordig populair is in de bedrijfswereld. De hype was er iig wel.

JSTL is trouwens een algemene sun library met componentjes die ge in uw JSP's kunt gebruiken.

MemberX zei:

Devolgende guideline zou ik je willen aanraden: voor eenvoudige web applicatie gebruik je best Tomcat. Wil je echter meer kan je altijd overschakelen op Glassfish.

Klik om te vergroten...

Offtopic weliswaar:

Met Glassfish heb ik nog niet gewerkt, maar wel met Tomcat, WebLogic en WebSphere. Tomcat blijft uit eigen ervaringen de meest performante server waar ik mee gewerkt heb. Tomcat is geen J2EE server, maar is eerder een servlet container (geen pure webserver want da's bv ne Apache). Ik ben van mening dat ge op Tomcat icm een goed framework à la Struts zeker ingewikkelde performante web applicaties kunt bouwen. Persoonlijk heb ik eerder een afkeer van EJB's ... de manier van werken en vooral de performantie steekt me tegen.

Ik zou t och wel eens willen zien of een tomcat de ADF applicaties even goed en performant kan draaien dan en AS van oracle (web logic vanaf 11g)...

Ik heb hier thuis het boek "Head first Servlets & JSP" liggen en das echt wel een steengoed boekske. Soms wordt het wel wat langdradig uitgelegd maar dat hoeft geen nadeel te zijn.

Catscratch zei:

Struts is een MVC framework om web applicaties te bouwen. Gebruikt nogal weinig J2EE componenten en ook geen EJB.

Klik om te vergroten...

Uh, je kiest volledig zelf wat voor back-end je gebruikt achter een MVC framework he. Als je EJB's wil gebruiken met een Struts MVC daarvoor, dan is dat absoluut geen probleem.

Je moet daar een duidelijk onderscheid in maken. Veel mensen begrijpen bijvoorbeeld het verschil niet tussen Spring enerzijds en Spring MVC anderzijds.

Catscratch zei:

Persoonlijk heb ik eerder een afkeer van EJB's ... de manier van werken en vooral de performantie steekt me tegen.

Klik om te vergroten...

Ooit al met EJB3 gewerkt?

Als de performance je tegensteekt doe je trouwens zelf iets verkeerd. Ik zit hier vaak nog met EJB2.1 te werken, maar wees gerust dat de performance enorm goed is (moet ook, in het hart van de stromen van de Sociale Zekerheid met enorme volumes).

-P|b-SqUeaLeR zei:

Dat een JSP pagina een html template is waar je op bepaalde plaatsen servlet functies aanroept...
Echter, blijkt nu dat JSP eigenlijk XML is, en de JSP compiler de servlets aanmaakt........

Klik om te vergroten...

Eerst en vooral: je kan met een JSP servletfuncties aanroepen, maar dat hoor je niet te doen, wegens "vuil". Je gaat in je servlets alles klaarzetten om dan te laten renderen door de JSP's.

En inderdaad, JSP's worden gecompiled tot servlets. Het grote nut van JSP's zijn dat ze je gemakkelijk een pagina laten opmaken. Je kan dat ook ineens in een servlet doen, maar dan kan je geen deftige tools gebruiken om pagina's op te maken (je maakt in principe 1 grote string van je pagina die je dan naar de outputstream schrijft) en de scheiding tussen view en controller is ver zoek dan. Een gewone web developer zal er dan ook niet meer aan uitkunnen, terwijl JSP's zeer verstaanbaar schrijven (als je ze niet volzet met scriptlets, wat ook erg vuil is).

- JAX is Java API for XML ofzoiets, inderdaad, maar waarom bestaat er JAXB, JAXRPC, JAXWS. En blijkbaar zelfs nog JAXP, JAXM en JAXR en waar komen die bij kijken binnen het hele J2EE gebeuren?

Klik om te vergroten...

Ik ken ze ook niet allemaal tbh. JAXWS is de opvolger van JAXRPC en zorgt voor de eigenlijke webservice zelf. JAXB zorgt voor omzetting van XML naar java objecten en omgekeerd. JAXP is een API om XML te parsen zonder er eerst Java-objecten van te maken.

x4xk3 zei:

Ik heb hier thuis het boek "Head first Servlets & JSP" liggen en das echt wel een steengoed boekske. Soms wordt het wel wat langdradig uitgelegd maar dat hoeft geen nadeel te zijn.

Klik om te vergroten...

Ken die ondertussen bijna vanbuiten, ik ga binnenkort voor SCWCD. Goed boek inderdaad en je kent er de hele Servlets/JSP-kant goed mee.

Over Web Services zegt het dan weer niets.

eniac zei:

Ooit al met EJB3 gewerkt?

Als de performance je tegensteekt doe je trouwens zelf iets verkeerd. Ik zit hier vaak nog met EJB2.1 te werken, maar wees gerust dat de performance enorm goed is (moet ook, in het hart van de stromen van de Sociale Zekerheid met enorme volumes).

Klik om te vergroten...

EJB2.1 ... Bij EJB's ben ik er altijd maar ingesmeten geweest toen ik nog consultancy deed en heb ik zelf nooit iets van de grond opgetrokken met EJB's.

Kan misschien zijn dat het slecht geschreven code was of niet, maar de mensen kloegen daar ook over de performantie en op kritische onderdelen hadden ze al ne omweg geschreven om niet via EJB.

Was nochtans een respectabel bedrijf in NL.

Pas op, ik heb het ook niet zo hoog op met EJB2.x hoor (allez, eigenlijk alles voorafgaand op 3.0). Kluwen van interfaces maakt het niet meteen handig in gebruik. Maar de performance is, indien deftig gedaan, geen probleem.

Ik heb het al anders gezien ook, zeer trage EJB-applicaties, maar de manier waarop het geschreven was... Amai


Nuja, EJB 3 lost de grote problemen van voorgaande versies op. Heb al gehoord (helaas nog niet aan den lijve mogen ondervinden, maar daar breng ik binnenkort verandering in) dat deze versie zeer sterk geïnspireerd is op het uitstekende Spring en Hibernate.

-P|b-SqUeaLeR zei:

- SOAP
- WSDL
- UDDI

Klik om te vergroten...

SOAP is een XML based protocol om te communiceren tussen web services.
Het komt er dus op neer dat er XML messages gestuurd worden tussen de client en webservice die het SOAP protocol volgen.

WSDL moet je dan zien als een soort skeleton file van die web service.
Het beschrijft de interface.
Als je de WSDL file hebt van de webservice, weet je dus welke calls je kunt maken etc

UDDI is voor publieke webservices
Stel bijv. dat jij een publieke webservice maakt, dan wil je dat andere mensen aan uw WSDL file kunnen zodat ze weten hoe ze uw functionaliteit kunnen callen.
In zo'n geval ga je u registreren bij een UDDI.
Andere mensen kunnen dan bij een UDDI op zoek gaan naar een gepaste webservice en de WSDL file daarvan opvragen.

eniac zei:

Pas op, ik heb het ook niet zo hoog op met EJB2.x hoor (allez, eigenlijk alles voorafgaand op 3.0). Kluwen van interfaces maakt het niet meteen handig in gebruik. Maar de performance is, indien deftig gedaan, geen probleem.

Ik heb het al anders gezien ook, zeer trage EJB-applicaties, maar de manier waarop het geschreven was... Amai


Nuja, EJB 3 lost de grote problemen van voorgaande versies op. Heb al gehoord (helaas nog niet aan den lijve mogen ondervinden, maar daar breng ik binnenkort verandering in) dat deze versie zeer sterk geïnspireerd is op het uitstekende Spring en Hibernate.

Klik om te vergroten...

Euh, EJB 3 en Hibernate hebben niets met mekaar te maken.

Verbaast me trouwens wel dat je zwaar fan bent van EJB 3, maar er ook niet de nadelen van in ziet. De AOP implementatie is immers zéér pover te noemen als je bv gaat vergelijken met Aspectj of de AOP Allience implementatie.

JPA is gebaseerd op ORM-frameworks met toplink als default implementatie die meegeleverd wordt met glassfish. (wat de default implementatie is van de JSR standards) Deze standaard staat ook volledig los van de EJB 3 standaard, hé. (sinds JEE 5)

Ik neem aan dat jij op 't RIZIV op project zit? Aangezien je spreekt over het hart van de sociale zekerheid?

WHiSPy zei:

Euh, EJB 3 en Hibernate hebben niets met mekaar te maken.

Klik om te vergroten...

De literatuur die ik erover gelezen heb vergeleek de entity beans toch nogal met de manier waarop Hibernate werkt (in die mate dat dezelfde persoon/personen achter beide zitten) en de session beans met de manier waarop je een Spring-applicatie in elkaar bokst.

Maar zoals ik al zei: ik heb er nog te weinig ervaring mee en daar zal binnenkort verandering in komen.. Ik heb er wel al genoeg over gelezen om te weten dat het een _heel_ pak beter is dan EJB 2.x en gezien mijn ervaringen ermee kan dat eigenlijk niet anders, of ze zouden het wel heel slecht gedaan moeten hebben.

Ik neem aan dat jij op 't RIZIV op project zit? Aangezien je spreekt over het hart van de sociale zekerheid?

Klik om te vergroten...

Het RIZIV is maar 1 van de instellingen van de sociale zekerheid. Ik zit in de Kruispuntbank van de Sociale Zekerheid. Alwaar zowat alle stromen tussen de verschillende instellingen van de sociale zekerheid passeren.

JPA is imo ook een quasi Hibernate clone. En het concept van IoC in Spring heeft men in EJB 3.0 ook overgenomen.

EJB 3.0 is idd een hele vooruitgang, maar er is nog genoeg werk aan. Stateful session beans zijn nog steeds erg, ma ik zou het zelf ook niet beter kunnen