Session 1709

Developing Portable Applications for the Java™ 2 Platform, Enterprise Edition (J2EE™) Kevin Osborn, Philippe Hanrigou,Lance AndersenSun Microsystems, Inc.

Session 17092

Goal

Learn how to develop portable applications for the J2EE™ 1.3 platform

Session 17093

Learning Objectives

Understand the value of the J2EE brand

Identify key areas of J2EE technology which have portability limitations

Identify areas of J2EE technology which allow vendors to extend

Session 17094

Speaker’s Qualifications

Kevin Osborn is the manager of the Compatibility Test Suite (CTS) team for Java 2™ Platform, Enterprise Edition (J2EE)

Lance Andersen is a technology specialist in Java Partner engineering, and has extensive experiencewith different implementations for the J2EE platform

Philippe Hanrigou is a CTS engineer, specializing in the EJBTM specification and interoperability technologies

CTS is the largest collection of portable, J2EE platform-based applications with over 15,000 test cases

Session 17095

Merits of the Java™ 2 Platform, Enterprise Edition (J2EE™)

Faster Solution Delivery Time to Market

Freedom of choice

Simplified Integration

End-to-end solutions

Session 17096

Agenda

The Value of the Java Compatible™, Enterprise Edition Brand

J2EE Compatibility Test Suite, a collection of portable applications

J2EE CTS learning experiences

Summary

Q&A

Session 17097

The Value of the Java Compatible™, Enterprise Edition Brand

Session 17098

8

Delivering Compatibility

Integrated Application Environment Platform and API specifications Reference implementation of APIs Compatibility Test Suite A Brand J2EE BluePrints design guidelines

Session 17099

J2EE Platform: Licensees

SAS InstituteSecantSilverStreamSonicSpiritsoftSybaseTalarianTibcoTMaxTogethersoftTriforkWebGain

IBMIn-Q-My InterworldIONAiPlanet Lutris MacromediaNECNokiaOraclePersistencePramati

ATGBEA SystemsBorlandBroadvisionBrokatCACape ClearCompaqData DirectFujitsuHitachiHP Bluestone

Session 170910

1.3 Compatible Products Are Here!

Session 170911

J2EE Platform: Compatibility Goals

Write Once, Run Anywhere™

Portable applications will run in all compatible servers

Compatibility Test Suite tests conformance to the specifications

Compatibility challenges

Portability of test suite

Vendor value add—Don’t be confused!

Session 170912

CTS: Largest Collection of Portable Applications for the J2EE 1.3 Release

Largest collection of J2EE 1.3 platform-enabled applications: 1800+ .ear files 15,000+ tests

Intense exposure to application portability Every licensee has to successfully deploy

and run all these tests Non-portable means invalid Test is challenged if its relies on any

non-portable feature or behavior

Session 170913

J2EE 1.3 Platform Architecture

AppletContainer

Web Container EJB Container

Applet

ServletJSP EJB

J2SE J2SE

J2SE

J2SE

ApplicationClient Container

ApplicationClient

JMS

JAA

S

JAX

P

JDB

C

JMS

JAA

S

JTA

JAX

P

JDB

C

Co

nnectors

JavaMail

JAF

JMS

JAA

S

JTA

JAX

P

JDB

C

Co

nnectors

JavaMail

JAF DatabaseHTTPSSL

HTTPSSL

Session 170914

Enterprise JavaBeans™ (EJB™) Specification: Learning Experiences

Session 170915

EJB Spec: State Gotchas

Stateless beans Do not retain any conversational state

Entity beans Do not rely on state that you do not persist

(ejbLoad / ejbStore) Can come into READY state:

Through ejbCreate()(but not only) Through ejbActivate() (e.g., No pooling!)

Initialize non-persistent member variables in setEntityContext()

e.g., Getting a reference to the environment naming context (java:comp/env)

Session 170916

EJB Spec: RemoteException

Background: EJB 1.0 spec Allowed business methods to throw a

java.rmi.RemoteException (bean class) To indicate a non-application exception

Deprecated since the EJB 1.1 release

Portable beans should throw the javax.ejb.EJBException (or another RuntimeException)

CMP 2.0 beans must not throw the RemoteException (bean class)

Session 170917

EJB Spec: RMI-IIOP Types

IIOP can be the underlying protocol…Valid RMI-IIOP types

JavaTM Language to IDL Mapping specification (“Java IDL”)

Argument and return types For the Home and Remote Interfaces

Session beans instance variables Mark all non-serializable instance

variables as transient A few additional valid types (EJB.7.4.1)

Session 170918

CMP 2.0: A New Persistence Model

CMP 2.0 now only supports 4 transaction attributes (EJB.17.4.1)

Only Required, RequiresNew or Mandatory should be used

Use NotSupported, Supports, Never is not portable (support is optional)

Use unique abstract schema names per ejb-jar file (EJB.11.2.3)

Undeploy does not guarantee persistence cleanup

Session 170919

EJB Spec: New Query Language

Finder methods All finder method defined in Home / LocalHome interfaces…

Must have a corresponding <query> element One exception: findByPrimaryKey(...)

EJB QL consideration Container and databases may not support

the use of the optional, third argument of the LOCATE function

Avoid use of this argument

Session 170920

Java Naming and Directory Interface™ (JNDI): Learning Experiences

Session 170921

JNDI Initial Context Requirement

java:comp/env naming context is required for all lookups Recommended subcontexts

java:comp/env/jdbc java:comp/env/ejb java:comp/env/url java:comp/env/mail java:comp/env/jms

Use unique JNDI names

Session 170922

JNDI: INS:CosNaming

Always use INS compliant names

Especially true for interoperability Path separators is a concern:

“dot” is not valid Examples of valid INS names:

MyApplication_foo_bar_myEJB

corbaname:iiop:1.2@<host>:<port>#yourApp_foo_yourEJB

Session 170923

Using the Component Environment Context

Always use the component naming environment to lookup “administered object”(portable and easy) e.g., JMS Queue Connection Factories

Session beans A reference to the bean environment context

(and any of its sub-contexts) can always be passivated

A reference to the Initial Context might not be!

InitialContext ctx = new InitialContext();

Context envContext = nctx.lookup("java:comp/env");

Session 170924

Java™ Message Service (JMS) API and MDB: Learning Experiences

Session 170925

JMS API: Pre-deployment

No standard way To define MDB JMS destination bindings To create/configure (prior to deployment)

JMS Connection Factories JMS Destination

Document pre-deployment configuration instructions

Eventually provide a helper application/script to create these JMS administered objects

Session 170926

JMS API: Audit Your Cleanup Code

JMS sessions and connections: close them explicitly (sessions first)

tSub.close();tSession.unsubscribe(...);

Durable subscriptions: unsubscribe when done

MDB using BMT: commit or rollback all your JMS sessions explicitly

ut.commit();

myJmsSession.close();myJmsConnection.close();

Session 170927

JMS API: Robust Error Handling

Common problem

Do not rely on (potential) auto-commit behavior; use finally blocks!

Applicable to all Bean Managed Transactional code (not only JMS)

ut.begin();try { /* Do something */} catch(SomeApplicationException e) { /* Recover from exception */ /* No explicit cleanup and/or commit */}/* cleanup code */ut.commit();

Session 170928

JMS API: Close Connections (Revisited)

Developer writes code assuming to deal with 2 distinct Connection Factories

Deployer binds TFact1 and TFact2 to the same JMS factory (JNDI name + client ID)

client ID already in use at /* OK? */

Tcf1 = (TopicConnectionFactory) nctx.lookup("java:comp/env/jms/TFact1");tcf2 = (TopicConnectionFactory) nctx.lookup("java:comp/env/jms/TFact2");tCon1 = tcf1.createTopicConnection(...);... /* Do not close tCon1 */tCon2 = tcf2.createTopicConnection(...); /* OK? */...tCon1.close(); tCon2.close();

Session 170929

Back-end Learning Experiences

Session 170930

Java™ DataBase Connectivity API (JDBC™): Clarifications

J2EE 1.3 implementation must be able to return a JDBC 2.0 compliant DataSource via JNDI

Additional requirements are listed in the JDBC section of the J2EE 1.3 Platform specification (J2EE.6.2.2.3)

ResultSet types TYPE_SCROLL_INSENSITIVE, TYPE_SCROLL_SENSITIVE are not required for J2EE 1.3

Session 170931

Security Learning Experiences

TM

Session 170932

Security: J2SE Platform-based Security Permissions

J2SE security permissions: J2EE components can only expect to get the

“J2EE security permissions set” as defined in J2EE 1.3 Specification Table 6.2

Application components that need permissions not in this minimal set should describe their requirements in their documentation

Session 170933

Security: Method Permissions

When security roles are defined, always specify method permissions J2EE 1.2 release

The server may interpret unspecified to be none or all

J2EE 1.3 release It is the responsibility of the Deployer to

assign method permissions for all of the unspecified methods

Use the <unchecked>/<exclude-list>elements

Session 170934

Security: Login Code

Keep login code in a separate class that can be ported J2EE 1.2 release does not require a specific

authentication mechanism (e.g., JAAS) J2EE 1.3 release requires JAAS, but it is a good

practice to keep the LoginModule code from the application code

Session 170935

Packaging Learning Experiences

TM

Session 170936

EJB 2

Ejb-jar 2

EJB 1

Ejb-jar 1

Packaging: EJB™ References

EJB Remote references Need to package

(or reference) Home and Remote interfaces even if part of the same .ear file

EJB local references All beans packaged in the same ejb-jar

A jar file can reference another jar file using a Class-Path header in its Manifest file (J2EE.8.1.1.2)

Session 170937

Packaging: Transaction Attributes

Must not specify any transaction attributes for: Session beans

All methods of the Home interface All the methods of javax.ejb.Object() and

javax.ejb.EJBLocalObject()

CMP 2.0 getHandle() getEJBHomeHandle() getEJBHome() getEJBMetaData() getEJBLocalHome() GetPrimaryKey() IsIdentical()

Session 170938

Packaging: “JSP™ Tags”

It is invalid to have TLDs which refer to missing Tag classes

Even if your application does not actually use this JSP Tag

Make sure you package all the Tag classes for all the Tags defined in your TLD

(JavaServer Pages™ Specification-based Tags)

Session 170939

Packaging: Case Sensitivity

Deployment descriptors: The content of the XML elements is in

general case sensitive (J2EE.8.4)

Exact behavior of the deployment tool is unspecified

Example: <ejb-name>, CMP 2.0 relationships

Invalid

<multiplicity>One</multiplicity>

<multiplicity>one</multiplicity>

Session 170940

J2EE 1.3 Platform, Interoperability: Learning Experiences

Session 170941

Interoperability

RMI-IIOP is required

Transaction interoperability Optional feature of the EJB 2.0 spec Code your EJB component so that it handles

containers that support AND do not support transaction interoperability See EJB 2.0 specification section 19.6.2.2

for details

Session 170942

Interoperability: CORBA Names

Must use a valid corbaloc or corbaname corbaloc:iiop:1.2<host>:<port>/<objectkey>

Host, port and objectkey are values corresponding to the root CosNaming service of the server

corbaname:iiop:1.2@<host>:<port>#rmi:/Lance/ASessionEJB

Info to the left of the “#” is unique to the App Server which is looking up the EJB component

Everything to the right of the “#” indicates how to find the EJB component on the remote server

Session 170943

RMI-IIOP / Java IDL Stubs and Ties

J2EE platform-based components can be clients of any RMI-IIOP or Java IDL object Java-To-IDL (RMI-IIOP) describes how to

create portable stub and tie classes POA support is not mandated Unlike “EJB stubs” and ties, these must

be packaged with the application

Only application clients can create and export RMI-IIOP and Java IDL objects

Session 170944

Non-Portable Features Integration

Session 170945

Use of Non-Portable/Optional Features

An application for the J2EE platform might want to use: An optional API or feature

(e.g., Transaction interoperability) Application server specific extensions

Improved performance, functionality beyond the scope of the J2EE 1.3 platform, …

In such case Generalize the proprietary API: Abstraction layer Applications access implementation specific

code only through this abstraction layer

Session 170946

Example 1: The CTS Porting Package

CTS must use a couple of non-portable/ unspecified API features Deployment/undeployment, pre-deployment

configuration of DB and JMS API administered objects, …

A porting package is included Abstracts implementation specific code

Portable applications access implementation specific code only through interfaces

Licensees provide their implementations of these interfaces

JDBC SQL statements are read at runtime

Session 170947

Example 2: Use of Local Interfaces From the Web Container

Support for use of EJB local interfaces from the Web container is optional

Your application performance might benefit from using this (non-portable) feature

Even if you only use local interfaces always provide a remote view of the beans accessed by your JSP/Java Servlet components

Do not rely on any side effect of the local client view (e.g., Sharing of objects)

Your application can easily be ported to any J2EE 1.3 platform-compliant application server

Session 170948

Summary

Read the specifications carefully

Only take advantage of required platform semantics

Be aware of vendor value add

Avoid use of optional packages

Session 170949

If You Only Remember One Thing…

Read the specifications carefully! Write your apps to the spec.

Session 1709

Session 1709