Toon posts:

[java / ejb] wat gebruiken jullie?

Pagina: 1
Acties:
  • 190 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Hoi,

Ik ben de laatste tijd veel bezig met het ontwikkelen van Enterprise java beans.
Ik werk op Linux en gebruik eigenlijk nu niet veel anders dan mijn favoriete editor vi. Verder gebruik ik ant om de boel te compilen, deployen, etc...

Ik vroeg me af wat jullie gebruiken. Zijn er IDE's / tools beschikbaar die het leven gemakkelijker maken wat betreft het maken van EJB's?

  • The - DDD
  • Registratie: Januari 2000
  • Laatst online: 17-08 22:44
Je kunt is eclipse proberen (www.eclipse.org) samen met de lomboz plug-in. Alhoewel ik nog niet zeker weet of dat wat is (lomboz)....

Vergeet verder XDoclets niet.... Daarmee kun je alle EJB meuk in 1 file definieren. Vervolgens genereer je daaruit je Home & Remote interface, je bean class en de XML descriptor. http://xdoclets.sourcefourge.org (ofzo)...

Oh ja en JBoss natuurlijk (www.jboss.org) dat is de ultieme applicatie server ;)

Alles wat ik net noemde is opensource en zou allemaal onder Linux moeten werken.

Verwijderd

't is waarschijnlijk niet het topic om hierover te beginnen, maar wat houdt EJB nu precies is? Ik programmeer nu al zo'n 3 tot 4 jaar in Java en ik kan wel wat leuke programmaatjes in elkaar duwen, maar ik heb nog nooit met een EJB gewerkt (voor zover ik weet dan). Wat ik ervan begrepen heb is het meer de EJB container die zo belangrijk is bij deze architectuur, omdat die alle min of meer generieke onderdelen van een (web)applicatie overneemt.

Jammergenoeg heb ik nooit echt zin en tijd gehad om mij hier verder in te verdiepen. Ik heb wel laatst JBoss gedownload en geïnstalleerd, maar het is me niet echt duidelijk geworden wat ik er nu mee moet. Ik heb wel al veelvuldig TomCat 4 gebruikt, wat ook een EJB container schijnt te zijn (correct me if I'm wrong), maar ik zou graag precies weten wat een EJB (en -container) nu eigenlijk is en waar het nu precies goed voor is.

Kan iemand me ff een duwtje in de goeie richting geven waar ik hier meer info over kan vinden? Ik ben me een beetje aan het inlezen in webservices, wat kan een EJB hieraan bijdragen?

Alvast bedankt!

Verwijderd

websjwans moet je hier het boek ff downloaden
http://www2.theserverside...asteringEJB/index.jsp?tmc

Verwijderd

Ziet er veelbelovend uit, bedankt voor de link.

Verwijderd

Topicstarter
The - DDD schreef op 23 oktober 2002 @ 08:58:
Je kunt is eclipse proberen (www.eclipse.org) samen met de lomboz plug-in. Alhoewel ik nog niet zeker weet of dat wat is (lomboz)....

Vergeet verder XDoclets niet.... Daarmee kun je alle EJB meuk in 1 file definieren. Vervolgens genereer je daaruit je Home & Remote interface, je bean class en de XML descriptor. http://xdoclets.sourcefourge.org (ofzo)...

Oh ja en JBoss natuurlijk (www.jboss.org) dat is de ultieme applicatie server ;)

Alles wat ik net noemde is opensource en zou allemaal onder Linux moeten werken.
Ik heb eclipse met de Lomboz plugin al eens geprobeerd. Maar ik kan alleen maar zeggen dat het gewoon (nog) niet werkt.
Lomboz maakt overigens veelvuldig gebruik van XDoclet. Ik heb XDoclet nu maar eens gedownload. Ga eens proberen of dat het tikken van deployment descripters etc... vereenvoudigd.

  • LordLarry
  • Registratie: Juli 2001
  • Niet online

LordLarry

Aut disce aut discede

Borland JBuilder kan het ook. Er is een gratis versie, maar ik denk niet dat die EJB's aankan. Draait zowel onder linux, solaris en windows als ik me niet vergis. Tis tenslotte zelf in java gemaakt :)

We adore chaos because we like to restore order - M.C. Escher


  • bazzs2001
  • Registratie: April 2002
  • Laatst online: 13-06 11:18

bazzs2001

je moet knagen wat lekker is

LordLarry: JBuilder personal kan voor zover ik weet niks met J2EE doen (volgens mij alleen de Enterprise versie)

websjwans: EJB's zijn mooi om een applicatie scalabel en robuust te maken maar er zit wel veel werk in en meestal is J2EE overdreven (en traag)

JBoss en TomCat zijn J2EE omgevingen en in deze ogmevingen draaien EJB containers......

groeten


Verwijderd

Topicstarter
bazzs2001 schreef op 24 oktober 2002 @ 11:38:
websjwans: EJB's zijn mooi om een applicatie scalabel en robuust te maken maar er zit wel veel werk in en meestal is J2EE overdreven (en traag)
Dat er (initieel) veel werk in gaat zitten is waar. Je moet heel wat klassen schrijven om een beetje applicatie draaiend te krijgen. Uiteindelijk krijg je er wel een zeer mooi goed te onderhouden draaiend geheel voor terug. Dat het vaak overdreven en langzaam is zou ik toch willen weerleggen. JBoss bijvoorbeeld is rete snel. En overdreven wil ik het zeker niet noemen. Toch zeker wanneer je realiseert dat het onderhoud van dergelijke applicaties zich tot een minimum beperken.
Ik ben reeds enige tijd bezig met het schrijven van applicaties m.b.v. ejb en ik moet echt zeggen dat ik het tot op heden het meest doordachte systeem tot op heden vindt. De open-source projecten die momenteel lopen brengen mij zeker niet op andere gedachten. Kijk eens naar JBoss, XDoclet, ant, etc...

Ik denk dat EJB op het gebied van Applicatie Server toepassingen veruit de beste keuze is van dit moment.

Verwijderd

bazzs2001 schreef op 24 oktober 2002 @ 11:38:
LordLarry: JBuilder personal kan voor zover ik weet niks met J2EE doen (volgens mij alleen de Enterprise versie)

websjwans: EJB's zijn mooi om een applicatie scalabel en robuust te maken maar er zit wel veel werk in en meestal is J2EE overdreven (en traag)

JBoss en TomCat zijn J2EE omgevingen en in deze ogmevingen draaien EJB containers......
Veel werk, ga de database code zelf maar schrijven. CMP scheelt je juist werk.

  • bazzs2001
  • Registratie: April 2002
  • Laatst online: 13-06 11:18

bazzs2001

je moet knagen wat lekker is

Verwijderd schreef op 24 oktober 2002 @ 15:46:
[...]
Dat er (initieel) veel werk in gaat zitten is waar. Je moet heel wat klassen schrijven om een beetje applicatie draaiend te krijgen. Uiteindelijk krijg je er wel een zeer mooi goed te onderhouden draaiend geheel voor terug. Dat het vaak overdreven en langzaam is zou ik toch willen weerleggen. JBoss bijvoorbeeld is rete snel. En overdreven wil ik het zeker niet noemen. Toch zeker wanneer je realiseert dat het onderhoud van dergelijke applicaties zich tot een minimum beperken.
Ik ben reeds enige tijd bezig met het schrijven van applicaties m.b.v. ejb en ik moet echt zeggen dat ik het tot op heden het meest doordachte systeem tot op heden vindt. De open-source projecten die momenteel lopen brengen mij zeker niet op andere gedachten. Kijk eens naar JBoss, XDoclet, ant, etc...

Ik denk dat EJB op het gebied van Applicatie Server toepassingen veruit de beste keuze is van dit moment.
Ik moet misschien is naar JBoss kijken, de refrence implementatie is in ieder geval vrij traag en geheugen vretend.

Ant heb ik nu een paar keer gebruikt en is inderdaad vrij handig, naar XDoclet moet ik nog kijken.

Ik vindt EJB's wel handig, maar voor veel gevallen is het gewoon overbodig (maar in sommige gevallen is het dan weer heeeeel handig, o.a door de schaalbaarheid en de onderhoudbaarheid).

groeten


  • bazzs2001
  • Registratie: April 2002
  • Laatst online: 13-06 11:18

bazzs2001

je moet knagen wat lekker is

Verwijderd schreef op 24 oktober 2002 @ 15:57:
[...]

Veel werk, ga de database code zelf maar schrijven. CMP scheelt je juist werk.
JDBC kan je ook zonder EJB's gebruiken......

groeten


Verwijderd

bazzs2001 schreef op 24 oktober 2002 @ 16:06:
[...]


JDBC kan je ook zonder EJB's gebruiken......
Ja en? Dan is JDBC code schrijven meer werk als CMP. Helemaal als je appserver een tool hiervoor heeft. Ik gebruik zelf orion ( www.orionserver.com ) en hoef dan alleen maar d.m.v een tool de velden van een bean aan te geven, plus eventuele relaties met andere beans en de tool genereert source + deplyoment descriptors.

  • bazzs2001
  • Registratie: April 2002
  • Laatst online: 13-06 11:18

bazzs2001

je moet knagen wat lekker is

Verwijderd schreef op 24 oktober 2002 @ 17:15:
[...]
Ja en? Dan is JDBC code schrijven meer werk als CMP. Helemaal als je appserver een tool hiervoor heeft. Ik gebruik zelf orion ( www.orionserver.com ) en hoef dan alleen maar d.m.v een tool de velden van een bean aan te geven, plus eventuele relaties met andere beans en de tool genereert source + deplyoment descriptors.
Dat is natuurlijk wel zo, maar als jij geen ejb's gebruikt is Container Managed Persistence (hier hebben we het over toch) geen goede reden om op ejb's over te stappen lijkt mij...

Het blijft natuurlijk een mooi mechanisme.

groeten


Verwijderd

WSAD (WebSphere Studio Application Developer) is de tool om (o.a.) EJB's mee te maken en te testen. WSAD maakt gebruik van eclipse, maar heeft veel meer mogelijkheden. De nieuwste versie van WSAD is 5.0 en ondersteund de J2EE 1.3 (o.a. EJB 2.0) specs. In WSAD 5.0 zit de AE versie van WebSphere 5.0 waarmee het een en ander getest kan worden. Super gave tool.

Van WSAD 4.0.3 (J2EE 1.2) bestaat ook een linux versie.

  • The - DDD
  • Registratie: Januari 2000
  • Laatst online: 17-08 22:44
Iedereen doet altijd zo moeilijk over EJB's. Het zijn context afhankelijke componenten. Is de context er niet, dan kan een EJB niks. En die context is dus je applicatie server.

Grootste nadeel van EJB's? Geen single point of definition. Je moet een implementatie schrijven, een remote interface, een home interface en dan ook nog een aparte deployment descriptor. Vier files voor 1 component!! MAAR XDoclet lijkt hier de oplossing voor te zijn.

Grootste voordeel van EJB's is naar mijn idee dat het ontzettend goed te configureren is. Transacties?? Geen probleem, moeten ze ook distributed zijn? Beveiliging? Tuurlijk, als je me even verteld welke methode ik moet gebruiken doe ik het voor je. Database? Zal ik even al DB code voor de genereren (CMP) of heb je het toch liever zelf in de hand...(BMP). Concurrency? Als je je aan de standaard houdt dan hoef je er bijna niet meer bij stil te staan.

Kortom voordelen. En er zijn er nog veel meer. Veel mensen zitten heel makkelijk J2EE met .NET gelijk te trekken. Eh, niet dus volgens mij. (mijn mening, dus flip hier niet om)


Leukste van J2EE is nog wel het volgende, je bengint er mee en je wordt overspoeld met ontzettend veel kennis en informatie... Je zwoegt verder en langzaam gaat er een lichtje branden. (kan lang duren of nooit gebeuren voor sommigen) Maar als je zo ver bent dan draai je in no time dingen in elkaar die, zodra ze draaien, staan als een huis. Heb al een paar keer gehad dat ik iets had gedaan en anderhand echt dacht: "Damn, dat in zo weinig tijd? Vet man!!"

Daarom zeg ik: "J2EE is vet."

  • bazzs2001
  • Registratie: April 2002
  • Laatst online: 13-06 11:18

bazzs2001

je moet knagen wat lekker is

The - DDD schreef op 25 oktober 2002 @ 10:02:

Grootste nadeel van EJB's? Geen single point of definition. Je moet een implementatie schrijven, een remote interface, een home interface en dan ook nog een aparte deployment descriptor. Vier files voor 1 component!! MAAR XDoclet lijkt hier de oplossing voor te zijn.
ga hier toch eens snel naar kijken
Grootste voordeel van EJB's is naar mijn idee dat het ontzettend goed te configureren is. Transacties?? Geen probleem, moeten ze ook distributed zijn? Beveiliging? Tuurlijk, als je me even verteld welke methode ik moet gebruiken doe ik het voor je. Database? Zal ik even al DB code voor de genereren (CMP) of heb je het toch liever zelf in de hand...(BMP). Concurrency? Als je je aan de standaard houdt dan hoef je er bijna niet meer bij stil te staan.
Dit zijn dingen die je allemaal moet instellen en waar je allemaal over moet nadenken, als je nog geen handigheid hebt in J2EE dan is dit toch lastig en ben je er best lang mee bezig.

Een van de nadelen van J2EE en EJB's is dat er wel documentatie is maar die lijkt niet altijd helemaal te kloppen of is onvolledig, omdat niet veel mensen wat met EJB's hebben gedaan vindt je ook niet veel als je zoekt.
Kortom voordelen. En er zijn er nog veel meer. Veel mensen zitten heel makkelijk J2EE met .NET gelijk te trekken. Eh, niet dus volgens mij. (mijn mening, dus flip hier niet om)
Ik weet niet precies wat .NET is, maar dacht eigenlijk dat het net zoiets als J2EE is...
Leukste van J2EE is nog wel het volgende, je bengint er mee en je wordt overspoeld met ontzettend veel kennis en informatie... Je zwoegt verder en langzaam gaat er een lichtje branden. (kan lang duren of nooit gebeuren voor sommigen) Maar als je zo ver bent dan draai je in no time dingen in elkaar die, zodra ze draaien, staan als een huis. Heb al een paar keer gehad dat ik iets had gedaan en anderhand echt dacht: "Damn, dat in zo weinig tijd? Vet man!!"
Mja ik heb alleen nog maar wat testapps gemaakt om J2EE te leren en bij mij is het meer geweest van: "hé hé het werkt eindelijk".

Hoewel ik de laatste keer zoiets had van: "huh werkt het al?"
Daarom zeg ik: "J2EE is vet."
J2EE is ook vét, maar in veel gevallen in mijn mening overdreven, maar als je het wel nodig hebt dan is het zeker vét!

groeten


  • traviandus
  • Registratie: Februari 2001
  • Laatst online: 25-03-2025

traviandus

vague

Verwijderd schreef op 22 oktober 2002 @ 17:35:Ik vroeg me af wat jullie gebruiken. Zijn er IDE's / tools beschikbaar die het leven gemakkelijker maken wat betreft het maken van EJB's?
Om even weer op de vraag terug te komen: Ik heb zelf een tijdje Forte for Java gebruikt. Die is gratis te downloaden van Sun website. Zit gigantisch veel functionaliteit in, alleen is geschreven in Java en dus wel een snelle machine vereist om de zaak een beetje soepel te laten lopen.

Ik ben later toch weer terug gegaan met ontwikkeling in een standaard editor (EditPlus onder Windows) en voor compilen/builden/deployen) heb ik Ant (jakarta.apache.org/ant) gebruikt. Voor mij bleek dit toch de meest praktische combinatie.

Verwijderd

Topicstarter
traviandus schreef op 25 oktober 2002 @ 11:06:
[...]


Om even weer op de vraag terug te komen: Ik heb zelf een tijdje Forte for Java gebruikt. Die is gratis te downloaden van Sun website. Zit gigantisch veel functionaliteit in, alleen is geschreven in Java en dus wel een snelle machine vereist om de zaak een beetje soepel te laten lopen.

Ik ben later toch weer terug gegaan met ontwikkeling in een standaard editor (EditPlus onder Windows) en voor compilen/builden/deployen) heb ik Ant (jakarta.apache.org/ant) gebruikt. Voor mij bleek dit toch de meest praktische combinatie.
Ik zit inderdaad in een soorgelijke situatie. Ik gebruik dus vim & ant. Op zich ook best een goede combinatie. Maar het komt er nog altijd op neer dat ik deployment descripters zit te tikken met de hand. XDoclet lijkt hiervoor een oplossing te bieden. Maar daar heb ik op zich nog weinig ervaring mee. Ik kan ook niet echt een goede tutorial hiervoor vinden. (Behalve dan de XDoclet homepage).

Dat vindt ik eigenlijk wel jammer. Ik ben namelijk altijd veel tijd kwijt met het maken juiste deployment descriptors. Deployment descriptors zijn er eigenlijk alleen voor de application server. En hebben verder weinig waarde voor mensen.
Daarbij is het natuurlijk gewoon suf tikwerk. Wat ook goed gedaan kan worden door een goede tool. (Ik ga me maar eens storten op XDoclet denk ik).,

  • Bobco
  • Registratie: Januari 2001
  • Laatst online: 30-10-2023

Bobco

I used to dream about Verona.

Verwijderd schreef op 25 oktober 2002 @ 13:01:
[...]
Ik zit inderdaad in een soorgelijke situatie. Ik gebruik dus vim & ant. Op zich ook best een goede combinatie. Maar het komt er nog altijd op neer dat ik deployment descripters zit te tikken met de hand. XDoclet lijkt hiervoor een oplossing te bieden. Maar daar heb ik op zich nog weinig ervaring mee. Ik kan ook niet echt een goede tutorial hiervoor vinden. (Behalve dan de XDoclet homepage).
Dat soort combinaties werkt prima, maar er is nog meer mogelijk. Zelf gebruik ik (onder WinNT) IntelliJ IDEA. Is weliswaar niet gratis, maar er is een Early Access program waardoor je 'm toch gratis mag gebruiken. Zelf wil ik eigenlijk niets anders meer: handige refactoring opties, intelligente imports, goede integratie met Ant, voortdurend controle of je niet vloekt in Java zodat je tenminste niet compileert en er dan achter komt dat je een cast naar String bent vergeten.

Kortom, kijk hier maar eens....

With the light in our eyes, it's hard to see.

Pagina: 1