From its inception more than a decade ago, the Java platform has matured considerably making it the preferred choice of many professionals & organizations for developing applications. In its most recent version for the enterprise -- dubbed Java EE 5 -- its designers have placed a special emphasis on doing more with less, so whether you're a seasoned expert or just starting out, it's likely you will find some fresh approaches that will simplify and ease your development efforts – this article takes a closer look.
Meta data is a powerful programming concept, one which allows developers to specify or alter application code behavior outside of the actual programming logic. In prior Java enterprise versions, this was achieved through XML files known as deployment descriptors; however, while this allowed for such behavioral customizations, it forced even the simplest applications to fulfill such a requirement whether they needed meta data or not.
In Java EE 5, meta data can now be embedded directly in application code -- a process known as attribute programming. What was once required to be specified in additional XML descriptors can now be accomplished with in-line declarations, providing a more streamlined development process -- users of an open source Java project named XDoclet can probably relate to this concept.
This is not to say XML descriptors are obsolete in Java EE 5, they are still very much valid. As a matter of fact, XML descriptors provide a secondary and overriding mechanism to any meta data that might have been declared within application code. In other words, a Java EE 5 application server will automatically take any behavior properties declared in a deployment descriptor over those embedded in Java byte-code.
It should be pointed out that attribute programming is not an exclusive addition to Java EE 5, but rather part of the Java standard edition 5(J2SE), an enhancement which cannot be underestimated, not only because standard support for attribute programming marks a shift in Java as a whole, but also because many other areas pertaining to Java EE 5 -- not just deployment descriptors -- can be enhanced using this same principle.
Annotations are very much open ended in terms of the functionality they can offer, making them ideal for pre-packaging any type of Java logic that might have been considered tedious in earlier Java enterprise versions. To cite a concrete example, let's take the case of data validation. In prior Java versions, data validation either entailed a substantial amount of scaffolding code or an ad-hoc framework -- say Struts -- to validate input. In Java EE 5, we can make use of Java annotations so our POJO's look something like the following listing.
Each of the previous annotations represents a particular behavior in an O/R design, with the backing logic and relational data bridging being executed by a Java EE 5 compliant application server, which in turn, allows organizations to choose among best-of-breed implementations based on a common standard, a point that can be especially important to those who have dealt with the fragmented/proprietary syntax used by commercial O/R vendors -- like Coco base -- and open source projects such as Hibernate.
Continuing with our discussion on the persistence API for EJB 3.0, another functionality that was factored into its design was the capacity to operate outside the context of Java EE containers, in effect creating a general purpose persistence API usable in standard Java environments(J2SE). As a matter of fact, it is a confirmed possibility by Sun that this same persistence API will be spun out of EJB 3.0 into its own working group/JSR. But let's not stray too far away from our main theme on Java EE 5.
Turning back to the previous code listing, you may have noticed we were dealing with a POJO, which is another addition to working with the whole gamut of components in EJB 3.0 -- not just entities, but also the new incarnations for session beans and messaging beans. Among the main advantages of using POJO's in Java EE 5, are two factors which go hand in hand: testing and simplicity.
Once relegated to the biggest enterprise projects, testing has become an integral part of the software development process with the popularity of agile principles; however, in the pre-3.0 EJB model, this process proved to be an elaborate endeavor at best. The reasons behind this complexity lied in both the container based environment required to execute EJB's and the inheritance hierarchy imposed by earlier versions.
With a container needed to manage middleware services inherent to EJB's -- such as transactions and security -- this required the replication and bootstrapping of a similar container to test the business logic behind an underlying EJB. And even though the use of such a testing container was technically feasible, what proved to be an even more difficult task was the actual creation of tests for a given EJB. This was due to the close-knit design around such container services enforced through an inheritance hierarchy.
In the pre-3.0 EJB world, every design was required to inherit behavior from an EJB base class to wire up middleware services. In Java EE 5 this requirement has been lifted, allowing the use of POJO's to be enabled as EJB's and in this same process ease the creation of tests, achieving a very clean separation between the middleware service required for EJB's and the actual business logic behind them. Take a look at the following listing which illustrates an EJB 3.0 session bean.
Notice how we use an annotation to wire up the EJB, but more importantly, how all of its methods are structured as a POJO, making the code testing process a simple step in the development life-cycle, and one which does not require intricate knowledge in setting up ancillary dependencies which were the norm in pre-3.0 EJB.
Java EE 5 -- just like its predecessors -- also has another major part in its architecture, one related to technologies on the web tier.
Created as a means for standardizing UI components, handling navigation, input validation and page events for web applications, JSF has had various implementations and tools circulating since early 2004, but to many in those early days, the appearance of JSF came with a sense of too little, too late or simply too late. Since JSF was neither designed to be a web framework nor a substitute for core Java web technologies -- Java Server Pages(JSP) and Servlets -- it created a certain misconception around its use, given that many developers were either just comfortable with the productivity provided by core technologies -- JSP's & Servlets -- or simply saw overlap in JSF compared to many of the Java web frameworks that appeared earlier.
With Java EE 5, JSF will officially be supported in every compliant application server, making it a powerful addition to the enterprise platform and a compelling one at that, especially with support for standardized UI components. With the appearance of web techniques like Asynchronous JavaScript and XML(AJAX), the bar for creating powerful web interfaces has only risen, so the capacity of mixing and matching pre-built UI components or Faces -- think widgets -- will probably become even more attractive to many.
Still, for those who may have worked with earlier JSF versions and experienced a certain conflict with the principles established by JSP's as a presentation technology, the version behind Java EE 5 -- JSF 1.2 / JSR 220 -- is specifically designed to align these particular issues while still remaining in-line with earlier JSF versions.
As far as other Java enterprise web technologies are concerned -- namely JSP's, Servlets and JSTL -- with the exception of a few minor additions and revisions, there are no new surprises with respect to earlier versions.
We have pretty much covered the major benefits behind Java EE 5, but we still have one more issue to address, how to actually take advantage of these features.
About the Author: Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics at http://webforefront.com
Annotations : Meta data & Descriptors
| POJO input validation | |
|---|---|
| Java EE 5 | Pre Java EE 5 |
public class User {
private String password;
@MinLength(5)
@MaxLength(20)
public void setPassword(String password) {
this.password = password;
}
public String getPassword() {
return password;
}
} | public class User {
private String password;
public void setPassword(String password) throws Exception {
if ((newPassword != null) && (newPassword.length() > 20))
throw new Exception();
this.password = password;
}
public String getPassword() {
return password;
}
} |
In Java EE 5, meta data can now be embedded directly in application code -- a process known as attribute programming. What was once required to be specified in additional XML descriptors can now be accomplished with in-line declarations, providing a more streamlined development process -- users of an open source Java project named XDoclet can probably relate to this concept.
This is not to say XML descriptors are obsolete in Java EE 5, they are still very much valid. As a matter of fact, XML descriptors provide a secondary and overriding mechanism to any meta data that might have been declared within application code. In other words, a Java EE 5 application server will automatically take any behavior properties declared in a deployment descriptor over those embedded in Java byte-code.
It should be pointed out that attribute programming is not an exclusive addition to Java EE 5, but rather part of the Java standard edition 5(J2SE), an enhancement which cannot be underestimated, not only because standard support for attribute programming marks a shift in Java as a whole, but also because many other areas pertaining to Java EE 5 -- not just deployment descriptors -- can be enhanced using this same principle.
Annotations are very much open ended in terms of the functionality they can offer, making them ideal for pre-packaging any type of Java logic that might have been considered tedious in earlier Java enterprise versions. To cite a concrete example, let's take the case of data validation. In prior Java versions, data validation either entailed a substantial amount of scaffolding code or an ad-hoc framework -- say Struts -- to validate input. In Java EE 5, we can make use of Java annotations so our POJO's look something like the following listing.
| Use of Entity API with O/R annotations |
|---|
@Entity(access=AccessType.FIELD)
public class AddressBook {
@Id(generate=GeneratorType.AUTO) long pk;
@ManyToOne Owner own;
@OneToMany(cascade=CascadeType.PERSIST) Set |
Continuing with our discussion on the persistence API for EJB 3.0, another functionality that was factored into its design was the capacity to operate outside the context of Java EE containers, in effect creating a general purpose persistence API usable in standard Java environments(J2SE). As a matter of fact, it is a confirmed possibility by Sun that this same persistence API will be spun out of EJB 3.0 into its own working group/JSR. But let's not stray too far away from our main theme on Java EE 5.
Turning back to the previous code listing, you may have noticed we were dealing with a POJO, which is another addition to working with the whole gamut of components in EJB 3.0 -- not just entities, but also the new incarnations for session beans and messaging beans. Among the main advantages of using POJO's in Java EE 5, are two factors which go hand in hand: testing and simplicity.
Once relegated to the biggest enterprise projects, testing has become an integral part of the software development process with the popularity of agile principles; however, in the pre-3.0 EJB model, this process proved to be an elaborate endeavor at best. The reasons behind this complexity lied in both the container based environment required to execute EJB's and the inheritance hierarchy imposed by earlier versions.
With a container needed to manage middleware services inherent to EJB's -- such as transactions and security -- this required the replication and bootstrapping of a similar container to test the business logic behind an underlying EJB. And even though the use of such a testing container was technically feasible, what proved to be an even more difficult task was the actual creation of tests for a given EJB. This was due to the close-knit design around such container services enforced through an inheritance hierarchy.
In the pre-3.0 EJB world, every design was required to inherit behavior from an EJB base class to wire up middleware services. In Java EE 5 this requirement has been lifted, allowing the use of POJO's to be enabled as EJB's and in this same process ease the creation of tests, achieving a very clean separation between the middleware service required for EJB's and the actual business logic behind them. Take a look at the following listing which illustrates an EJB 3.0 session bean.
| Session bean POJO in EJB 3.0 |
|---|
@Stateless
public class RateCalculator {
public int add(int a, int b) {
return a + b;
}
public int subtract(int a, int b) {
return a - b;
}
public int multiply(int a, int b) {
return a * b;
}
public int divide(int a, int b) {
return a / b;
}
} |
Java EE 5 -- just like its predecessors -- also has another major part in its architecture, one related to technologies on the web tier.
Web Tier : JSF and Co.
The web tier in Java EE 5 has not changed as radically as its EJB counterpart from earlier versions, but there are a few issues worth mentioning, such as the formal incorporation of Java Server Faces(JSF) into the Java enterprise mix.Created as a means for standardizing UI components, handling navigation, input validation and page events for web applications, JSF has had various implementations and tools circulating since early 2004, but to many in those early days, the appearance of JSF came with a sense of too little, too late or simply too late. Since JSF was neither designed to be a web framework nor a substitute for core Java web technologies -- Java Server Pages(JSP) and Servlets -- it created a certain misconception around its use, given that many developers were either just comfortable with the productivity provided by core technologies -- JSP's & Servlets -- or simply saw overlap in JSF compared to many of the Java web frameworks that appeared earlier.
With Java EE 5, JSF will officially be supported in every compliant application server, making it a powerful addition to the enterprise platform and a compelling one at that, especially with support for standardized UI components. With the appearance of web techniques like Asynchronous JavaScript and XML(AJAX), the bar for creating powerful web interfaces has only risen, so the capacity of mixing and matching pre-built UI components or Faces -- think widgets -- will probably become even more attractive to many.
Still, for those who may have worked with earlier JSF versions and experienced a certain conflict with the principles established by JSP's as a presentation technology, the version behind Java EE 5 -- JSF 1.2 / JSR 220 -- is specifically designed to align these particular issues while still remaining in-line with earlier JSF versions.
As far as other Java enterprise web technologies are concerned -- namely JSP's, Servlets and JSTL -- with the exception of a few minor additions and revisions, there are no new surprises with respect to earlier versions.
We have pretty much covered the major benefits behind Java EE 5, but we still have one more issue to address, how to actually take advantage of these features.
* Compatible Java EE 5 application servers
Like any other technology based on standards, Sun Microsystems requires that every Java EE 5 application server provider pass a series of compatibility tests in order to qualify as a certified vendor. The current list of compatible Java EE application servers include :- Apusic Application Server (v5.0), by Kingdee.
- NetWeaver Application Server Java EE 5 Edition, by SAP.
- Sun Java System Application Server Platform Edition 9, by Sun Microsystems
- JEUS 6, by TmaxSoft
About the Author: Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics at http://webforefront.com
No comments:
Post a Comment