|
|
|
|
|
|
|
Enterprise JavaBeans[tm] Architecture FAQsWe want to hear from you! Please send us your FEEDBACK.
1. There seem to be many specifications related to Java 2 Platform, Enterprise Edition (J2EE). What are they and where can I find them?The J2EE[tm] platform specification is a document that defines the requirements for J2EE application servers. A J2EE product provider can implement the functionality in whichever way that they want, providing that the requirements outlined in the specification are met.The latest finalized version of the J2EE specification is version 1.3. Version 1.3 has recently superseded version 1.2 and it is version 1.2 of the specification that is the version implemented by many of the current application servers available. You can download both the J2EE platform specification v1.2 and the J2EE platform specification v1.3 from here. The J2EE platform specification document also defines support for other specifications. Following are some details of other important specifications: The Enterprise JavaBeans (EJB[tm]) Specification defines what is required to support the EJB component architecture.
It's target audiences are vendors of transaction processing systems and enterprise
application tools, as well as other vendors who want to support EJB technology
in their products. You can download the EJB specification v1.1 and the EJB specification
v2.0 from here
. The J2EE[tm] Connector Architecture is a new feature that has been introduced in the J2EE 1.3 specification. It defines a standard architecture for connecting the J2EE platform to Enterprise Information Systems such as ERP, TP and database systems which aren't supported by JDBC[tm] API. The J2EE Connector Specification details the requirements for how the J2EE Connector Architecture should be implemented. The J2EE Connector Specification is available for download from
here.
Other specifications included in the J2EE platform include the JavaServer Pages (JSP[tm]) and Java servlet specifications. The J2EE 1.3 platform requires support for the Java Servlet 2.3 and JSP 1.2 specifications while the J2EE 1.2 platform requires support for the Java Servlet 2.2 and JSP 1.1 specifications. The Java servlet specifications are available for download from here while the JSP specifications are available for download from here
2. What exactly is the J2EE[tm] Reference Implementation?The J2EE[tm] Reference Implementation is a full implementation of the J2EE platform specification. It's both a proof-of-concept and an operational definition of the J2EE platform. It can be used by J2EE technology application developers for developing and testing their J2EE platform compliant products. For each version of the J2EE platform specification there is also a Reference Implementation.The J2EE Reference Implementation is not a commercial grade product and its software license prohibits its use in a production environment. The Reference Implementation is available as part of the Java 2 platform, Enterprise Edition (J2EE Software Developers Kit (SDK), and the version numbers of the SDK reflect the version of the J2EE Platform specification implemented by the SDK. For example J2EE SDK v1.2.1 implements v1.2 of the specification, while the J2EE platform SDK v1.3 implements v1.3 of the specification. You can find details of the J2EE specifications under the question "There seem to be many specifications related to the J2EE platform. What are they and where can I find them?" in this set of FAQs. The latest version of the SDK for the 1.2 version of the specification
is j2sdkee v1.2.1
and can be downloaded
here.
Please read the license agreement when you download the J2EE SDK.
3. What tools are available for testing applications that incorporate EJB technology?You can test and run your EJB applications on any application server that supports the version of the J2EE specification to which you wrote your EJB components.The first and most obvious option is the J2EE Reference Implementation which comes as part of the J2EE SDK. You can find out more about the Reference Implementation by reading the "What exactly is the J2EE[tm] Reference Implementation?" question in this set of FAQs. There are also several OpenSource and freely usable application servers whose license covers you for "personal use". Many people on the EJB forum have recommended JBoss which is a fully-free application server that is licensed under the GNU Public License. Other frequently mentioned application servers are an Open Source Enterprise JavaBeans technology server and Orion. JOnAS is an OpenSource implementation of the EJB 1.1. specification. The Orion Application Server is free for development and for non-commercial deployment but isn't OpenSource. JBoss Application Server
Many of the popular commercial application servers have trial versions with limited licenses. You can find out more by visiting the "What commercial applications are available for running my J2EE[tm] platform applications?" question in this set of FAQs.
4. What Development tools are available for developing J2EE platform applications? There are several Integrated Development Environments (IDE) that support the development of J2EE platform applications. Listed below are some that support most, if not all of the features of the J2EE platform specification v1.2. There are some versions of these and other products that support Java servlets and JavaServer Pages[tm] (JSP technology) but provide no support for the development of EJB component architecture. Forte[tm]
for Java[tm] Enterprise Edition
v3.0
(Solaris[tm] 8 Operating Environment,
Windows NT SP6, Redhat Linux)
5. What commercial applications are available for running my J2EE platform applications?There are so many application servers on the market that it is impossible to list them all. We'll do our best to keep this list growing by adding new application servers as we learn about them. The following list is in alphabetical order and the URL's they link to are the main sites for the vendor of the product.Allaire JRun
6. Are there any J2EE platform tutorials available? Sun provides two versions of the tutorial for different versions of the J2EE platform and Software Development Kit (SDK). The tutorial for version 1.2 of the J2EE platform and v1.2.1 of the SDK is called the J2EE[tm] Developers Guide . The tutorial for version 1.3 of the J2EE platform and for v1.3 of the SDK is simply called the J2EE[tm] Tutorial. The J2EE Tutorial is fundamentally different from the J2EE Developers Guide because of the major differences between version 1.2 and 1.3 of the J2EE platform. You can view version 1.2.1 of the J2EE platform developers Guide for J2EE SDK
v1.2.1 from
here.
IBM also has several tutorials on their DeveloperWorks site. Currently they have courses that cover the following J2EE technology topics.
Building Java HTTP Servlets
7. I've found the J2EE Tutorial but I don't have the examples, where can I get them from? The download location for the tutorial is given in the tutorial itself. You can download it from here . When you get to the download page you will be offered two formats; PDF and zip. Selecting the "zip" option will give you a zip file containing the tutorial in HTML format and with all of the examples.
8. Is there a Developer certification for the J2EE platform? There are two Certifications offered by Sun Microsystems and several IBM certifications that relate to the J2EE platform and architecture, the technologies that the J2EE architecture encompass and in the case of the IBM certifications, to the WebSphere application server and VisualAge development environment. You can find out more about the IBM certifications by visiting their Application Development Certification web site. The two certifications offered by Sun are the
Sun Certified Web Component Developer Certification for the J2EE[tm] platform
and the
Sun Certified Enterprise Architect for the J2EE[tm] platform.
Details of the Sun Certifications can be found here . In order to find out about Sun Certifications in your country go to the Sun Educational Services web site and use the page to navigate to your local country site. Also, there is the jCert[tm] initiative which was founded in 1999 by many of the leading players in Enterprise Java[tm] technology. The aim of the jCert initiative is to promote common standards for validating the skills of developers working with the Java platform.
9. What other technical resources are available? Sun Microsystems is constantly producing new J2EE platform specific technical content and their web-site has a section that covers the J2EE Platform in general as well as a section dedicated to Enterprise JavaBeans[tm] technology. Throughout the Internet, resources for J2EE technology-based application and EJB component architecture development abound. Each of the application server vendors have really good technical resources for not only their own products but for J2EE and EJB technology-based application development in general. If you have an application server specific problem it is always a good idea to visit the vendors web site before posting to the forum. TheServerSide.com is an excellent J2EE technology community that includes a forum for discussing J2EE platform issues, technical articles, news about what's happening in the J2EE technology world, reviews of J2EE platform products and even early access to J2EE technology related books. The JavaWorld[tm] publication consistently produces great J2EE technology related technical articles as well as covering all other aspects of Java technology. Visit their J2EE platform related site here.
10. How can I get technical support?The Java Technology Forums are a great place to start for technical help. The forums form a large community with a vast level of expertise on all areas of Java technology. If you have an issue with a specific J2EE application server or supporting product and you are unable to get help from the forums then the best recourse is to visit the website of the vendor of that product. Sun Microsystems itself offers excellent in-depth developer support programs at many different levels. For more information about these offerings or to purchase one, please visit the Sun Developer Connection program web site.
11. I've just downloaded the Java 2 platform, Enterprise Edition (J2EE) SDK and I'm having trouble getting the Reference Edition up and running. What should I check?First, you should check that you have everything that you need to run the Reference Implementation and to use the Java 2 platform, Enterprise Edition (J2EE) SDK. Read the Release Notes; they will tell you what platforms and databases are supported and which version of the Java platform the Reference Implementation is compatible with. Next read the Installation Instructions carefully. If you have done these two things then everything else should be easy. You'll find the Release Notes in the Doc subdirectory of the directory in which you installed the J2EE SDK. The Installation Instructions are available online and their location is specified in the Release Notes.Simple tips for Win32 platform: First check the release notes of the SDK to make sure that you are using a supported version of the Win32 platform. You must be able to set up environment variables on your system. To do this on the supported versions of Microsft Windows isn't difficult, just open the System Control Panel, select the Advanced Tab and click "Environment Variables". Here you can set up environment variables at the system and user levels (system level variables can only be set by an administrator). Create an environment variable called J2EE_HOME and assign to it the path in which you installed the J2EE SDK. Create an environment variable called JAVA_HOME and assign to it the path in which Java is installed. Modify the PATH environment by adding both %J2EE_HOME%\bin and %JAVA_HOME%\bin
to it. If a PATH environment variable is set for the user, it's value will be appended to the system level PATH. So if you have already added %JAVA_HOME%\bin and/or %JAVA_HOME%\bin to the PATH environment for the system, then the system PATH will take precedence over the user PATH. This may not be what you want. The CLASSPATH is something that often causes problems and this is compounded by the fact that the two ways of setting it are mutually exclusive. The best practice is to always use the -classpath option with the java and javac commands. If you choose to, you can then set up environment variables for commonly used CLASSPATH combinations and use these variables with the -classpath option. For example, you could create an environment variable for use when compiling the J2EE technology example applications. If you create an environment variable called J2PATH and assign it the value %J2EE_HOME%\lib\j2ee.jar;. You can then use this new environment variable as follows: javac -classpath %J2CPATH% MyBeanHome.java You can combine these variables with other variables and/or other class library locations. For example: javac -classpath %J2CPATH%;%ALTPATH%;c:\myapp\lib\mylibrary.jar
MyBeanHome.java Tips for the Solaris[tm] operating environment and Linux : Setting environment variables on a system running the Solaris[tm] Operating Environment or Linux is really dependent on what shell you are using. Check your operating system's documentation for how to set an environment variable in your particular shell. Create an environment variable called J2EE_HOME and assign to it the path in which you installed the J2EE SDK. Create an environment variable called JAVA_HOME and assign to it the path in which Java technology is installed. Modify the PATH environment by adding both $J2EE_HOME/bin and $JAVA_HOME/bin to it. The CLASSPATH is something that often causes problems and this is compounded by the fact that the two ways of setting it are mutually exclusive. The best practice is to always use the -classpath option with the java and javac commands. If you choose to, you can then set up environment variables for commonly used CLASSPATH combinations, and use these variables with the -classpath option. For example, you could create an environment variable for use when compiling the J2EE technology example applications. If you create an environment variable called J2PATH and assign it the value $J2EE_HOME/lib/j2ee.jar;. you can then use this new environment variable as follows: javac -classpath $J2CPATH MyBeanHome.java You can combine these variables with other variables and/or other class library locations. For example: javac -classpath $J2CPATH:ALTPATH%:/opt/myapp/lib/mylibrary.jar MyBeanHome.java
12. I need to be able to run both the 1.2.1 and 1.3 versions of the Java 2 Platform, Enterprise Edition (J2EE) SDK and Reference Implementation. How can this be done?The key is to set the J2EE_HOME environment variable to be the path to the installation directory to the version of the that you want to run. Be sure that both your systems PATH environment variable and any variables that you use for the classpath use the J2EE_HOME variable to find the J2EE SDK scripts and class libraries. For example. If on a Microsoft Windows system you set the PATH and CLASSPATH as follows:PATH=%PATH%;%J2EE_HOME%\bin and you have the two versions of the J2EE SDK installed in the directories: c:\j2sdkee1.2.1 setting J2EE_HOME=c:\j2sdkee1.2.1 will enable you to use version 1.2.1 and setting J2EE_HOME=c:\j2sdkee1.3 will enable you to use version 1.3. To make this work effectively you must not use the full path of any of the J2EE platform SDK commands that you wish to run. As %J2EE%\bin directory is in the path, simply typing the name of command (such as j2ee, cloudscape, deploytool) will suffice.
13. When I use the J2EE Reference Implementation to deploy an application, I cannot find the client JAR file after deployment has completed. What's going wrong?When deploying an enterprise application that contains an enterprise bean, deploytool will allow you to create a client JAR file which contains the classes that a standalone client application will need in order to be able to access the bean. When you run the client application you will need to provide access to the client JAR file via the classpath, otherwise the application will not run. Many of the instructions for tutorial examples tell you what command line to type for running an application which includes adding the client JAR file to the classpath and many make the assumption that the client JAR file is in the directory in which you are running the client application. But this isn't always going to be the case.When you build an enterprise application you create an Enterprise ARchive or .EAR file. Deploytool allows you to create this file anywhere that you want to on your system. The problem is, when you deploy the application the default path provided by the deploytool for the client JAR file is the location of the .EAR file. If you wrote all of your source code including the code for your client application in one directory, and deployed the enterprise application in a different directory, you'll find that when you compile the client application the client JAR file isn't in same directory as your source code. So what to do? When deploying your enterprise application be aware of the situation described above and make sure that you set the path in the "Client Jar File Name:" to include the path to the directory in which you really want the Client JAR file to reside. This could be your source directory, but wherever you choose you need to be aware of the location of the client JAR file when you compile your client application. Note: The entry box that deploytool provides for "Client Jar File Name:" is a little small and it's difficult to see what you have typed so it's probably best to use the Browse button to set the path. The last stage of deployment is to create the Client JAR file and the path name used will be displayed in the Deployment Progress window. You can use this for confirmation.
14. I keep seeing terms such as blueprints and Java Pet Store demo in relation to J2EE application development. What are blueprints and what is the Java Pet Store demo?The Java Blueprints for J2EE architecture are a set of guidelines for developing enterprise applications. They describe best practices and explain and demonstrate the use of the various J2EE technologies. The Java Blueprints for J2EE architecture are available on-line or in published form as the book "Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition".The Java Pet Store demo is the sample eCommerce application that is associated with the Java Blueprints for J2EE architecture. The Pet Store illustrates basic usage of J2EE technology, and demonstrates current best practices in system design. The intent of the Java Pet Store demo is to cover as much of the platform as possible, as clearly as possible, in a relatively small application. The Pet Store application is available for download as a zip file, as a shell script or as a Win32 executable. Full source code for Java Pet Store demo is included in the package. All information relating to the Java Blueprints for J2EE architecture and to the Java Pet Store demo can be found on the Blueprints web page on the Java web site.
15. I'm totally confused about stateless session beans, particularly about their life-cycle and their state, what's the deal?A stateless session bean does not maintain any conversational client state across method calls but it can include instance variables that allow it to maintain state independent of any client interaction.The life-cycle of a stateless session bean is completely controlled by the container. If a client needs a stateless session bean it calls the create() method on the Home Interface. All this does is tell the container that an instance of the bean is needed. The container can then either obtain that instance from an instance pool or create a new instance if none are available. Once the container has obtained the bean it is then associated with the EJBObject created to service the client request. When the container creates a bean instance it calls the bean's ejbCreate() method which allows it to initialize any persistent connections or obtain references to other objects that the bean may need during it's life cycle. Note that the ejbCreate() method is only called when an instance of the bean is created. Therefore, this initial state is not re-initialized when the bean is used to service a client request. When a client calls the remove() method on either the Home or Remote Interfaces of a stateless session bean, it serves as notice to the container that the client no longer needs the bean. The container then releases the EJBObject and the bean is returned to it's instance pool. The ejbRemove() method of the stateless session bean is not called until the container decides to remove the bean from the instance pool. This allows the bean to do any clean-up operations such as closing any open connections that it has.
16. How can I generate unique primary keys for my Entity Beans?This is a very frequently asked question, and although it's not possible to provide a detailed answer in the scope of this set of FAQs, it is possible to point you to external resources where this subject has been addressed.The article entitled "HIGH/LOW Singleton+Session Bean Universal Object ID Generator" on TheServerSide.com is the result of lengthy discussion on this subject on two related discussion threads. Most of the discussion revolves around Scott Ambler's article on "Enterprise-Ready Object IDs" which describes the HIGH/LOW strategy of Object ID generation and which is the basis of the solution described in the article on TheServerSide.com.
17. I've been developing and testing my EJB technology client application on the same system on which my EJB technology application is running. I now want to deploy my EJB client application on a remote system. What changes do I need to make?For the Reference Implementation:There are two main changes required. The first is to supply properties to InitialContext so that it can access the remote system. The second is to eliminate any coded EJB technology refs as these are only applicable to the local system. To correctly create the InitialContext you
must supply the java.naming.factory.initial
and java.naming.factory.url.pkg properties via
it's constructor. For the Reference Implementation, the values are: java.naming.factory.initial: "com.sun.jndi.cosnaming.CNCtxFactory"These values will differ for other J2EE applications and application servers. Also you will probably use an EJB technology ref in the lookup on the home interface. An EJB technology ref is defined in the deployment descriptor of the bean and maps a J2EE technology environment value to a Java Naming and Directory Interface value. EJB technology refs are only relevant on the local system; you will need to recode so that your lookup(s) use Java Naming and Directory Interface values instead. The J2EE Tutorial
has an example
Converter Application
which uses the following call to lookup the home interface of the Converter
Bean: Object objref = initial.lookup("java:comp/env/ejb/SimpleConverter");
When you deploy the Converter Application you use the name "MyConverter"
as the Java Naming and Directory Interface name for the Converter Bean. Therefore you need to change the
call to lookup the Home Interface to be as follows: Object objref = initial.lookup("MyConverter");
Following is a code snippet showing the complete process of looking up the
home interface of an enterprise bean from an application running on a remote
system: try {
Context.INITIAL_CONTEXT_FACTORY and
Context.PROVIDER_URL are static fields of the Context class that
can be used as a shorthand for the java.naming.factory.initial
and java.naming.factory.url.pkg properties.
It's possible to shorten this a little by always using URLs in your lookups.
For example, the following code will have the same result as the previous
example: try {
An example URL would be "iiop://tomato:1050/myBean" where tomato is the
EJB technology server name and 1050 is the port number.
A third option is to set the org.omg.CORBA.ORBInitialHost to be the name of the EJB server. You can do this either by passing in the property and it's value on the command line using the -D switch of the java command or you can do it programmatically using System.setProperty() . Via the command line: java -Dorg.omg.CORBA.ORBInitialHost=<serverName> ..........Via setProperty(): System.setProperty("org.omg.CORBA.ORBInitialHost", "<serverName>");
For other J2EE platform applications:
Generally the key is to find out the correct values for the java.naming.factory.initial and java.naming.factory.url.pkg properties for the application server that you are using and then follow the instructions outlined above. This set of FAQs will attempt to provide a comprehensive list of these in the near future:
18. How can I run a J2EE client application that is deployed on a remote system using runclient?If you are using the J2EE Reference Implementation's runclient application to run an application client on a remote system, you do not not need to make changes to the code that you used for testing on the local J2EE application server. Simply set the VMARGS environment variable to be -Dorg.omg.CORBA.ORBInitialHost=<serverName> and then use runclient as you would on the local system.
19. When I start deploytool, I get the message
This problem is seen with the J2EE
Reference Implementation v1.2.1 (j2sdkee1.2.1). It's caused by a problem
in parsing the applications XML deployment descriptor(s). The problem normally
happens when a class library (JAR file) that includes XML support is loaded
before the normal XML support libraries are loaded. This could be because
changes were made to the CLASSPATH when a Java application or package was
installed, or if an XML library is loaded into the
jre/lib/ext directory of your Java platform installation.
|