Nieuwe J2EE ondervindt drie maanden vertraging

Vnunet schrijft dat de volgende versie van Java 2 Enterprise Edition circa drie maanden later zal uitkomen dan oorspronkelijk gepland. Reden van de vertraging is de Web Services Interoperability-standaard (WS-I), die halverwege dit jaar zal verschijnen met steun van meer dan 160 softwarebedrijven wereldwijd. Sun wil deze richtlijnen verwerken in J2EE 1.4, waarvan de specificatie oorspronkelijk volgende maand zou verschijnen. J2EE 1.4 wordt de eerste release van de ontwikkelingstools die diverse protocols en standaarden op het gebied van internet en communicatie ingebakken heeft.

" align="right" vspace=5 hspace=5>WS-I gaat een aantal richtlijnen bevatten op dit vlak, en Sun vindt het belangrijk voor de softwarebranche dat er geen conflict bestaat tussen J2EE en WS-I. Het feit dat Sun wacht op WS-I moet ertoe leiden dat de Java-tools beter compatibel zijn met applicatieservers van bijvoorbeeld IBM en Oracle. Waarschijnlijk zal de vertraging geen schadelijk effect hebben op de Java-gemeenschap, omdat veel ontwikkelaars nog niet eens overgestapt zijn naar J2EE 1.3.

Reacties (20)

[Verwijderd]

ik ben geloof ik niet zo'n J2EE fan .. het enige waar ik op dit moment een beetje positief over denk is JINI ... maar ook daar heb ik mijn twijfels alweer over. Ik ken het wel niet 100%, maar waarom heeft het in hemelsnaam een web-server nodig (is dat niet een beetje ouderwets). EJB's snap ik sowieso al niet... wat moeten we met zulk een slecht gedocumenteerd stuk software (daar bedoel ik mee de verkoop van verhalen waar je dus niets aan hebt). Ik geloof dat ik overal weerstand tegen bied waarin het buzz-woord web of service in voorkomt.....

Niet dat het er zo veel toe doet wat ik denk over Java programmeurs , maar ik denk dat sinds de introductie van JDK1.2 eigenlijk alleen maar bullshit is uitgebracht..... (en ik ben dus zelf een echte Java programmeur).... iemand die dit kan weerleggen ????

[dvdhoek]

Als je enthousiast bent over JDK1.2, biedt J2EE wel degelijk een meerwaarde. J2EE stelt je namelijk in staat om (complexe) business logica te programmeren op een Java manier, terwijl je front end uiteindelijk een web browser is. Het fenomeen applet moet je hierbij buiten beschouwing laten, die hebben binnen J2EE eigenlijk geen rol. Een J2EE applicatie is opgedeeld in een aantal lagen, een JSP front-end, een Servlet laag die de submits opvangt en doorstuurt naar de EJB laag, die je uiteindelijke applicatie bevat. Een goeie J2EE applicatie bevat vrijwel geen code in de JSP en Servlet laag, ook vrijwel geen javascript. EJBs kun je gewoon zien als normale Java classes zoals je ze ook met JDK1.2 maakt, met als belangrijke verschil dat het remote objecten zijn die op de server draaien en eventueel gedeeld kunnen worden door meerdere client instanties.

[melgers]

In grote lijnen met je eens. Maar wel te simpel

JavaScript kan in mijn ogen wel degelijk erg nuttig zijn. Bijvoorbeeld voor eenvoudig input validatie en soms zelfs drag and drop in de Browser (dit is veel java/ECMA script). Tegenwoordig zie je hiervan echt sterke staaltjes. Jammer is het wel dat het dan vaak niet in alle browsers werkt.

EJB is niet per definitie de manier van data opslag/retrieval in een J2EE omgeving. JDBC is ook een valide methode. Of het handig is dat te doen in session beans is niet zo relevant, zelf objecten in de JNDI tree aanmelden werkt net zo goed.

Het domweg mappen van Entity beans op een al bestaand relationeel datamodel wordt zelfs als een anti pattern beschouwd (bron: core J2EE patterns, Sun MicroSystem press). Een goed relationeel model is niet per definitie ook het beste voor een EJB aanpak. Een fout die ik in de praktijk vaak gemaakt zie worden(en zelf ook maak(te)).

[dvdhoek]

Ik gebruik zelf entity beans ook niet (meer). De huidige productieomgeving waarop ik werk zijn ook niet verder dan EJB 1.0 en binnenkort EJB 1.1. We hebben nog wel even Bean managed beans geprobeerd, maar zagen er weinig voordeel in, en de performance is, indien de database ook wordt geupdate door niet-EJB applicaties, ook niet optimaal.
We ontwikkelen onze applicaties volgens het Session Façade pattern. Voor de database access gebruiken we stateless session EJBs. Stateless om het gebruik aan resources te minimaliseren en de performance te optimaliseren. Vanuit de session beans vinden simpelweg JDBC calls plaats, wat een entity bean uiteindelijk trouwens ook doet. Het gebruik van session beans biedt als verder voordeel dat je door het instellen van parameters kunt aangeven hoe met databasetransacties moet worden omgegaan.
Voor wat betreft JavaScript blijf ik van mening het gebruik zoveel mogelijk te beperken. Business rules horen in ieder geval niet in je front-end thuis, dit past ook niet in het Session Façade pattern. Zo kan een validatie of een bepaalde optelling hoger is dan een bepaalde drempel heel eenvoudig in Javascript, maar als het een business rule betreft, hoort ie daar niet. Daarbij is het lastig een grens te trekken als je een deel van de validaties in javascript doet, want wat is simpel en wat niet? Ik zie wel eens hele ingewikkelde scripts om een datum of een opgemaakt getal te parsen, terwijl je dat in Java in een paar regels code doet. Ook het al dan niet verplicht zijn van velden valideer ik liever server side. Dan heb je tenminste niet te maken met al die verschillende manieren waarop je de waarde uitvraagt van een object. Vergelijk maar eens het opvragen van een waarde van een combobox, checkbox, normaal inputfield, listbox en dan zit er inderdaad ook nog vaak verschil tussen browsers.
Ik ben het wel met je eens voor wat betreft zaken als drag and drop of bijvoorbeeld een mechanisme om waarden van de ene listbox naar de andere over te hevelen. Dit is namelijk interface en heeft niets met je business proces te maken.
En iets meer on-topic. Ik denk dat het uitstel zeer verstandig is, indien hiermee aan een standaard kan worden geconformeerd. Bedrijven zijn toch niet zo snel met het invoeren van een nieuwe J2EE omgeving.

[melgers]

Die webserver is nodig om class definitions remote te kunnen laden, eigenlijk net als bij Applets. Het discovery protocol is denk ik het meest herbruikbare van het toch wel geflopte Jini concept. JAXM(ook leuk) gebruikt iets dergelijks dat er verdacht veel op lijkt.

Persoonlijk vind ik dat er in sinds jdk 1.2 vooral op het vlak van performance veel winst is gebroekt. Ook het nog niet zoveel gebruikt non-blocking IO in de nio packages kan volgens mij application servers een kleinere footprint geven en betere performance.

Jammer vind ik dat er gekozen is voor een eigen logging API in JDK 1.4. Het lijkt op Log4j maar is het net niet.

EJBs zijn wel omslachtig en misschien alleen de moeite waard in een echt gedistribueerde omgeving. Als je echter goed zoekt is er zat goede documentatie over te vinden (oa de JBoss tutorial is prima). Qua coderen is het echter niet moeilijker dan normale code. Eerder makkelijker omdat je zaken als transacties en securitie achteraf middels de descriptor files kunt regelen. EJB 2.0 is een echte vooruitgang tov de vorige versie.

Voor kleinere toepassingen heb ik mijn hoop op JDO gevestigd (weet niet of dat in de volgende J2EE spec zal staan).

Weerleggen kan ik je argumenten niet echt. Ik heb wel eens Jini demos gemaakt waar vervolgens nooit wat mee gebeurd is. EJB en Web Services heb ik echter dagelijks nog mee te maken.

WebServices ondersteunen in de huidige standaard geen transacties. In mijn ogen dus niet geschikt voor echt serieuze toepassingen. BEA heeft hier een eigen proprietary oplossing voor bedacht. Eigenlijk vind ik het goed van SUN te wachten tot er een volwassen RFC is.

Tot slotte nog even dit. De afgelopen tijd heb ik de meest domme discussies over C# en Java gevolgd hier op Tweakers. Het niveau is soms stuitend. Neem je verantwoordlijkheid en doe geen statements over zaken waar je geen verstand van hebt. Daarmee bewijs je de Tweakers community geen dienst. Ik wijk tegenwoordig al weet uit naar amerikaanse sites.

[Verwijderd]

Wat ik me afvraag is of alle andere ontwikkelingen altijd worden tegengehouden als men met wat groots bezig is. Ik zit nl nu op J2SE 1.4.1, en ik wacht vol spanning op J2SE 1.5 omdat ik egt wel Generics nodig heb! Wordt de J2SE 1.5 ontwikkeling nu uitgesteld zolang J2EE 1.4 niet af is of hoe zit dat nou?

[Verwijderd]

De voorlopige datum voor J2SE 1.5 is pas medio 2004... Verder hebben J2SE en J2EE ook niet zo heel veel met elkaar te maken. Het een is de basis framework, het ander een enterprise framework dat bovenop dat basis framework draait. Als er al een afhankelijkheid is dan is die dus eerder andersom.

Het is imho ook helemaal niet erg dat deze standaard nu vooruit gepushed wordt. Veel van de J2EE ontwikkelingen zijn helaas nog steeds niet helemaal 1.3, dat gaat allemaal erg langzaam. Ik denk dat dat ook een belangrijke reden voor Sun is om nu niet met een 1.4 release nóg meer ruis te veroorzaken dan er al is in Java Enterprise land. Voor de mensen die geinteresseerd zijn in de ontwikkelingen die 1.4 brengen zal is er al een beta versie. Het is alleen maar goed dat WS-I dadelijk ook echt een serieus onderdeel is van de standaard, en niet een patch of upgrade, zoals hierboven geopperd wordt. Wat heb je immers aan een communicatiestandaard die optioneel is?

[BreeeZe]

Met wat research op www.ws-i.org kom je erachter dat microsoft 1 van de members is, zij hebben daar ook hetvolgende over te zeggen:

The cross-industry collaboration that led to the creation of WS-I is a very important step forward in advancing a systematic, consistent and standards-based approach to adopting and deploying new Web service technologies,” said Eric Rudder, Senior Vice President, Developer and Platform Evangelism at Microsoft Corporation. “The membership of WS-I shares a common vision of Web services as a critical way to cross the historical boundaries between platforms, applications and programming languages. The benefits and value of Web services for customers and partners cannot be overstated.”

Lijkt me dus niet dat ze dan: "een eigen interpertatie" erop na houden...

[Krankenstein]

Bij heel veel van dat soort dingen heeft de consument geen baat, maar daar lijkt Microsoft ook niet echt op uit te zijn (no offence). Da's natuurlijk hardstikke jammer.

Gelukkig doet Sun moeite om de standaarden goed toe te passen in plaats van gesloten "standaarden" te bedenken.

Zijn de standaarden waarover het hier gaat eigenlijk "open" standaarden of moet er geld voor worden betaald aan de bedenkers?

[Verwijderd]

Het gaat hier om de Enterprise Edition, daar gaat Microsoft zo ie zo geen eigen versie van maken. Microsoft maakt alleen eigen versies van de JRE.

[mxcreep]

Microsoft dit toepassen ???
Het gaat om een standarisering qua development platform, J2EE wordt gebruikt om transactionele systemen mee te bouwen...niet om je XP desktop traag mee te maken...
Het duidelijke verhaal van klok en klepel...maar goed daar hebben de meeste tweakertjes wel meer last van...

[FendtVario]

Misschien kunnen ze in die drie maanden wachten eens een paar probleempjes in java oplossen (zoals pas op tweakers stond) of iets doen aan de snelheid. Zou een goede zaak wezen.

[PommeFritz]

J2EE heeft /niets/ met Java zelf te maken.
J2EE is een verzameling Enterprise Standaards (transactions, databases, security enz) met bijbehorende reference implementaties.
Wellicht ben je in de war met de Java SDK / Java JRE?

[alfatrion]

Het is gebruikelijk dat bij een taal bepaalde zaken in de biliotheek zitten. De taal java is in drie smaken te krijgen, nl.: J2EE, J2E en J2ME. Het hangt een beetje af van je definitie van computer-taal. Voor vallen dit soort object als een collectie (java) of functies zoals sprintf (c) wel bij een taal.

[Hielke Hoeve]

Ik weet het wel zeker.

[Verwijderd]

Waarom brengen ze 'm niet eerst gewoon uit zonder WS-I ondersteuning om over een half jaar een update uit te brengen? Lijkt me toch wel ietsje makkelijker...

Maar goed, het is natuurlijk wel mooi dat Sun de standaarden graag wil aanhouden .

[Verwijderd]

Maar goed, het is natuurlijk wel mooi dat Sun de standaarden graag wil aanhouden.

Anders dan het inmiddels overleden dBase en WP. Elke versie kon niet met het vorige samenwerken.

* 786562 DrWolffenstein

[Verwijderd]

dBase is nog niet dood hoor
Het wordt alleen uitzonderlijk weinig gebruikt... net als WP