JBoss maakt J2EE-ontwikkeling makkelijker

JBoss, producent van de gelijknamige Java application-server, heeft nieuwe versies van zijn producten uitgebracht die ondersteuning bieden voor de nieuwe versie 3.0 van Enterprise Java Beans (EJB). Onder de nieuwe producten die EJB 3.0-ondersteuning bieden bevinden zich een nieuwe versie van de JBoss Appllication Server 4, Hibernate 3, JBoss Eclipse IDE 1.5 en een nieuwe versie van JBoss Portal, 2.0.

Met EJB 3.0 zou het voor ontwikkelaars eenvoudiger moeten worden om J2EE-applicaties te ontwikkelen. Hoewel J2EE een relatief groot marktaandeel heeft, staat het platform bekend onder ontwikkelaars om zijn complexiteit en de relatief lange leercurve. Met de nieuwe versie van EJB zal er volgens de ontwerpers minder code nodig zijn om de componenten met elkaar te verbinden en kan er meer tijd worden besteed aan de logica van de applicatie. Sacha Labourey, JBoss' European general manager, geeft toe dat de concurrentie van het .Net-framework van Microsoft ook invloed heeft op de veranderingen in de EJB-standaard. 'Er is concurrentie van .NET, dat wellichtt niet zo krachtig is [als J2EE], maar erg eenvoudig is om in te ontwikkelen. Het is dus tijd om de programmeurs hun productiviteit terug te geven', aldus Labourey.

De nieuwe EJB 3.0 maakt met name object-persistentie eenvoudiger. In voorgaande versies moesten ontwikkelaars nog zelf de persistentie regelen, met de introductie van versie 3.0 is dit te realiseren door enkele eenvoudige aanwijzingen in de Java-code op te nemen. JBoss Portal 2.0 maakt het mogelijk zogenaamde portlets te maken, wat kleine interfaces van programmas zijn die de eindgebruiker kan combineren in een portal. Portal 2.0 implementeert de JSR 168-standaard om dit te realiseren. De kosten voor dit alles zijn theoretisch gezien beperkt, aangezien vrijwel alle producten van JBoss open source zijn. JBoss genereert inkomsten door service en trainingen te geven voor zijn producten.

Reacties (25)

Ik ben zelf ook java ontwikkelaar en ik wil eigelijk steeds meer van JBoss af. EJB3.0 is al een stuk beter en lichter dan 2, maar het is nog steeds log als je kijkt naar bv Spring icm Hibernate.

Ik gebruik dus erg weinig van de features, en eigelijk is jboss dan eigelijk een continue bron van irritatie en ergernis. De prijs betalen voor een complexe omgeving, waar je nog geen fractie van de functionaliteit gebruikt.

Tomcat|Jetty Hibernate Spring en Acegi.. voor standaard webapplicaties ben je toch niet meer nodig.

In de meeste gevallen is een persistentie layer (hybernate/ojb) samen met een "model2" layer (spring/struts) wel genoeg. Pas als je gedistribueerde transacties gaat doen komt de kracht van j2ee naar voren.
Denk hierbij bv aan het koppelen van een webshop aan paypal en upc, alles binnen 1 transactie en als er bv geen postbode beschikbaar is dan wordt alles ook terug gedraaid.

Ik heb geen problemen met alle elementen van j2ee.. voornamelijk wel ejb.

En distributed transactions zijn geen onderdeel van ejb. Met spring heb je trouwens een abstractie voor het transactie mechanisme dat je gebruikt.. vanuit de applicatie zie je niet dat je werkt mbv hibernate zijn transactie support.. of dat je werkt met JTA.

Distributed transactions zijn wel makkelijker wanneer de transactions worden gehost in JBoss, dus dat je JBoss als DTC gebruikt. Natuurlijk moet je bij de distributed transactions met externe resource managers een coordinator gebruiken en dat zal geen JBoss zijn.

Toch denk ik dat menigeen wel loopt af te geven op application servers, maar vergeet niet dat een application server essentieel is voor een distributed application, bv een BL tier over meerdere servers, want alleen dan haal je cross-machine object awareness en dus kun je object caches maken die wel safe zijn.

@Otis: damn, dat is een stukje tekst waar ik werkelijk geen snars van begrijp, volgens mij voor het eerst in zoveel jaar

Verder is EJB imho een verkrachting van de menselijke geest. Het is geen middel om je creativiteit te uiten maar een dwangbuis waar je door moet worstelen om ergens te komen.

Software ontwikkelen is al lang niet meer een kwestie van creativiteit, of zou dat in ieder geval niet moeten zijn. Om kwaliteit te leveren met voorspelbare oplevertermijnen, beperkte budgetten, steeds grotere complexiteit van software systemen en grotere mate van bedrijfs kritisch zijn van software moet je software ontwikkelen op basis van herhaalbare handelingen, methodes, processen en daardoor herhaalbare resultaten.

Programmeren was vroeger een zeer creatief, soms zelfs artistiek beroep, waarbij je met de grootste lol quick hacks maakte en heroische staaltjes code produceerde. Veel ontwikkelaars uit die tijd zullen met lede ogen zien dat programmeren steeds meer lopende band werk is geworden en nog meer zal worden, puur omdat dat de enige weg is naar de gewenste resultaten. "Heroic programming is not a sustainable business practice" ... steeds minder, ten minste.

En zeg nou zelf, zou jij je huis willen laten bouwen door een stel kunstenaars, die tijdens de bouw nog allerlei beslissingen moeten gaan nemen over hoe ze het gaan bouwen? Of heb je liever dat er een team ontwerpers dat eventueel iets artistiek met de vormgeving omgaat, maar verder gewoon een kwalitatief huis bouwt op basis van simpele, bewezen, niet-creatieve methodes en technieken, die simpel herhaalbaar en reproduceerbaar zijn?

Het soort opdrachten waar ik mee bezig ben is wel een flink stuk creativiteit nodig. Maar om even terug te komen op een 'vast' ontwikkel proces.

Ik ben het met je eens. Maar als je steeds grote kunstgrepen moet voor dingen die relatief eenvoudig zijn, en bepaalde oplossingen niet gebruikt mogen worden (je moet dus verplicht een stuk functionaliteit links laten liggen) dan ben je gewoon verkeerd bezig. Verder moet je extra werk gaan verzetten om ergens te komen terwijl het gewoon niet nodig is. Het enigste wat ik van EJB handig vind zijn stateless session beans. Maar met het declaratieve transactiesupport van Spring heb ik hier zelfs geen behoefte meer aan. En verder maak je imho met EJB gewoon erg slecht geschreven software. Met een degelijke IOC container ben jij weer 100% in charge ipv je altijd te moeten vergrijpen aan allerlei totale bagger oplossingen (bv altijd JNDI gezever om aan referenties naar objecten te komen)

Bij de meeste dingen die Sun maakt vraag ik me steeds meer af hoe handig het voor kleine software bedrijven is. Enorm uitgebreide en gecompliceerde specs.. log en groot ontwikkel traject.. Ik kies daarom ook vaak liever voor niet Sun oplossingen..

JDO/EJB-CMP -> Hibernate
EJB -> Spring
JNDI -> veel gevallen niet nodig.. IOC container is je vriend.

En ik ben bezig met een lightweight channels implementatie als alternatief voor JMS (zonder de remoting). Message channels zijn al een vrij oud idee (pipes filters onder unix bv) en ik ben dit principe vaak nodig binnen 1 enkel applicatie. Ipv dat ik meteen naar iets zwaars als JMS wil grijpen, wil ik een lightweight oplossing die perfect doet wat ik zeg.. en tot in de allerkleinste details te configureren valt, en die ook helemaal naar mijn hand te zetten is.

Link
http://members.home.nl/peter-veentjer01/index.htm

Staat er nog maar een paar dagen.. en ik moet het nog 'echt' opensource maken.

"The right tool for the job" geldt natuurlijk nog steeds. Weinig aannemers zullen een ingewikkelde constructiemethode gebruiken voor het schuurtje in de achtertuin, terwijl het voor de bouw van een woontoren wel geld en tijd zou kunnen uitsparen.

Aan de andere kant zijn sommige developers soms te lang bezit uit te zoeken welke hamer nou het best is om 1 specifiek soort spijker in 1 specifiek soort muur te slaan, waar feitelijk iedere hamer voldoet. Zoek dus niet naar de perfekte maar gewoon naar de eenvoudigste goede (of voldoende) oplossing.

Voor mij toch maar dat artistieke dan. Ze moeten wel over gedegen technische kennis beschikken, maar verder een redelijk vrije hand krijgen. Dan kunnen ze innovatief bezig zijn.

Dan kunnen ze innovatief bezig zijn.

Dat doen ze maar lekker in hun eigen tijd... en geld graag. Innovativiteit is voor commerciele organisaties nooit het primaire doel.

Het wordt tijd dat er een fatsoenlijke GUI designer komt voor J2EE. Het is een middeleeuws om nog je UI componenten met code in je applet of application te verwerken, wat zo'n beetje iedere Java IDE van je wil. Met VS.NET is dit vele malen gemakkelijker. Je plaatst het component op je workspace, en je gaat je component verder programmeren.
De GUI IDE's die er zijn (bv SlickEdit of XUI for netbeans) zijn buggy, en integreren niet fatsoenlijk in de IDE.

Het hangt er maar net van af welke mate van controle je wilt. Over java ide's gesproken, bijna iederen ide heeft wel een wysiwyg gui editor, ecipse (plugins) / jdeveloper / together etc hebben ze iig wel.

NetBeans is al lang de beste gratis Java IDE wat betreft wysiwyg GUI ontwerp. En er wordt gewerkt aan nog veel beter: Sun werkt aan een manier om de voordelen (vnl. resizability) van layout managers (een sterk punt van Swing) te koppelen aan het quick'n'dirty ontwerpgemak van absolute layout (het voordeel van de Visual Studio).

Er is reeds een architecture die bepaalde componenten voorziet bij de J2EE ontwikkeling namelijk JavaServer Faces (JSF). Deze voorziet standaard UI en maakt het ontwikkelen van deze componenten aangenaam.
Op volgende site zal je meer info vinden over JSP + ook over verschillende Java Open Source producten.

http://www.javapolis.com/confluence/display/JP04/Extending+JavaServer+ Faces

Dat is toch voor web-widgets, dus voor zaken als een Button of een Link of een EditBox op je webformulier?

Ze hadden het volgens mij over GUI development voor client applicaties, a la Delphi. (.NET lijkt trouwens erg veel op Delphi, qua IDE features)

Wel grappig dat sommige mensen nogal af zitten te geven op de persistence in EJB en roepen dat Hibernate net zo goed is, terwijl Hibernate (Annotations) juist de persistence layer is in JBoss.. wat is het verschil dan?

Vreemde manier van vergelijken.

EJB-CMP is iets totaal anders dan Hibernate en daarop is het commentaar gegeven. Dat JBoss nu ook Hibernate ondersteund (alhoewel ik me afvraag wat JBoss toe voegt aan het nieuwe annotations gedeelte van Hibernate 3.0 zelf) is alleen maar een goeie zaak.

Verder is Hibernate niet 'de' nieuwe persitancelayer van EJB 3.0 en het is zeker niet 'de' persistancelayer van EJB 2 (want dat is EJB-CMP)

EJB-CMP is iets totaal anders dan Hibernate en daarop is het commentaar gegeven.

Neen. In EJB < 3 misschien wel, maar in 3 niet. En dit gaat over 3.

Dat JBoss nu ook Hibernate ondersteund (alhoewel ik me afvraag wat JBoss toe voegt aan het nieuwe annotations gedeelte van Hibernate 3.0 zelf)

Heh. Hibernate Annotations is een implementatie van CMP zoals dat in EJB3 gedefinieerd is. Vandaar ook dat JBoss het gebruikt. ('t lijkt alleen zo weinig op CMP in eerdere EJB versies dat ik niet geloof dat ze nog de kreet CMP gebruiken om verwarring te voorkomen.. maar het is en blijft gewoon container managed persistence)

Ik betwijfels dat het een implementatie is van CMP, eerder dat er een mapping plaats kan vinden tussen de annotations van Hibernate en wat EJB nodig heeft.

Maar via je 1e opmerking probeer je een beetje de draak te steken met mensen die commentaar leveren op EJB-CMP en dat terwijl Sun zelfs hun eigen EJB-CMP (uit ejb 2.0) implementatie dropt voor iets anders (dus zelfs door Hibernate gerealiseerd kan worden).

Ruudjah, er is inmiddels wel een fatsoenlijke GUI designer voor J2EE. Ik ben toevallig deze week op cursus om dit te leren. Het gaat over Oracle ADF, die 100% compatible is met de J2EE standaard. Je hebt hier wel de IDE van Oracle zelf voor nodig, genaamd JDeveloper. Maar hierin kan je dus op een visuele manier je Business Components laag, en je MVC lagen in elkaar klikken met de muis.
Het is allemaal vrij uitgebreid, je kan in iedergeval hier er wat meer over lezen
http://www.oracle.com/technology/products/jdev/index.html

Ik werk alweer een aardig tijdje met JBoss ... en heb hier ook al het een en ander aan Hibernate voor bij zien vliegen. Het heeft allemaal zijn voordelen en zijn nadelen. Het grote voordeel van JBoss lijkt mij toch wel dat het een complete J2EE server is die niets kost met bijna alles erop en er aan. Het nadeel het is zwaar en log en vaak overkill. Hibernate is volgens mij onderdeel van de volgende generatie JBoss (JBoss 4.x) en is niet een application server maar volgens mij alleen een Database naar Object mapper. Dat mapping kon je ook al doen met behulp van Container managed Entity beans en dat hebben ze dus nu nog maar een keertje overnieuw geschreven en Hibernate genoemd. Dat zou dan makkelijker en minder werk moeten zijn. Voordeel: je hoeft alleen nog maar 1 klasse te schrijven. Nadeel: je moet weer tig XML bestanden schrijven waarvan het formaat in een kommisch DTD bestand beschreven is of vaag gedocumenteerd op het internet. Die worden dan met behulp van de reflection api van sun samengebrouwd en aan de achterkant komt gewoon good old plain SQL eruit. Daarbij moet voor elke Database type weer nieuwe code geschreven worden omdat ze destijds de SQL standaard zo belabbert hebben vast-gelegd. Over 5 jaar is de XML hype voorbij dan moet alles met AOP gebeuren. Op dit moment doen we al lekker veel AOP in Java, maar in de toekomst gaat AOP overal zijn intrede doen, bijv AOP over XML of AOP over SQL statements. In toekomst wordt het dan mogelijk om alles ... maar dan ook echt alles in 1 bestand te stoppen dat dan eindigt met de extensie .html

Laten we wel wezen .. distributed transactions gebeuren misschien bij de bank en bij nog wat andere grote bedrijven, maar 99% van de bedrijven gebruikt het niet of heeft het niet nodig. Alle voorbeelden betrekken zich op een dierenwinkel (pet-store) of op bank-transacties. Ik heb nog geen enkele X-Box, Playstation of Nintendo SQL zien uitvoeren laat staan dat die iets met Hibernate, JBoss,... doen

conclusie: de IT heeft er in de software ontwikkeling gewoon een enorme chaos van gemaakt, omdat daar het meeste mee te verdienen valt. Als alles netjes, goed gedocumenteerd en logisch geprogrammeerd zou zijn zouden elk project 2x zoveel mensen nodig hebben en zou de winst 2x zo laag zijn. Ik loop dus vrolijk mee met de rest, maar besef in ieder geval dat alles wat ik bouw ook gewoon rotzooi is

Wat een treurig hoog aantal J2EE amateurs zie ik hier toch voorbij komen. J2EE biedt 10tallen voordelen over de lightweight oplossing die hier aangehaald worden. Heeft iemand hier ooit wel eens te maken gehad met gedistribueerde applicaties?
Begrijp me niet verkeerd, maar het blijft een kwestie van "the right tool for the job". Met de spring/hibernate oogkleppen op zul je het grotere plaatje nooit begrijpen, maar het is wel positief dat mensen zich realiseren dat het overkill kan zijn om bijvoorbeeld EJB/JMS te gebruiken.
Voor wat betreft J2EE IDE.. WTF!?!?! Hebben jullie dan absoluut en helemaal geen kaas gegeten van J2EE?! Wat doen IDE componenten in een serverside framework als J2EE?
Als er gedoeld wordt op een soort BeanBox die zou kunnen helpen bij het aan elkaar knopen van de EJB/JMS en andere zaken (voor al die mensen die een JNDI iets erg moeilijks vinden) vind ik het prima (JBuilder doet t wel aardig).
Als je het hebt over text invoerveldjes in je client applicatie en de persistentie van de ingevoerde data: ga VB coden ofzo!

>>Wat een treurig hoog aantal J2EE amateurs zie ik hier toch voorbij komen.

Een goed begin. Eens kijken of je het ook waar kunt maken.

>>J2EE biedt 10tallen voordelen over de lightweight oplossing die hier aangehaald worden.

Zoals? Voor distributed transactions ben je niet een volledige applicatieserver nodig zoals JBoss. Ik heb geen problemen met distributed transactions.. alleen met omgevingen met te veel troep wat ik niet gebruik en voor te veel problemen zorgt: classloader problemen/ memleaks by het deployen/volledig nieuwe tomcat erin bij een minor version change die je hele applicatie overhoop gooit. En verder heeft JBoss nog een gigantische lading eigen troep dat ik niet gebruik.

>>Heeft iemand hier ooit wel eens te maken gehad met gedistribueerde applicaties?

Ja. Voor eenJTA implementatie zit je niet vast aan een applicatieserver. En met Spring krijg je (uiteraard) een volledige abstractie van het transactie mechanisme waarme je net zo eenvoudig JTA als Hibernate zijn standaard transactie coordinator kunt gebruiken.

>>Begrijp me niet verkeerd, maar het blijft een kwestie van "the right tool for the job". Met de spring/hibernate oogkleppen op zul je het grotere plaatje nooit begrijpen

Volgens mij begrijp jij het hele plaatje dan nog niet. Ik zie niet in waarom Hibernate een inferieure oplossing zou zijn tov EJB-CMP of Spring tov EJB, of een degelijke IOC-container tov JNDI. Kan je dit eens beter onderbouwen. of kan ik misschien beter vragen: heb jij uberhaubt wel een idee wat Spring bv is en zit jij vast in een heel klein denkwereldje?

Verder zijn trouwens nieuwe ontwikkelingen van Sun redelijk gebaseerd op 'lightweight' ontwikkeling die al een tijd bestaan. Sun ziet zelf ook wel in dat hun oplossingen vaak lomp en log zijn en dat er een betere en snellere manier van ontwikkelen moet bestaan.

>>Voor wat betreft J2EE IDE.. WTF!?!?! Hebben jullie dan absoluut en helemaal geen kaas gegeten van J2EE?! Wat doen IDE componenten in een serverside framework als J2EE?Als je het hebt over text invoerveldjes in je client applicatie en de persistentie van de ingevoerde data: ga VB coden ofzo!

Het schijnt dat sommige mensen wel eens forms en dat soort zaken moeten maken. En alhoewel ik erook niet echt van gesharmeerd bent, zijn er veel mensen die zo willen werken en dat heeft niets te maken met vb of welke andere clientside taal dan ook.

Ik heb niet de indruk dat jij je kritiek waar hebt kunnen maken. Het getuigd imho van een stuk ontwetendheid.

JBoss maakt J2EE-ontwikkeling makkelijker

Sorry, maar die titel deed me echt denken dat het om een advertorial ging... Iets genuanceerder mag best.