Developing Portable Applications for the Java 2 Platform, Enterprise Edition (J2EE )

Transcription

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

2 Goal Learn how to develop portable applications for the J2EE 1.3 platform 2

3 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 3

4 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 experience with different implementations for the J2EE platform Philippe Hanrigou is a CTS engineer, specializing in the EJB TM specification and interoperability technologies CTS is the largest collection of portable, J2EE platform-based applications with over 15,000 test cases 4

5 Merits of the Java 2 Platform, Enterprise Edition (J2EE ) Faster Solution Delivery Time to Market Freedom of choice Simplified Integration End-to-end solutions 5

6 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 6

7 The Value of the Java Compatible, Enterprise Edition Brand 7

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

9 J2EE Platform: Licensees ATG BEA Systems Borland Broadvision Brokat CA Cape Clear Compaq Data Direct Fujitsu Hitachi HP Bluestone IBM In-Q-My Interworld IONA iplanet Lutris Macromedia NEC Nokia Oracle Persistence Pramati SAS Institute Secant SilverStream Sonic Spiritsoft Sybase Talarian Tibco TMax Togethersoft Trifork WebGain 9

10 1.3 Compatible Products Are Here! 10

11 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! 11

12 CTS: Largest Collection of Portable Applications for the J2EE 1.3 Release Largest collection of J2EE 1.3 platformenabled applications: 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 12

13 J2EE 1.3 Platform Architecture Applet Container Applet HTTP SSL Web Container EJB Container JSP Servlet EJB J2SE Application Client Container HTTP SSL JAAS JMS JTA Java Mail JAF J2SE JAXP JDBC Connectors JAAS JMS JTA Java Mail JAF J2SE JAXP JDBC Connectors Database Application Client JDBC JAXP JAAS JMS 13 J2SE

14 Enterprise JavaBeans (EJB ) Specification: Learning Experiences 14

15 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) 15

16 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) 16

17 EJB Spec: RMI-IIOP Types IIOP can be the underlying protocol Valid RMI-IIOP types Java TM 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) 17

18 CMP 2.0: A New Persistence Model CMP 2.0 now only supports 4 transaction attributes (EJB ) 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 ) Undeploy does not guarantee persistence cleanup 18

19 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 19

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

21 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 21

22 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 22

23 Using the Component Environment Context InitialContext ctx = new InitialContext(); Context envcontext = nctx.lookup("java:comp/env"); 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! 23

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

25 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 25

26 JMS API: Audit Your Cleanup Code JMS sessions and connections: close them explicitly (sessions first) myjmssession.close(); myjmsconnection.close(); MDB using BMT: commit or rollback all your JMS sessions explicitly ut.commit(); Durable subscriptions: unsubscribe when done tsub.close(); tsession.unsubscribe(...); 26

27 JMS API: Robust Error Handling 27 Common problem ut.begin(); try { /* Do something */ } catch(someapplicationexception e) { /* Recover from exception */ /* No explicit cleanup and/or commit */ } /* cleanup code */ ut.commit(); Do not rely on (potential) auto-commit behavior; use finally blocks! Applicable to all Bean Managed Transactional code (not only JMS)

28 JMS API: Close Connections (Revisited) Developer writes code assuming to deal with 2 distinct Connection Factories 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(); Deployer binds TFact1 and TFact2 to the same JMS factory (JNDI name + client ID) client ID already in use at /* OK? */ 28

29 Back-end Learning Experiences 29

30 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 ) ResultSet types TYPE_SCROLL_INSENSITIVE, TYPE_SCROLL_SENSITIVE are not required for J2EE

31 Security Learning Experiences TM 31

32 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 32

33 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 33

34 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 34

35 Packaging Learning Experiences TM 35

36 Packaging: EJB References EJB Remote references Need to package (or reference) Home and Remote interfaces even if part of the same.ear file EJB 1 Ejb-jar 1 EJB local references All beans packaged in the same ejb-jar EJB 2 Ejb-jar 2 A jar file can reference another jar file using a Class-Path header in its Manifest file (J2EE ) 36

37 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() 37

38 Packaging: JSP Tags (JavaServer Pages Specification-based 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 38

39 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 <multiplicity>one</multiplicity> 39 <multiplicity>one</multiplicity> Invalid

40 J2EE 1.3 Platform, Interoperability: Learning Experiences 40

41 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 for details 41

42 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 42

43 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 43

44 Non-Portable Features Integration 44

45 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 45

46 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 46

47 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 47

48 Summary Read the specifications carefully Only take advantage of required platform semantics Be aware of vendor value add Avoid use of optional packages 48

49 If You Only Remember One Thing Read the specifications carefully! Write your apps to the spec. 49

50

51