|
|
||||||||||||||||||||
| Home > SOA News > Getting the most out of a J2EE platform | |
| SOA News: |
|
||
Market Analysis 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 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 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 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 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.
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:
'); // -->
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
| About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
|
|||||||