J2EE 1.4 spec offers better Java/non-Java interoperability.
The Java application server market is about to go through another cycle of change with the imminent release of the J2EE 1.4 specification.
J2EE (Java 2 Enterprise Edition) compatibility is the sine qua non for any Java application server with enterprise ambitions.
Version 1.4 was released as a proposed final draft Aug. 22 and updates all three of the core Java application server standards to newer versions: EJB (Enterprise JavaBeans) 2.1, Java Servlet 2.4 and JSP (JavaServer Pages) 2.0. We covered the big changes in JSP 2.0namely, the expanded tag library and new expression languagein the Sept. 2 issue (see www.eweek.com/links
Once these specifications are approved, the next step is for Sun Microsystems Inc. to update its J2EE reference implementation and compatibility test suite. When this is done, third-party application servers can be tested and then certified as compatible; we expect to see J2EE 1.4-based products early next year.
The J2EE 1.4 specification mentions three areas that didnt make it into the specification but will be addressed in a future release: an audit API and auditing mechanism, access controls based on instantiated data in the class (content-based access control mechanisms), and a standardized way for users to register themselves with Web sites.
Web Services Support
The major change with EJB 2.1 is the ability to map a SOAP (Simple Object Access Protocol) 1.1 interface onto a stateless session EJB.
Currently, the only way to access EJB is from Java client applications using Javas Remote Method Invocation protocol or from CORBA (Common Object Request Broker Architecture) client applications using CORBAs Internet Inter-ORB Protocol.
With built-in SOAP support, developers will be able to access EJB-based business logic using any language with SOAP over HTTP (or Secure HTTP) support. The most immediate benefit will be much easier interoperability between applications written using Microsoft Corp.s development tools and the J2EE world.
The easier case of allowing EJBs themselves to call out to external components using SOAP is also supported.
Native Web services support is an area of catch-up for J2EE. Microsoft established an early lead in integrating Web service access APIs with back-end business logic, and its .Net Framework has great Web services support. A number of third-party products can wrap EJBs and other Java classes with a SOAP interface, but the lack of Web services support has become a clear feature gap in the current J2EE specification.
Also more capable is the EJB query language, an abstraction layer over SQL, thats used to manipulate entity beans. The EJB query language gains count, sum, minimum, maximum and average aggregate operators, and now supports an ORDER BY clause to return objects in sorted order.
Finally, EJB 2.1-compatible servers must provide a timer service that can run EJBs at scheduled intervals or at a particular time through a call-back.
Java Servlets change very little in the move from the current 2.3 to the proposed 2.4 specification.
Servlet deployment descriptor files have an updated format that allows developers to extend them with configuration data for their servlet. The format of deployment descriptor files is now defined using XML Schema instead of the old Document Type Definition format for better data typing. Servlets using Servlet 2.2- or 2.3-style deployment descriptor files are still supported.