http://www.ibm.com/developerworks/websphere/techjournal/0805_knutson/0805_knutson.html
Date: 14 May 2008
Java EE technologies, present and future
The remainder of this article looks at specific technologies included in the Java EE platform and their expectation for change:
- Servlets
Servlets should be a fairly stable technology at this point, mature and fairly well understood. Other than addressing Web 2.0, there are no significant changes expected. Of course, that's not to say that there won't be any changes:
-
Java EE 5 addressed some of the usability problems in the platform by permitting metadata to be embedded in component source code. The servlet specification did not take full advantage of this and so it is expected to do so. However, this should only add additional forms of metadata rather than changing any behavior.
-
Another major change in Java EE 5 is the integration of the expression language between JavaServer™ Faces and JavaServer Pages, but this integration was designed to be backward compatible and should present no major issues.
-
One possible future change is metadata scopes. Servlets tend to declare metadata at a module level and share it among all Web components. EJBs tend to declare metadata at the component level. This is expected to evolve to enable both component and module scoped forms of metadata. Again, this is not expected to cause any incompatibility as the existing scope behavior should be maintained.
-
Another possible area of change is adding programmatic APIs to dynamically define behavior rather than defining it declaratively. SOA seems to be pushing this style and it is likely that all technologies will adopt both a declarative and programmatic behavior model at some point, if they haven't already. For the most part, this should not cause any incompatibility. The only possible exception would be adding methods to interfaces that must be implemented by applications. Given the current trend in the industry of getting away from explicit interfaces (and using annotated methods instead), this is not expected to be an issue.
-
- JavaServer Pages (JSP) and Java Standard Tag Library (JSTL)
JSPs and JSTL are also fairly stable technologies at this point, with no significant changes expected.
- JavaServer Faces (JSF)
JSF is still a relatively new technology. JSF is undergoing a major revision for the next round of specifications with an expected integration between JSF managed beans and Enterprise JavaBeans™. The risk of changes affecting existing applications will be higher here than with other presentation technologies. IBM does have representation on the JSF expert group and will keep a watchful eye out for problems.
One area of future concern is be how well Ajax support in JSF will follow the specifications for the OpenAjax Alliance. Through its participation, IBM will try to ensure that compatibility is maintained as the standards move forward. Ajax support in JSF will be new (when it appears) and use of that feature will be at a somewhat higher risk than other parts of JSF. More details will be known in early 2009.
- Portlets
Although not part of the Java EE platform, IBM WebSphere Application Server V6.1 and later provides the ability to utilize portlets. The portlet specification is currently undergoing a revision, but IBM is the specification lead and has a level of control over its evolution.
Version 2.0 of the portlet specification is a major revision that adds features omitted in Version 1.0, like coordination of resource serving, and leads the Java Portlet specification toward a path of maturity. Changes likely for later versions will mainly be to align with changes in other Java EE specifications, such as Servlet 3.0 or JSF 2.0, but they are not likely to include major new functionality on the portlet side.
At the time of this writing, Version 2.0 of the Java Portlet specification appeared to be source and binary compatible to Version 1.0, and switches were to be added for controlling underspecified Version 1.0 behavior that is now specified in Version 2.0. This compatibility assertion will be validated once the specification is finalized and sufficient testing has been performed.
- Enterprise JavaBeans (EJB)
The EJB specifications have added new capabilities over time, but have done so in an upward-compatible way. The EJB 3.0 specification changed the EJB programming model syntax in a fairly dramatic way. However, the older 2.1 and prior programming models are still available, and even the 3.0 programming model contains backward compatibility support, enabling clients and server components to be implemented with different versions of the specifications.
-
Session beans are fairly stable at this point and no substantial behavior changes are expected, although new functions are likely to be added.
-
Message-driven beans are also fairly stable.
-
CMP/BMP persistence is stable, but is likely to be deprecated in favor of Java Persistence APIs (JPA) as a relational persistence technology, or the Java EE Connector Architecture (JCA) for non-relational persistence.
-
One possible change that might affect this in the next round of specifications is the potential to bring session and message-driven beans together, into a single component style with both synchronous and asynchronous interaction styles. Given the last revision of the specification, it is reasonable to expect sane and compatible evolution here as well.
-
- JDBC
JDBC is quite stable at this point, offering a good long term investment in performance and compatibility, assuming you do not change your database vendor; a database vendor change might require changes in the SQL statements or in the locking and isolation levels you use.
- Java Persistence APIs (JPA)
JPA is the technology slated to replace EJB CMP Object/Relational Mapping support in the Java platform. This is a new technology and so further evolution is expected. However, it is also based on multiple vendor implementation experiences (Hibernate, TopLink, and Kodo) and therefore the risk of change causing incompatibilities is somewhat reduced. JPA provides some isolation from JDBC vendor differences.
- Java Message Service (JMS)
JMS has changed little in a long time and is considered a stable technology.
- Java EE Connector Architecture
The Java EE Connector Architecture has been stable for some time, but has some issues that will be addressed in the next round of specifications. The current architecture does not address failover or inbound and outbound consistency; vendors have had to rely on extensions to handle these issues. Changes in the specification to address these and other problems are planned to be compatible, but could eventually affect custom-written resource adapters. Adapters purchased and maintained from other vendors should hide any affects (if any) of those changes.
- JavaMail and JavaBeans Activation Framework (JAF)
JavaMail's evolution has been somewhat quiet, possibly because there is a smaller percentage of developers using it than, say, servlets or EJBs. This architecture tends to have more implementation classes that could be affected by evolution, making it more difficult to evolve and maintain source compatibility. However, in general, it appears to be mostly stable at this point and no changes are currently foreseen. JAF is used for MIME type handling and is generally considered as stable as JavaMail.
- Java API for XML-based RPC (JAX-RPC)
JAX-RPC is likely to be deprecated in Java EE 6, and therefore any new development needs to consider the option of using:
- JAX RPC: a technology that is stable, but does not work for all cases and will be going away, or
- JAX-WS: a new technology that is likely to change, but is a reflection of where the industry is moving.
- Java API for XML Web Services (JAX-WS)
JAX-WS is the second generation of a Web services API, taking strategic precedence over JAX-RPC. It was defined as a new technology in order to avoid backward compatibility issues that would have hampered the evolution of the specification. There have already been some issues around the evolution of JAX-WS, due to decisions of the W3C standards committees, that have led to revisions removing the support of some requirements of the specification. The Web services area is likely to evolve even more. Currently, there is a desire to standardize the qualities of service related to a Web service (such as reliable messaging or transactions), in addition to a focus on RESTful Web services (via JAX-RS – JSR 311). All of this is still relatively new and shakeouts are likely to occur as the industry gains more experience in these areas.
From a maturity perspective, JAX-WS has benefited greatly from the JAX-RPC experience. The lessons learned from JAX-RPC and fed into JAX-WS have produced a reasonably effective and mature specification. The inclusion of both JAX-WS and JAXB in Java SE 6 (the JDK/JRE) will likely stabilize these technologies even further.
- Java Architecture for XML Binding (JAXB)
JAXB is also new, but similarly evolved from the previous JAXB 1.0 delivery. Combining that experience with leveraging input from JAX-RPC and JAXB's inclusion into JAX-WS, JAXB is better positioned in its second release (like JAX-WS is over JAX-RPC) to be a stable and compatible technology. While it maintains the same name as its predecessor, its implementation and much of what it is trying to accomplish has been rewritten based on lessons learned from its past deficiencies. It could evolve further as the platform tries to address more consistent mappings between Java objects and other representations, such as protocol marshalling or persistence. Expectations are that backward compatibility will be maintained for those mappings.
- SOAP with Attachments API for Java (SAAJ)
SAAJ is a fairly stable rendering form for Web service messages. Apart from its extension of leveraging standardized DOM APIs, it has undergone little change since its initial release.
- Java API for XML Registries (JAXR)
JAXR is another technology that was introduced and adopted by the Java EE platform too rapidly. JAXR was based on providing an abstraction over UDDI V2 and ebXML V2, but V3 versions of those standards were produced almost simultaneously, rendering JAXR somewhat obsolete out of the gate. The industry is still evolving in this space somewhat, so any further evolution of JAXR is also likely to be out of date when complete. Once the industry settles down a bit, JAXR will likely either evolve dramatically or be replaced by another technology.
- Java EE Management
Java EE Management has been fairly stable and its stability is expected to continue.
- Java EE Deployment
This technology should be avoided, as it is insufficient for the task and is likely to go away or be replaced by a substantial revision in the future.
- Java Authentication and Authorization Service (JAAS)
JAAS provides the core of security services for the Java EE platform. It is generally stable, but there are known differences in behavior across vendors regarding JAAS subject propagation. This will attempt to be clarified in a future Java EE platform specification so that industry consistency may be achieved.
- Java Authorization Contract for Containers (JACC)
The changes in Java EE 5, enabling metadata declarations via annotations, have required changes to JACC to enable the handling of annotated security declarations. JACC 1.0 providers are not likely to be able to provide appropriate security behavior with security annotations in use, although existing applications that do not use annotated security declarations should continue to run fine.
Of course, the future is uncertain, but you can expect some technologies to continue influencing the Java EE platform. The technologies listed below should be approached with caution from a compatibility standpoint, since it is likely that they will evolve dramatically.
- JAX-RS - RESTful services
The industry has recognized that it is not always efficient to have a formal Web service for loosely coupled services. However, this is new for the industry and not a lot of experience has been built up yet around this hot topic. As best practice patterns emerge, it can easily be imagined that the specification could change dramatically.
- WebBeans
The Java EE 6 content proposal includes the addition of a new technology called WebBeans. Originally proposed as a way to integrate JSF managed beans and EJBs, it has since evolved into a distinct component model meant to encompass many other component models. There is very little experience in this space (although WebBeans was intended to be modeled on JBoss Seam, it has gone well beyond that experience). The closest example might be to look at the years of deliberation that went into producing the first SCA specification, which also serves as a component model that encompasses many other component models. Unless the scope of WebBeans is reduced dramatically in the near future, its specification is likely to evolve dramatically.
- Timer and Workmanager
These specifications drive enterprise qualities of service into asynchronous (that is, threaded) programming styles. They are based on joint work done by IBM and BEA (CommonJ) and have somewhat reduced risk based on multiple vendors having delivered these technologies, but these specifications have rebased the API on the Java Concurrency Utilities for threaded work management. It remains to be seen whether the industry will accept this or require additional changes, but the risk of their use is likely to be smaller than WebBeans. Using existing Asyncronous Beans APIs within WebSphere Application Server will provide the best long term stability and compatibility -- at least until these specifications stabilize.
1136
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
