Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Jan-Hendrik Kuperus at 0:44 on Thursday 13 December    Add 'JSR 318 – Enterprise Java Beans 3.1' site to delicious  Add 'JSR 318 – Enterprise Java Beans 3.1' site to technorati  Add 'JSR 318 – Enterprise Java Beans 3.1' site to digg  Add 'JSR 318 – Enterprise Java Beans 3.1' site to dzone

Na een zeer teleurstellende sessie met de lokkende titel: ‘Java Persistence – A heretic’s demonstration’, wat een slecht voorbereide demo van een third-party database was (InterSystems Cache), nam ik plaats bij het verhaal over de nieuwe specificatie voor EJB 3.1.

Onbekend als ik was met de EJB specificaties heb ik in dit uurtje een hoop geleerd over EJB 2.x en EJB 3.0 en heb ik een aardig beeld van waar de spec heengaat met EJB 3.1. Zoals ook al het doel was bij EJB 3.0, mikt JSR 318 op een versimpeling van de specificatie en dan met name voor de developer. Deze versimpeling zal op twee belangrijke gebieden het best te voelen zijn: ontwikkeling en packaging.

Met betrekking tot de ontwikkeling van EJBs worden op het gebied van de onwtikkeling de volgende verbetering voorgesteld:

  • Local Business Interfaces zullen optioneel gaan worden. Waar het nu verplicht is om een interface te maken van de public onderdelen van een EJB, zal deze eis bij de volgende spec vervallen. De motivatie hiervoor is dat het maken van een dergelijke interface meestal neerkwam op het kopieren van alle public methods naar een interface en deze te implementeren. In de toekomst is dit niet meer nodig, alle public methods worden standaard gezien als het lokale contract van de EJB. Maar, wanneer het nodig of wenselijk is om een aparte interface hiervoor te maken kan dit nog steeds op de oude manier. Let wel: de EJB container zal er nog steeds zorg voor dragen dat de client niet de werkelijke Bean instantie te pakken krijgt.
  • Invoering van Singleton Beans. In de volgende versie van de EJB spec is het mogelijk om een Bean als Singleton te declareren. Dit betekent niet dat er een instantie van de Bean in een cluster is, maar dat van een dergelijke Bean slechts een instantie is per applicatie per JVM.
  • Concurrency options. Waar in de oude standaarden concurrency control puur bij de container lag kan de ontwikkelaar vanaf EJB 3.1 invloed uitoefenen op hoe er bij een Singleton Bean wordt omgegaan met concurrency. Standaard wordt een dergelijke Bean behandeld als elke andere Bean. Dat wil zeggen dat hij maximaal door 1 Thread tegelijk kan worden benaderd. Bij Singletons kun je echter straks per methode definieren of deze concurrency constraint behouden moet blijven of dat deze niet van toepassing is. Mocht je bij een Singleton Bean vage dingen willen doen en de concurrency control zelf in de had willen nemen, dan kan ook dat vanaf EJB 3.1 met Bean-managed concurrency
  • Timer Services. Een belangrijke toevoeging aan deze service is het gebruik van calendar-based events. In de volgende versie van de spec is het mogelijk om met een syntax die lijkt op die van de Linux crontabs aan te geven dat bepaalde services bijvoorbeeld elke eerste dag van de maand moeten plaatsvinden. Dit staat in sterk contrast met de huidige situatie, waar je de relatieve tijd tot dat tijdstip moest bepalen en daarvoor een Timer aan moest maken. Bovendien worden dit soort calendar-based timers voortaan automatisch door de container opgestart en zijn er geen omwegen via ServletContextListeners meer nodig om Timers aan te maken.
  • Asynchronous Operations. EJB 3.1 gaat de ondersteuning voor asynchrone operaties uitbreiden. Hoe dit precies uitgewerkt gaat worden is nog niet beken, maar er werd gehint naar simpele Fire and Forget methodes en/of de nieuwe Java 6 Future<T> constructie.

Dan nog een schijnbaar klein, doch belangrijk punt omtrent het packagen en deployen van EJBs in de toekomst. Waar je in de oude situatie een *-ejb.jar en een *.war file samen moest pakken in een *.ear file, kun je vanaf EJB 3.1 de EJB files ook gewoon in de WEB-INF/classes map van je WAR-file zetten en zijn lastige constructies met EARs niet meer nodig. Dit heeft enkele gevolgen voor met name dingen als de Java Component Environment, die de EJBs dan nu binnen een WAR file moeten delen.

Tot zover de EJB 3.1 update. Morgen weer een ‘drukke’ dag voor de boeg… :)

–JH


© 2020 Java Competence Network. All Rights Reserved.