ServicesTabEjbNodeFuncSpec

EJB Node in the Services Tab

Modification History:

Winston Prakash - Feb 06, 2007


Note: This is just sample or a starter document to start the discussion based on Services Tab Architecture. Does not correctly reflect the implementation details. Need to be re-written by the Service Type implementor. - Winston



Contents


Introduction

The EJB support can be divided into two parts: EJB development/deployment and EJB consumption. This document only covers the EJB consumption support in the Services Tab. The goal of the EJB consumption functionality is to help the user to create an applications using the business logic already defined in EJB components. One way of adding the EJBs to the application created in Netbeans is by first adding them to the EJB root node in the Services Tab and then drag and drop the EJB or one of its methods to a consumer such as VWP designer or JSP editor.

Assumption

Currently, it is assumed that the user has already developed and deployed some EJBs into some EJB container and the EJBs are ready for consumption by an application.

However, in future there will be support to add the EJB actively being developed using Netbeans IDE.

Supported EJB container and Web container

Theoretically, we can support any EJB container. But in reality, different container behaves a little differently. So, extra development time is needed for supporting additional EJB containers. Expected EJB containers that will be supported in the near future are

  • Sun Application Server
  • WebLogic
  • WebSphere
  • JBoss


EJB discovery using Client jar file

Ideally, the user enters an URL of the EJB container and Netbeans then magically discover all the EJBs deployed on the container. But in reality, there is no standard defined in the EJB sepcs for automatically discovering the deployed EJBs. The container vendors do not provide any proprietary mechanisms to do this either.

Client jar file contains all the necessary classes for a client (in our case, it's the web application) to call the EJBs. If the web application is running in a J2EE environment, the client jar file only needs to contain the home interfaces, remote interfaces and the classes those interfaces depend on. But if the web application is running in a standalone web container, then the stubs for the remote interfaces are also needed. In order for us to be able to display the EJBs in Netbeans, we also need the client jar to include the EJB deployment descriptors.

For details on how to get the client jar files, please refer to the documentation of each application server vendor. Although some application servers provide tools to help the user generate the client jar files, the user can still create the client jars on their own.

The client jar file will be loaded into Netbeans using the add EJBs dialog. This jar file will be package into the final WAR file and deployed to the target web container.


Client jar for Sun Java Application Server

For Sun Java Application System 8, the user can request for a Client jar file and save it on a local directory during deployment time. If the user didn't request at the deployment time, the file can still be generated using utility tools. The command in SunAppServer 8 is “asadmin get-client-stubs --user user --appname app_name local_dirpath”. The client jar file generated from SunAppServer8 contains the deployment descriptors (ejb-jar.xml and sun-ejb-jar.xml), home interfaces, component interfaces, bean classes, the stubs for the remote home and component interfaces and the classes which the interfaces depend on.

Client jar for WebLogic Server

WebLogic has a similar java-based utility tool - “java -classpath <weblogic_install_dir>weblogic81/server/lib/weblogic.jar weblogic.appc -iiop <ear, jar file, or classes>” to help the user generate a client jar file containing the home interfaces, component interfaces, the stubs for the remote interfaces and all the classes the interfaces depend on. The jar file also contains the deployment descriptors (ejb-jar.xml and WebLogic-ejb-jar.xml) with the above command (Note: giving option “-basicaClientjar” will exclude the xml files).

Client jar for WebLogic Server

WebSphere deployment process does not produce one client jar file for the whole application, instead you can get one client jar per EJB module. There is no utility tool provided to help the user generate one client jar from a deployed application (.ear) either.

Client jar for JBoss

Not fully known yet!

Extracting EJB information

The EJB informations displayed in the Services Tab via the EJB nodes are extracted from either the client jar files or the additional .ear or .jar file specified by the user in the add EJBs dialog . Usually the deployment descriptors are contained in jars which are contained in the given .jar or .ear files. Netbeans first recursively exams all the jar files to find the ejb-jar.xml and <vendor>-ejb-jar.xml files. It then parses the xml files to get the necessary EJB information. The home interfaces, component interfaces are found from the standard deployment descriptors. The business methods are figured out using Java reflection. The JNDI names of the remote EJBs are from the vendor specific deployment descriptors.

Adding EJB

User adds the EJB by right clicking and selecting “Add Set of Session EJBs...” menu item on “Enterprise Java Beans” node in the Services Tab, which would bring up the following wizard dialog.


  • EJB Set Name: This is just a grouping name for the EJBs going to be added. The name will be used for display in the server navigator only. The name can contain any printable characters. The default name is as shown. If Netbeans finds out the user given name is not unique, a trailing integer will be added to make it unique.
  • Application Server: It is the vendor name of the application server where the EJBs are deployed. For Reef Shark, the supported list include Sun Application Server 8, Sun Application Server 7, WebLogic 8.1 and WebSphere 5.1. The list can go longer in the future. The default application server is Sun Application Server 8.
  • Server Host: It is the name of the host where the application server is running on. “localhost” is the default value.
  • RMI-IIOP: It is the port number for looking up and communicating with the remote EJBs. Different default port number will be displayed depending on the application server selected in the Application Server combo box. It is 3700 for Sun Application Server, 7001 for WebLogic and 2809 for WebSphere.
  • Client jars: Multiple client jars can be added. The “Add...” button on the right side allows the user to choose the desired client jars. The “Remove” button is disabled initially because there is no client jar to remove. It'll be enabled when the first client jar is added. It'll be disabled again when the very last jar is removed. The client jars specified here will be packaged into the final WAR file.
  • EJB Deployment Descriptor: This field is not necessary if the client jars added above including the deployment descriptors. But if the above client jars do not include the necessary EJB deployment descriptors, then the user can give the jar or ear file where the EJB deployment descriptors can be found. The jar or ear file specified here will not be include in the final war file. The only purpose of this file is to get the EJB deployment descriptors.

When the user clicks “Next” button, the first thing Netbeabs does is validating the user input data. Error message box will pop up if invalid data is found. Refer to HIE's UI specification for possible error messages.

Export EJB Sets

When the user exits from Netbeans, all the EJB information are saved in <userdir>ejb-datasource/ejbsources.xml. The information will be restored from this file when the user runs Netbeans again later.

This functionality exports the EJB information and data into a jar file. The exported jar file contains the ejbsources.xml, the client jars and the wrapper jars. In the export dialog, the EJB Set name, Server Host and RMI-IIOP Port are modifiable.

Import EJB sets

The first dialog the import brings up is the file chooser. After the user has chosen a jar file, which was exported by the export functionality, to import from, the following dialog shows up. As in export, the EJB Set Name, Server Host and RMI-IIOP Port are modifiable. The selected EJB sets will be displayed in the server navigator upon a successful import.


Modify EJB Set

There are two ways to modify an EJB set. One is by bring up the following dialog. The other one is modifying in the properties sheet. Only the EJB set name, server host and RMI-IIOP Port are modifiable. If the user wants to modify the client jars or the deployment descriptor jar./ear file, he or she needs to remove the old EJB set and add a new one.


Refresh

Refresh rereads all the client jars and the EJB deployment descriptor jar/ear file if there is no. It also regenerates the bean wrapper classes. The refresh is useful for the case where the user redeployed the EJBs with a newer version. Delete

It deletes the selected EJB set from the server navigator. It does not remove the client jars.


Adding EJB Root Node to Services Tab

The EJB Root Node is added to the Services Tab, via the contract published by Services Tab. So the root node should be added via the layer file as

<folder name="UI">
   <folder name="ServicesTab">
          <file name="org-netbeans-modules-ejb-nodes-EjbsRootNode.instance" />
   </folder>
</folder>
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo