|
|
|
|
In Workshop for WebLogic, the WebLogic EJB project greatly eases development of Enterprise JavaBeans. This topic provides an overview of EJBs and the WebLogic EJB project in platform applications. It includes the following sections:
Note: Workshop for WebLogic provides tool support for EJB-related technologies available with WebLogic Server. For a few of developing Enterprise JavaBeans outside the context of Workshop for WebLogic, see Programming WebLogic Enterprise JavaBeans.
An EJB is a server-side component that encapsulates the business logic of an application. The business logic is the code that fulfills the purpose of the application, as opposed to code that provides infrastructure and plumbing for the application. In an inventory control application, for example, the EJBs might implement the business logic in methods called checkInventoryLevel and orderProduct. By invoking these methods, remote clients can access the inventory services provided by the application.
EJBs always execute within an EJB container, which provides system services to EJBs. These services include transaction management, persistence, pooling, clustering and other aspects of infrastructure. The J2EE and EJB architecture is built on a number of underlying technology standards, such as the JDBC API for database connectivity, JMS for messaging, and JNDI for naming and directory functionality. To learn more about these technology standards, see your favorite J2EE documentation and http://java.sun.com.
In Java EE 5 there are three types of EJBs: session, entity, and message-driven. Each of these types is described briefly in the following sections.
A session EJB is used to execute business tasks for a client on the application server. The session EJB might execute only a single method for a client, in the case of stateless session beans, or it might execute several methods for that same client, in the case of stateful session beans. A session bean is never shared by clients. A session EJB is not persistent, so when the client terminates, its session EJB disconnects and is no longer associated with the client.
You'll find more information on developing session beans in Developing Session Beans.
Note: For a few of developing session Enterprise JavaBeans outside the context of Workshop for WebLogic, see Session EJBs.
An entity EJB represents a business object in a persistent storage mechanism. Some examples of business objects are customers, orders, and products. The persistent storage mechanism is a relational database. Typically, each entity bean has an underlying table in a relational database, and each instance of the bean corresponds to a row in that table. Unlike session beans, entity beans are persistent, allow shared access, have primary keys, and may participate in relationships with other entity beans.
Developing Entity Beans provides information on how Workshop for WebLogic supports this component type.
Note: For a few of developing session Enterprise JavaBeans outside the context of Workshop for WebLogic, see Entity EJBs.
A message-driven EJB is an enterprise bean that is able to listen for Java Message Service (JMS) messages. The messages may be sent by any JMS-compliant component or application. Message-driven EJBs provide a mechanism for J2EE applications to participate in relationships with message-based legacy applications.
For more information, see Developing Message-Driven Beans.
Note: For a few of developing session Enterprise JavaBeans outside the context of Workshop for WebLogic, see Message-Driven EJBs.
EJB 2.0 exposes four types of interfaces for session and entity beans, called the local home interface, the local business interface (or simply, the local interface), the remote home interface, and the remote business interface (or simply, the remote interface). When you use annotations to develop EJBs, these interfaces are generated for you by the IDE. Attribute values in the annotations specify the names for the generated interfaces.
Client applications can obtain an instance of the EJB with which to communicate by using the remote home interface. The methods in the remote home interface are limited to those that create or find EJB instances. Once a client has an EJB instance, it can invoke methods of the EJB's remote business interface to do real work. The business interface directly accesses the business logic encapsulated in the EJB.
Interactions between EJBs defined in the same Workshop for WebLogic application, as well as interactions between EJBs and web services or page flows in the same Workshop for WebLogic application, can use the local interfaces instead, which provides a performance advantage over remote interfaces. In other words, the local home and business interfaces define the methods that can be accessed by other beans, EJB controls, web services, and page flows in the same Workshop for WebLogic application, while the remote home and business interfaces define the methods that can be accessed by other applications.
Message-driven beans do not have these interfaces, because these beans' methods do not get invoked directly by other beans or client applications. Instead they process messages from client applications or other EJBs that are delivered via the Java Message Service (JMS). When a message is delivered, the EJB container calls the message-driven bean's onMessage method to process the message. For more information on Java Message Service, see your favorite J2EE documentation. Workshop for WebLogic also provides JMS controls to work with a Java Message Service.
During run time, information about how EJBs should be managed by the EJB container is read from a deployment descriptor. The deployment descriptor describes the various beans packaged in an EJB JAR file, settings related to transaction management, and EJB QL for find methods, to name a few examples.
Note: The deployment descriptor should never be checked in to a source control system. The descriptor is repeatedly updated by Workshop for WebLogic during development.
Annotation attribute values in your EJB source code specify the values to be used in descriptors, which are then automatically generated by the IDE.
Note: For more on deployment descriptors, see EJB Deployment Descriptors.
The EJB JAR contains one or more EJBs, including their interface definitions, any related Java classes that are being used by the EJBs, and a deployment descriptor describing these EJBs.
The WebLogic EJB project is the development environment for session, entity, and message-driven beans in a Workshop for WebLogic application. A WebLogic EJB project contains one or more EJBs. A Workshop for WebLogic application can have one or more WebLogic EJB projects, as well as other types of projects such as web service projects and web application projects.
When you create a WebLogic EJB project and choose to associate it with an a WebLogic EAR project, a dependency is automatically created from all WebLogic Web projects currently in the EAR to the new EJB project (the creation of these dependencies can be disabled). To your WebLogic EJB project you can add EJB source code by using any of three source code templates: WebLogic Entity Bean, WebLogic Session Bean, and WebLogic Message Driven Bean.
As with other source artifacts, you can use the Annotation view to edit annotation attribute values that determine how EJB interfaces are generated, what goes into deployment descriptors, and so on.
A key advantage of developing EJBs in the WebLogic EJB project is that one file is used to store the definition of the EJB class, its interfaces, and deployment descriptor specific settings. Instead of managing the overhead of using several JAVA files to store this information, you can use one file to represent an EJB. This is accomplished by using EJBGen annotations.
Note: When developing Enterprise JavaBeans with Workshop for WebLogic be sure to use the WebLogic EJB Project project type, rather than the EJB Project also provided. The WebLogic EJB Project includes WebLogic EJB Extensions provided with the IDE.
When developing EJBs in Workshop for WebLogic, you use EJBGen annotations in the EJB source file. These annotations are used to mark methods to be exposed when generating remote and home interfaces and to specify deployment descriptor settings. In the IDE, you can find generated deployment descriptors will be under src/META-INF; generated interfaces are located under .apt_src.
You can edit these annotations directly or use the Annotations view. You might find that using the Annotations view, which is aware of the constant values that some annotation attributes require, makes things easier.
For more about EJBGen annotations, see the EJBGen Reference.
When you build an EJB project, the EJBs' source code is compiled and checked for errors. The build output of an EJB project is an EJB JAR containing the various JAVA and CLASS files for the bean class, its interfaces, and any dependent value or primary key classes, as well as the deployment descriptor for these beans. After the build completes, the beans are (re)deployed on the server. In addition, when you add, change, or remove EJB source files, Workshop for WebLogic runs the EJBGen tool to regenerate interfaces and deployment descriptors.
If the WebLogic EJB project is associated with a WebLogic Server server, the EJB module will be deployed to the server (either as a standalone EJB module or a the child of an EAR); if changes were made to the project since the last publish, ejbc is executed to generate and compile WebLogic EJB container classes for the EJBs.
EJB controls provide an alternative approach to make locating and referencing the EJB easy. Once you have created the EJB control, the client application can define the EJB control and use its methods, which have the same method names as the EJB it controls, to execute the desired business logic without having to be involved with locating and referencing the EJB itself. In other words, EJB controls take care of the prepatory work necessary to use an EJB, allowing you to focus on the business logic instead.
 |