Friday, November 19, 2010

Devoxx 2010 daily notes: day four

Java EE Key Note: The Future Roadmap of Java EE

Java EE wil evolved to cloud platform and, to do so, it will needs modularity based on Java SE.

JSF 2.1

JSF 2.1 will propose:

  • transient state saving
  • XML view cleaning
  • targeted to HTML 5


JMS is an old specification, which need to evelove for addressing new communication layers:

  • resolving specification ambiguities
  • standardized vendor extension
  • integration with other specifications
  • integration with the web tier (websocket, JSON, NIO2)

JPA 2.1

JPA targets to improve standardization, flexibility and control of persistence context synchronization. The metamodel will be extended to ORM.

Several addition will take place in this release:

  • add event listener
  • outer join with ON conditions
  • update and delete query based
  • mapping between JPQL and criteria queries
  • DB and vendor function invocation
  • support stored procedure

The expert group will be done for january 2011, but the release date could be delay by J2EE timeline (modularity is waiting for Java SE 8).


JAX-RS 2.0 should be commited in december.

Actually, JAX-RS specification is not included into web profile.

A client API will be added:

  • low level builder pattern
  • high level response matching

JAX-RS will be adapted for MVC architecture based on JSP and Scalate.

Asynchronous, base on Atmosphere (HTTP streaming), will be too added with validation and injection. For exeample, @Context will be replaced by @Inject).

Comparing JVM Web Frameworks

In 2004, criteria to choose a web framework were:

  • request, component or RIA
  • stateful or stateless
  • project community
  • project futur
  • maintenance
  • technical features

And the choice could be described this way:

  • High traffic: request framework
  • Intranet: component
  • Products: products vendor

Now, in 2010, criteria are:

  • development productivity
  • developer perception
  • learning curve
  • project health
  • developer availability
  • job trends
  • templating
  • components
  • ajax
  • plugin
  • scalability
  • REST support
  • multi language
  • validation
  • books
  • doc
  • mobile
  • risk

After a comparison, to top five is:

  • Spring MVC (pro: configuration, integrtion, REST support; cons: instant reload)
  • GWT (pro: write in Java, easy to learn; cons: slow compilation)
  • Rails (pro: easy to learn, doc; con: performance, development tools)
  • Grails (pro: esay for Java programmers; cons: targeted to Java programmers)
  • Wiket (pro: for Java developpers; cons: no developpers available)

Standard DI with @Inject and JSR-330

CDI is a joined proposition from Google and Spring. It is resumed by five annotations and one interface.

@Inject identifies injectable members, that can be any visible fields (static or instance).

Injection order is:

  1. constructor
  2. fields
  3. methods

By default each time an injection must be done, a new instance is created.

@Qualifier allows to solve naming ambiguities by providing a way to create annotation to qualify a classe.

Interface Provide is a kind of factory where injection is not enough to create an object.

Guice and Spring Framework implements this JSR.

The Java Persistence Criteria API

JPA started with JPQL, a SQL like query language that can be used in static queries (@NamedQuery) and dynamic queries.

JPQL for dynamic query is:

  • String based: very easy to do
  • SQL like syntax
  • But it is String: risk of performance lost, lost of readability
  • No type safety

Criteria API is object based and typesafe (use of a metamodel).

CriteriaQuery are composite:

  • roots
  • join
  • expression
  • predicates
  • selections
  • ordering
  • grouping
  • method to assign: select(), multiselect(), from()
  • browse result: getSingleResult()

CriteriaBuilder: a factory of CriteriaBuilder for Expression and Predicate:

select c from Customer c;

TypedQuery tq = em.createQuery(Customer);

List resultList = tq.getResultList();

  • join -> root.join("orders");
  • where -> cq.where(cb.equal(root.get("...")).select(root)

There is hole in type safety in join and where: usage of string to specify attribute name.

The solution used by JPA is to generate at compile time a static metamodel (logical view).

Directly accessible via EntityManager.getMetamodel(), it is defined by a hierarchy of interfaces to describes types and attributes. So, browsing the metamodel is possible.

Now, it is possible to replace String in criteria by metamodel attribute or by accessing directly to the metamodel (path navigation).

Path navigation brings tha ability to access attributes of composite object: c.get(attribute_a).get(attribute_b). It is used to compound predicates.

CriteriaQuey is able to create subqueries and to call database specific function: cb.function("NAME", return_type, path);

Criteria parameters are created by using CriteriaBuilder and can be named.

Queries are modifiable.

HTML 5 Fact and Fiction

HTML 5 is mainly a collection of features.

It is actually better supported on mobile devices than on desktop.

HTML 5 is driven by mobile development. Developping a native application for each platform is too cheaper, we need a common platform, and this the web.

Feature detection can be done with Javascript and preferably by using library such as Modernizr.

Now, browser evolution is driven by specification. This can avoid a quirck mode where standard is more or less respected. HTML header file becomes:

HTML brings very feww components. So, developers uses external library, but there is no standard. HTML 5 comes with new input types. If they are not yet supported by browser, a text field is displayed. One of the target of such component is to brings facilities to mobile devices. For example, an email input field results to the @ symbol to be directly available on the keyboard.

It defines too things that are used from decades such as headers and footers.

It brings too:

  • autofocus
  • local storage: response to heavy cookie usage
  • offline mode: cache the application
  • microdata: semantic web
  • multithreading
  • geolocation (not part of HTML 5)

Activiti in Action

Activiti is a BPM open source tool , it is now mainly developed by Alfresco, but these are 2 distinct products, it is supported by SpringSource and Signavio. Activiti is based on the BPMN 2.0 standard, and the data can be persisted in an XML format.

Activiti allows you to model a process in BPMN 2.0 using “Activiti modeler” (from Signavio), or via an eclipse-based interface. At each step of the process, you can define who can execute the task, and define what are the information that should be filled in. Afterwards, you can initiate process instances, and each person involved will have access to the “activiti explorer” where he will have the possibility to fill in the required information. Once a process step is completed, activity notifies the next person involved that he has a task to do. The “activiti explorer” also provides analysts with process instances status and statistics (it is also possible to create easily a BIRT report about process instances report).

Activiti also provides other modules:

  • Activiti Probe (check process status)
  • Activiti Cycle (BPM collaboration platform)
  • iPhone client
  • Grails integration

Finally, Activiti is highly customizable and can be easily embedded into another application (you can, for instance, request to add a document into Alfresco at a particular process step using 5 lines of Java code …)

  • SpringSource provides an integration via a bean
  • A full query API provides access to the Activiti data
  • REST interface provided (used by an iPhone application

No comments:

Post a Comment