January 2002

Bill Shannon is a Sun Distinguished Engineer and Spec Lead for the Java 2 Platform, Enterprise Edition. Karen Tegan is Director of J2EE Compatibility and Platform Services for Sun Microsystems. In this interview, Floyd Marinescu of TheServerSide.com/The Middleware Company interviews Bill and Karen about J2EE, the CTS and recent controversial events surrounding J2EE.

Marinescu: How does an application server become J2EE compatible?

Shannon: All J2EE licensees receive the J2EE Compatibility Test Suite (CTS). The licensee executes the CTS against their implementation of the J2EE Platform Specification. Once their product has passed the CTS and has met all applicable testing requirements, they submit a certification form to Sun Microsystems, verifying that their product has passed the tests and met all compatibility requirements. Then the product can carry the Java Compatible, Enterprise Edition logo.

Marinescu: What kind of tests are included in the CTS?

Tegan: There are three types of tests included in the CTS: signature, API, and end-to-end or integration tests.

Signature tests verify that only the required elements of all specifications in the platform are implemented. Compatibility means no more and no less than the required Java APIs may be present, and the signature tests confirm this.

The API test checks that the product includes an implementation of all required APIs, and that the behavior of individual APIs meets the requirements of the spec. Both the signature and API tests are not new in Java Compatibility. These have been part of both J2SE compatibility tests and the tests for all Java optional packages provided by Sun.

The end-to-end integration tests are new to J2EE platform compatibility testing. They test the API and its underlying mechanism or service provider. For example, many end-to-end tests extend from the client to the EJB container to the back end database and return. Such tests use the platform the way an application would in a live interaction with a user. Integration and end-to-end tests check that an application using certain combinations of APIs behaves as expected. They ensure that data flows correctly between the front end application component and the database.

Marinescu: How does CTS differ from TCK in other technical areas?

Tegan: The term "Compatibility Test Suite" is just the name for the J2EE platform TCK. CTS serves the same purpose as any TCK: to ensure compatibility of a product. But, CTS is more extensive than most TCKs because it includes the "end-to-end" tests we described.

Marinescu: Some vendors who are J2EE compatible are tools or messaging vendors. Explain what it means for a messaging vendor to be compatible?

Shannon: Each product that carries the Java Compatible, Enterprise Edition logo meets all requirements defined in the J2EE Platform Specification. In order to receive the Java Compatible, Enterprise Edition brand, vendors must test and ship their products with a full implementation of the J2EE platform. In many cases, vendors include the J2EE reference implementation with their products.

For tools vendors, CTS tests the implementation of the J2EE platform integrated with their development products. For messaging products, vendors must integrate their products with an implementation of the platform, then pass CTS. Anytime a developer sees the Java Compatible, Enterprise Edition logo, they can be assured that the product includes a complete, compatible implementation of the J2EE platform.

Marinescu: Does the J2EE CTS test for compatibility with the J2EE Connector Architecture?

Shannon: The J2EE 1.3 platform includes the requirement for the J2EE Connector 1.0 Architecture. The CTS tests for all requirements of the J2EE 1.3 Platform Specification including Connectors.

Note that CTS tests only that the J2EE product meets the Connector requirements; it doesn't test any Resource Adapters that might be included with the product.

Marinescu: What is the value of the Java Compatible, Enterprise Edition brand?

Tegan: Any product that carries the brand assures the customer that the requirements of the J2EE compatibility program have been met. Such a product has been tested for compatibility with the J2EE specification, and has passed all those tests. Developers can write applications to the J2EE specification--and companies can purchase such applications--and be assured that they are portable across the more than 20 Java Compatible, Enterprise Edition products available today. The brand assures that "Write Once, Run Anywhere" is carried into enterprise applications.

Marinescu: What is new in the 1.3 tests?

Tegan: The J2EE 1.3 CTS has more than 15,000 tests. It includes all tests from 1.2, plus tests of the additional requirements of the J2EE 1.3 platform specification.

Shannon: New in J2EE 1.3 are the Java Connector 1.0 Architecture, EJB 2.0 with Interoperability and CSIv2, Message Driven Beans, improved CMP and finder query language, JMS 1.0.2, and JAXP 1.1.

Marinescu: How are the tests created?

Tegan: CTS engineering starts as soon as the JSR is filed. The CTS engineers work with Bill and other specification leads to determine all the requirements of each spec. These are referred to as the test assertions. Each assertion has at least one test case that refers to it. A list of all tests assertions and their respective specification location is distributed to the J2EE licensees along with the CTS.

Marinescu: What do you test in a spec?

Tegan: The CTS can only test for the required elements of the J2EE Platform Specification and that a product does the things that the specification "requires". Words such as "must," "will," and "is required to" are turned into test assertions by the CTS engineers and are tested on each licensee's product.

In some cases, the spec merely suggests how a product should behave, so adherence isn't tested. The specification indicates these cases with words like "may," "should," and "optionally." These are recommended functionality for the platform, but portability isn't guaranteed.

Shannon: For instance, the J2EE platform spec describes how a product can implement connection sharing, using the deployment information provided by the application that describes which connections can safely be shared. No J2EE product is required to implement connection sharing, or even to actually share connections in all possible cases. Whether the connection is actually shared or not, the other requirements of the J2EE spec must be obeyed. The CTS will test these other requirements, without testing whether the connection is actually shared.

Marinescu: Can the CTS be used as a test suite for product quality?

Tegan: Certainly a part of product quality is correct implementation of the specification. The CTS can be used as part of a product quality test suite. In fact, many licensees run the CTS against their intermediate builds of their product. Though the CTS does exercise quite a wide range of the product functionality, it isn't designed to be a product quality test suite. Products will always have functionality beyond that tested by the CTS or required by the specification.

The CTS isn't a stress test or a performance test. It doesn't test how a product behaves under heavy load. It can't test how a product reacts to a failure, such as an operating system crash or hardware failure. The transaction support required by J2EE allows a product to robustly handle a failure of this kind. But, the J2EE specification doesn't set specific failure handling requirements. CTS can't test behavior of a product during such a failure. Good product quality tests will want to test all these things.

Marinescu: We have heard vendors mentioning that they discovered bugs or flaws in the tests themselves. How does the discovery of a CTS flaw affect the test suite and the branding of other companies that previously passed the suite?

Tegan: Many bugs filed against CTS aren't problems with the test assertion itself, but with test setup or configuration. There are requirements in the J2EE platform specification where the implementation isn't specified. In these areas, some tests have depended on implementation specific behaviors in the J2EE reference implementation. A product that has previously passed these tests still provides a valid implementation, because the test itself did not change. The J2EE team works very closely with our licensees to fix any problem quickly.

Marinescu: Is the J2EE brand a one-shot thing or do I have to maintain it? If a product is J2EE compatible for 1.2 , is it necessary to pass the 1.3 CTS?

Tegan: Each version or edition of a product that carries the Java Compatible, Enterprise Edition brand must pass the tests and satisfy all testing requirements. When a new product is released with the Java Compatible, Enterprise Edition brand, it must pass the version of the CTS that was available roughly six months previous.

Marinescu: Can licensees ship implementations of new APIs or features for the next version of J2EE in a currently shipping product?

Shannon: The CTS requires that a product contain exactly the required versions of required APIs; older or newer versions aren't allowed. The required elements are defined by the platform specification. In order to maintain platform completeness and prevent platform fragmentation, many of the specifications included in J2EE do not have a separate TCK. EJB, Connectors, and JTA are examples of Java APIs that can only be provided as part of a J2EE compatible product.

Tegan: This means a developer will know exactly what features are available with any version of J2EE. The application doesn't need to check which version of each API is available. The application can't even *accidentally* use a feature from a newer version of an API, which would reduce application portability. Instead, an application knows that it has, for example, the J2EE 1.3 APIs, no more and no less.

Shannon: One important exception to this rule is critical to allowing Sun to deliver quality specifications through the JCP. A *non-final* product -- that is, an "early access" or "beta test" version -- doesn't need to meet compatibility requirements. Of course, these products may not use the Java Compatible brand. This allows vendors to ship preliminary implementations of specifications still under development. Users can use these implementations to provide feedback on the APIs. This helps us design APIs that best meet the needs of real users.

Another important exception is for Endorsed Standards. Endorsed Standards are Java APIs defined by standards bodies other than the JCP,such as the W3C DOM APIs. Vendors are allowed to include newer versions of Endorsed Standards in their products.

Marinescu: What is Sun's point of view in the debate over whether J2EE licensing restricts open source J2EE products?

Shannon: Sun participates in open source because it helps spark innovation, improve software quality, and fosters community. The source code for the J2EE reference implementation is made available publicly as part of the Sun Community Source Licensing program.

Sun supports open source developers because their efforts are consistent with Sun's own computing vision which uses open standards and non-proprietary interfaces. Sun's goal is to make our software as open as possible while ensuring portability and WORA.

Tegan: At the same time, having a strong brand and compatibility standards are important to the development of a robust market for J2EE platform products, tools, and components. The J2EE Compatible brand has achieved significant momentum over the past two years, and we want to make sure that any open source efforts don't impact the viability of that effort.

Marinescu: Why are there 5000 tests in 1.2 and 15000 in 1.3?

Shannon: The J2EE 1.3 Platform itself had major additions over version 1.2. The addition of JMS, Connectors and EJB enhancements including Interoperability and CSIv2 required a significant number of additional tests. In general, the CTS grows with the size of the platform requirements.

Marinescu: What have Sun and the Java Software team learned in working with licensees on CTS?

Tegan: We have learned that Compatibility matters to our licensees and their customers, and that it is a continuous process. Even though the CTS is large and tests a complex platform, the J2EE licensees met the challenge. You can't count on specs alone for technical correctness. It takes all three areas, the specification, the reference implementation and the compatibility tests to get it right. The CTS adds tremendous value to both J2EE product providers and enterprise application developers. Compatibility isn't a one time thing, it's a continual part of the development process.

Marinescu: We have heard the CTS is hard to run. What is Sun doing to make it easier?

Tegan: The CTS tests a complex environment. Today, an implementation can include vendor-specific platform requirements. To make the CTS itself portable, it abstracts the vendor specific classes into a porting package.

Once a vendor has implemented the complete platform, it is easy to run and repeat executions of the complete or sections of the CTS. The CTS uses JavaTest which is available through the JCP as part of the Java Test Development Kit (JTDK).

Marinescu: We have heard that JAXP is moving from EE to SE; what is the relationship between JCK & CTS?

Shannon: One requirement of the J2EE platform is the appropriate underlying J2SE platform -- one that has passed the appropriate Java Compatibility Kit (JCK) tests. The CTS also assumes that there is a Java Compatible, Standard Edition implementation underneath. Once a platform component technology migrates from J2EE into J2SE, CTS no longer includes signature or API tests -- they move to the JCK. The CTS may, however, continue to exercise the end-to-end and integration tests for that component.

Right now, JAXP is available as a separate technology, with a separate reference implementation and TCK. Therefore, JAXP can be combined with other technologies, including Java platform editions that don't include JAXP, such as J2SE 1.3 and J2EE 1.2.

J2EE 1.3 uses JAXP and requires, at a minimum, J2SE 1.3. Since SE 1.3 doesn't include JAXP, JAXP 1.1 is included in J2EE 1.3, and the J2EE 1.3 CTS includes the JAXP 1.1 TCK.

J2EE 1.4 will require J2SE 1.4 at a minimum. Since JAXP 1.1 will be moving into J2SE 1.4, the JAXP 1.1 TCK will move into the JCK for J2SE 1.4. As a result, the J2EE 1.4 CTS will not need to include the JAXP TCK.

Marinescu: How many J2EE licensees and certified products are there today?

Tegan: There are 20 Java Compatible, Enterprise Edition 1.2 products available today. Check out http://java.sun.com/j2ee/compatibility.html for the complete list of J2EE Compatible products and pointers to the licensee implementations. There are also 4 Java Compatible, Enterprise Edition 1.3 products available today.

Stay tuned for product announcements in the coming weeks as vendors finish their compatibility testing for our J2EE 1.3 Launch Event in San Francisco.

Marinescu: Many of our members have mentioned that even CORBA vendors can't properly interoperate - so why was IIOP standardized as the RMI transport in J2EE 1.3?

Shannon: The IIOP standard was already supported by the Java platform and provided the industry's best hope for a standard interoperability protocol at the time J2EE 1.3 was defined -- although, in the future, we expect web service protocols such as SOAP to also provide such interoperability.

In addition, we drove the definition of the security interoperability component of IIOP through the OMG in order to fill in the major missing piece that was needed for J2EE. We believe our compatibility testing program and licensee support program will allow us to achieve a real, useful level of J2EE interoperability.

Marinescu: Are there any plans on bundling JDO into J2EE?

Shannon: No, there are no plans to add JDO as a required component of J2EE. Some vendors are evaluating JDO for use in their products. If there is sufficient demand from vendors and customers to include JDO in J2EE, we will consider including it. So far, we have not seen such demand. Most vendors and users are happy with the Container Managed Persistence capability added to EJB 2.0 in J2EE 1.3.

Marinescu: What features should we anticipate in J2EE 1.4?

Shannon: Web services, web services, and more web services! Support for web service standards such as SOAP/HTTP and WSDL is the primary goal of J2EE 1.4. J2EE 1.4 will be the best platform for deploying and accessing web services. Much work is underway in the Java Community Process to define the components needed to supply full support for web services. One of the major components, the JAX-RPC technology, will be delivered before J2EE 1.4 and will be usable on J2EE 1.3 products.

J2EE 1.4 will also deliver on work in progress to improve the support for J2EE tools, and will provide minor enhancements to existing APIs as required.

More detail on our thinking for J2EE 1.4 can be found on the JCP web site at http://jcp.org/jsr/detail/151.jsp.

PRINTER FRIENDLY VERSION