Getting the most out of a J2EE platform
Most major enterprises have made their choice of application server, and many have even launched important projects based on this new infrastructure for executing transactional, secure business objects. The great majority of these enterprises have opted for the J2EE standard, with all the advantages and risks brought by adopting a new platform as a strategic component in an information system.
Our experience in major transactional projects means that we can now take a step back and look at vendors' sales pitches and the received marketing ideas. So how do we make the most of the functional and technical richness and potential of J2EE, without taking the slightest technological risk?
To answer this, we will need to start by explaining how J2EE technology is developed, looking at its complexity, highlighting those modules that have attained maturity and those that haven't. We shall then give our opinion on which parts of J2EE to use, and which to lose in mid-2002.
JCP ensures the functional richness and durability of Java
Sun, the inventor of Java, totally controls the Java(tm) brand and remains a very influential player when it comes to managing this industrial standard, offering protection against any attempted "hijack" by Microsoft.
In order to protect its progeny, Sun created and organized the "Java Community Process" (JCP), which takes the form of an international group governed by an "Executive Committee" (EC) in which influential players such as IBM, BEA and CISCO are represented - the first two being particularly powerful promoters and decision-makers.
The JCP organization ensures the richness and durability of the Java standard. The standardization process is kept democratic and transparent through the Java Specification Requests (JSRs). A member of the JCP can, at any time, submit a request to update of a particular aspect of Java. To do this, the requesting party must formalize and submit a JSR application, clearly explaining the objectives and methodology of the request. The JSR then enters a completely transparent, responsive review circuit.
Power and influence struggles do occur, but they do not have any major impact on the standard itself. On the one hand, the JCP organization makes sure that Java remains independent from the influence of powerful players, and on the other, Sun does not miss any occasion to demonstrate the force of its lethal weapon, which it has already tested with success against the enemy forces of Microsoft!
J2EE, richer and more complex then you might think
J2EE (Java 2 Enterprise Edition) standardizes transactional architecture based on the Java language. Vendors implement the J2EE standard and market it through J2EE application servers.
Put simply, J2EE standardizes the JDBC JSP/Servlets technology on the one hand, and EJBs on the other (see table at the end of this article "J2EE 1.3 specifications"). The EJB standard specifies, on the basis of a single technical structure, different types of EJB components designed to carry out different functional roles within a transactional J2EE architecture.
Within the EJB standard we find both Session Beans and Entity Beans. A session bean layer is generally used for managing an application session, and monitoring the navigation of an identified user. The session bean layer then hands over to the entity bean layer which implements business objects. These handle execution of management rules, consistency of transactions, security of execution of methods, database persistence, and so on.
Session beans can be "stateful" or "stateless". This means that they either do or don't manage a functional state (such as a list of parameters) between the different stages of the user's session. Entity beans may feature Container Managed Persistence (CMP entity beans) or Bean Managed Persistence (BMP entity beans). CMP beans bring complete transparency to persistence of business objects in a database, whilst BMP beans require specific development of this persistence layer (in JDBC for example) or need to call on an external technology to ensure persistence.
J2EE, what to lose in 2002
What is reassuring about a J2EE platform is that when a standard is simple and above all, adopted unanimously, it can be implemented in a completely standard fashion across all application servers.
The clearest example of this is JSP/Servlets/JDBC. This standard is perfectly well implemented by all market vendors. It is therefore quite possible to port JSP/Servlets/JDBC applications between market application servers.
The clearest counter-example is found in CMP entity beans. This standard is very young, and is certainly not unanimously adopted. The result is poor implementation, even with the most advanced, powerful application server vendors in the sector. What is more, the unanimity of CMP entity beans is contested by another standard, which is technically much simpler and yet functionally equivalent - Java Data Objects (JDO).
CMP entity beans still pose risks, in technical, performance and even durability terms, given the availability of other solutions such as JDO. Indeed, one of their main advantages - the standardization of automatic persistence mechanisms - still has functional and even structural weaknesses, and lacks maturity in implementations.
If it is absolutely necessary to implement Java applications that observe the object paradigm from end to end, we would recommend using proprietary business object persistence technologies from specialized vendors such as Versant or TopLink (Oracle).
J2EE, what to use right now
Clearly, The J2EE standard is structuring the technological foundations that will underpin the information systems of major firms in the future. The lessons that have been drawn from experiences in major transactional projects, now in production, are starting to take root.
The JSP/Servlets/JDBC has proved its merits in a number of major projects. It offers an excellent standard of performance and, above all, ensures portability between application servers. However, it does not offer all the features necessary to industrialize production and operation of applications in an enterprise. This drawback can be overcome by using Java frameworks such as Struts or by implementing Design Patterns such as DAO (Data Access Object) for persistence.
EJBs generally prove useful when it comes to standardizing and industrializing the techniques for developing and utilizing software components, but they also bring added complexity, cumbersome implementation, and are not without shortcomings in terms of maturity and performances.
Session beans and BMP entity beans may severely affect performances, but they do feature sophisticated characteristics that make them essential for implementing applications based on software components. By making considerable effort to acquire technical, design and development expertise, the risks of using session beans and BMP entity beans can be limited, and their functional richness exploited.
Opting for pragmatism: JSP/Servlets/JDBC + Frameworks
The options for J2EE adoption
Companies starting out with Java and wishing to begin J2EE development without taking risks in terms of technical aspects, durability, development scalability, or operability of applications, should certainly envisage intensive use of EJBs in later phases, and rely on JSP/Servlets/JDBC technology.
For enterprises with greater experience in Java technologies, we would recommend methodically applying strict standards, carrying out quality checks at all stages of the project, opting for training in software design, J2EE architectures, design and programming techniques, etc.
For more information on the performance of EJBs and other persistence solutions, you can consult our report: Strategies for persistence of business objects in J2EE architectures.
|JDBC 2.0 (Java DataBase Connectivity)||API for connection to relational databases|
|RMI/IIOP 1.0 (Remote Method Invocation / Internet InterOrb Protocol)||Remote component invocation mechanism|
|EJB 2.0 (Enterprise JavaBeans)||Server component model|
|Servlet 2.3||Web services extension API (equivalent to CGI)|
|JSP 1.2(Java Server Pages)||Server-side scripting API (equivalent to ASP or PHP)|
|JMS 1.0 (Java Message Services)||MOM connection API|
|JNDI 1.2 (Java Naming and Directory Interface)||Directory connection API|
|JTA 1.0.1 (Java Transaction Services)||Transaction management API|
|JavaMail 1.1||Mail sending API|
|JAF 1.0 (Java Activation Framework)||API for composition of complex emails|
|JAAS 1.0 (Java Authorisation & authentication services)||Security service management API|
|JCA 1.0 (J2EE Connector Architecture)||API for connection to legacy systems|
Copyright 2002 TechMetrix Research. TechMetrix is a technology-oriented analyst firm focused on e-business application development needs. TechMetrix is also backed by its parent company, a European global system integrator - SQLI - with more than 800 developers in the field.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.