Access EJB services

Imports allow connectivity to services outside of IBM Business Process Manager environments, while exports are published interfaces from a component or import that offers its service to the outside world ( as a web service). EJB (Enterprise JavaBeans) services are accessed through the creation of EJB imports and exports. These sections tell you when to use an import or export, some related files and classes you may need for them and any restrictions.

Imports

Imports have interfaces that are the same as, or a subset of, the interfaces of the remote service they are associated with so that those remote services can be called. Imports also require binding information, which specifies the means of transporting the data from the modules. The EJB import binding invokes Java 2 Platform Enterprise Edition business logic using the EJB 2.1 or EJB 3.0 programming model.

The generated import will have data bindings that make the Java-WSDL connection instead of requiring a Java™ bridge component. This will allow for the direct wiring of a component with a Web Services Description Language (WSDL) reference to the EJB import which communicates to an EJB-based service using a Java interface.

An EJB import can be used in the following scenarios:

  • You have a PI (project interchange) file which was created in Rational Application Developer that has an EJB application.
  • You have a EJB client JAR file in the module.
  • You have EJB Java classes that have been copied in a project in the workspace.
  • You have an EAR file that contains the EJB application created outside of IBM Integration Designer.

Exports

External Java EE applications can invoke an SCA component by way of an EJB export binding. Using an EJB export lets you expose SCA components so that external Java EE applications can invoke those components using the EJB programming model.

The EJB export bindings can interact with Java EE business logic using either the EJB 2.1 programming model or the EJB 3.0 programming model.

When working with EJB imports and EJB exports, note the following:

The following topics describe concepts and step-by-step instructions for creating EJB imports and EJB exports using IBM Integration Designer:


Create EJB imports

You can use IBM Integration Designer to create EJB imports that invoke remote EJBs.

From IBM Integration Designer, you can create an EJB import in the following ways:

The following topics describe concepts and step-by-step instructions for creating EJB imports using IBM Integration Designer:



Create EJB imports using the external service wizard

You can use the external service wizard in IBM Integration Designer to build an EJB import service. The external service wizard is a tool used to create services based on criteria that you provide. It then generates business objects, interfaces, and import files based on the services discovered. The EJB import is created based on an existing EJB implementation and the newly created import can then be deployed to Process Server.

Before beginning, copy the necessary JAR file or classes to the module, library or any other project to ensure they are available in the workspace.

To build an EJB import service using the external service wizard, follow these steps:

  1. Launch the external service wizard in IBM Integration Designer by clicking File > New > External Service.

  2. From the external service wizard window, select JavaEnterprise JavaBeans Binding and click Next. Note that you can also launch this wizard by selecting a module in the business integration (BI) view and right-clicking and selecting New > External Service > Java > Enterprise JavaBeans Binding.
  3. The New Enterprise JavaBeans Binding Service window opens. For EJB imports, select the Outbound processing option for the direction of binding processing to be used at run time. After you have made the selection, click Next.

  4. Select the module where the generated artifacts should be saved. You can select an existing module from the drop-down list, or create a new one by clicking New. You can also indicate the folder to be used. After you have made the selection, click Next.

  5. Select an available interface from the list. This will create a reference to an enterprise bean that is accessed through its local or remote interface. Note the dependent JAR files have to exist in the workspace as a Java 2 Platform Enterprise Edition utility. You can further filter the list of available interfaces using the All, Remote, or Local options from the drop-down list.
  6. Provide the JNDI name (if it was not automatically discovered) and click Next or click Finish to create the EJB import service.

  7. If the creation of the EJB import service failed, you will receive an error message stating Failed to generate interfaces and business objects. Check the log file.. Review the workspace error .log file located in %WORKSPACE%\.metadata folder for details regarding the failure and how to fix it.


An EJB import is created and shown in an assembly diagram in the assembly editor. You can select the EJB import and change the properties as required from the Properties tab.



Related concepts:

JNDI names


Related reference:

EJB 3.0 and EJB 2.1

JAXB and EJBs


Create EJB imports using the assembly editor

You can create an EJB import within an assembly diagram using the IBM Integration Designer assembly editor.

To create an EJB import service using the palette in the assembly editor, choose from the following options:

Use the Outbound Imports drawer

  1. Select the Outbound Imports drawer from the palette of the assembly editor.
  2. Drag the enterprise bean from the list of available outbound imports to the canvas of the assembly editor.
  3. The New Enterprise JavaBeans Import Service window opens and lists all the EJB remote and local interfaces available in the workspace. From this window, select an EJB remote or local interface as a reference the enterprise bean is accessed through and provide the JNDI name (if it was not automatically discovered).

  4. Click Finish to add the EJB import to the assembly diagram.

Drag and drop an EJB session bean object

  1. Drag an EJB session bean object on to the canvas of the assembly editor.
  2. The New Enterprise JavaBeans Import Service window opens. From this window, indicate the type of interface for the EJB import (WSDL or Java™) and select the EJB interface. Note there might be more than one EJB interface discovered ( EJB 3.0 local interface, EJB 3.0 remote interface, and so on).

  3. Click Finish to add the EJB import to the assembly diagram.

Drag and drop an EJB session bean file

  1. Drag an EJB session bean file on to the canvas of the assembly editor.
  2. The New Enterprise JavaBeans Import Service window opens. From this window, indicate the type of interface for the EJB import (WSDL or Java) and select the EJB interface. Note there might be more than one EJB interface discovered ( EJB 3.0 local interface, EJB 3.0 remote interface, and so on).

  3. Click Finish to add the EJB import to the assembly diagram.

Drag and drop an EJB local or remote interface

  1. Drag a local or remove interface on to the canvas of the assembly editor.
  2. The New Enterprise JavaBeans Import Service window opens. From this window, indicate the type of interface for the EJB import (WSDL or Java) and provide the JNDI name if it cannot be automatically discovered by the wizard.

  3. Click Finish to add the EJB import to the assembly diagram.

An EJB import is created and shown in an assembly diagram in the assembly editor.


You can select the EJB import and change the properties as required from the Properties tab.



Related concepts:

JNDI names


Related reference:

EJB 3.0 and EJB 2.1

JAXB and EJBs


JNDI names

JNDI (Java Naming and Directory Interface) names are used to provide a usable name for a Java objects. IBM Integration Designer uses the JNDI name to determine the EJB programming model level and the type of invocation (local or remote). You may sometimes need to provide the JNDI name when creating EJB imports and the format of the JNDI name required in an interface depends on the type of invocation you are using.

The following table shows the required JNDI name formats by invocation type:

JNDI name formats

Invocation type JNDI name format
EJB 2.1 (remote) com/test/example
EJB 2.1 (local) ejblocal:com/test/example
EJB 3.0 (remote) com.test.example
EJB 3.0 (local) ejblocal:com.test.example

For more information regarding JNDI names, see the Rational Application Developer information center at http://publib.boulder.ibm.com/infocenter/radhelp/v7r5/index.jsp



Related tasks:

Create EJB imports using the external service wizard

Create EJB imports using the assembly editor


Related reference:

EJB 3.0 and EJB 2.1

JAXB and EJBs


Configure properties for EJB imports

The properties of an EJB import can be edited as required from the assembly editor using the Properties view.

You should know how to create an EJB import.

The following properties of the EJB import can be edited:

Description

From the Description tab in the Properties view you can refactor the name of the EJB import as well as the folder name. The display name is not used in the assembly diagram, but it is used in some runtime processes. You can also enter a description for the import for additional clarification if needed. If you leave the Synchronize with the name field box selected, the name and the display name will remain the same.

Details

From the Details tab in the Properties view you can edit component's interfaces and partner references. A tree view lists all the interfaces and references. Select one of them to display its properties in a Details page, a Qualifiers page, and an Event Monitor page.

Qualifiers

From the Qualifiers tab in the Properties view you can set the Quality of Service (QoS) for the components. An application communicates its QoS needs to the runtime environment by specifying service qualifiers. They govern the interaction between a service client and a target service. Click Options to set or edit the service options for the EJB import.

Binding

From the Binding tab in the Properties view you can edit the binding information for the EJB import.

  • JNDI name - The JNDI Name is the logical name that an EJB import would use to look up the EJB instance. See the topic Administer EJB bindings in the BPM information center.
  • Data Handler - The data handler provides transformation function for transforming from one form to another. The transformation may map into a provided target or into a new instance of a specified target.
  • Fault Selector - The fault selector generates a fault identifier that can be matched with one of the faults associated with the specific outbound operation.
  • Function Selector - The function selector is an artifact that allows an EJB import to determine which EJB method should be invoked for a given WSDL method on the EJB import. EJB import function selector is the default value and it uses JAX-WS mapping to determine the EJB method. See the BPM information center.
  • Faults configuration - The configuration of the fault handler is optional. By default, JAX-WS data handler configured at the EJB import level is used for all of the faults.

Method bindings are not supported for EJB import bindings.

To edit the properties of an EJB import, follow these steps:

  1. From the assembly editor, select the EJB import in the assembly diagram.

  2. Select the Properties tab to view the properties for the EJB import and edit the values for them as required.

    Save the changes.



Create EJB exports

You can use IBM Integration Designer to expose SCA components using an export with an EJB binding so that external Java 2 Platform Enterprise Edition applications can invoke those components using the EJB programming model.

From IBM Integration Designer, you can create an EJB export in the following ways:

Note that you cannot use drag from the business integration view to add EJB exports to assembly diagrams in the assembly editor. Once you have created a service with an EJB binding, a client accessing this service must run in a client, web or EJB container for the dynamically downloaded stubs at run time to be accessible (see EJB clients).

The following topics describe concepts and step-by-step instructions for creating EJB exports using IBM Integration Designer:



Create EJB exports using the external service wizard

You can use the external service wizard in IBM Integration Designer to create an EJB export. The external service wizard is a tool used to create services based on criteria that you provide. It then generates business objects, interfaces, and import files based on the services discovered.

To create an EJB export using the external service wizard, follow these steps:

  1. Launch the external service wizard in IBM Integration Designer by clicking File > New > External Service.

  2. From the external service wizard window, select JavaEnterprise JavaBeans Binding and click Next. Note that you can also launch this wizard by selecting a module in the business integration (BI) view and right-clicking and selecting New > External Service > Java > Enterprise JavaBeans Binding.
  3. The New Enterprise JavaBeans Binding Service window opens. For EJB exports, select the Inbound processing option for the direction of binding processing to be used at run time. After you have made the selection, click Next.

  4. Select the module where the generated artifacts should be saved. You can select an existing module from the drop-down list, or create a new one by clicking New. After you have made the selection, click Next.

  5. Select an interface to base the binding on by clicking Browse. From the interface selection window that opens, you can select from a list of existing interfaces (note that you can sort this list by using the Show WSDL and Java, Show WSDL, and Show Java radio buttons). Or, you can create a new WSDL or Java interface by clicking New. After you have made the selection, click Next. Note that if a Java interface is selected, it must be a business interface and cannot be an EJB local, remote or home interface.

  6. From this window, decide whether to create an EJB client JAR module containing the client interfaces and classes that will be generated for use in a Java platform application. Click New to create a new module, or select an existing one from the drop-down list. If you decide not to create an EJB client JAR module at this time, you can create it later from the EJB export binding menu (right-click the EJB export and select Generate EJB Client Interface).

  7. Use the check boxes, indicate if the interfaces in the EJB client JAR module will be remote or local EJB 3.0 interfaces or remote EJB 2.1 interfaces.

  8. Click Finish to create the EJB export.


An EJB export is created and shown in an assembly diagram in the assembly editor. You can select the EJB export and change the properties as required from the Properties tab.



Create EJB exports using the assembly editor

You can create an EJB export within an assembly diagram using IBM Integration Designer's assembly editor.

To create an EJB export using the palette in the assembly editor, choose from the following options:

  1. Select the Inbound Exports drawer from the palette of the assembly editor.
  2. Drag the Enterprise JavaBeans from the list of available inbound exports to the canvas of the assembly editor.
  3. The New Enterprise JavaBeans Export Service window opens. From this window, select an interface from the drop-down list for the binding to be based on and click Next.

  4. From this window, decide whether to create an EJB client JAR module containing the client interfaces and classes that will be generated for use in a Java™ platform application. Click New to create a new module, or select an existing one from the drop-down list. If you decide not to create an EJB client JAR module at this time, you can create it later from the EJB export binding menu (right-click the EJB export and select Generate EJB Client Interface).

  5. Use the check boxes, indicate if the interfaces in the EJB client JAR module will be remote or local EJB 3.0 interfaces or remote EJB 2.1 interfaces.

  6. Click Finish to create the EJB export.


An EJB export is created and shown in an assembly diagram in the assembly editor. You can select the EJB export and change the properties as required from the Properties tab.



EJB 3.0 and EJB 2.1

EJB 3.0 has some significant differences with EJB 2.1. You should be aware of these differences when developing applications with EJB bindings based on 3.0 or higher.

EJB 3.0 was a rethinking of Enterprise JavaBeans (EJBs) based on an analysis of growing difficulties that developers had experienced as they developed applications using EJBs. The challenges addressed by EJB 3.0, the differences between EJB 3.0 and its predecessor, EJB 2.1, and a change to the local interface in EJB 3.0 are discussed below.


Challenges addressed by EJB 3.0

The EJB architecture was designed for applications with distributed components. BeforeEJBs, Common Object Request Broker Architecture (CORBA) had become one well-known standard that handled distributed objects but CORBA became complex and synonymous with difficult to use. As the EJB standard evolved, it too began to pick up many features and acquired a reputation as being too complex to use for developers. The following list of complaints were associated with EJBs by the time of EJB 3.0:

The next sections are a high-level look at the differences between EJB 3.0 and EJB 2.1. They are a starting point to understanding EJB 3.0 in particular. However, to learn EJB 3.0 in depth then you should read a book on the specification. Many EJB 3.0 books are available at most libraries. They provide code samples, recommendations and tips when building applications that use EJB 3.0. The following links also provide helpful information.


Differences between EJB 3.0 and EJB 2.1

For over a decade EJBs have been a key element of large-scale application development written in Java. Over this period EJBs evolved into a standard framework for the development, deployment and execution of distributed components that are used in multi-user environments. The framework included services for lifecycle monitoring, concurrency, pooling resources, transactions, security and persistence.

By the time of EJB 2.1, these standard features were available to developers working with EJBs: session beans for non-persistent data and entity beans for persistent data; an XML deployment descriptor; a local or home interface though only clients inside the Java 2 Platform Enterprise Edition container could access it; message-driven beans for asynchronous messages; and support for web services that exposed an endpoint so that an EJB could be invoked when needed. The result of these features though was that developers had to write a lot of code just to create an EJB. For example, developers needed to code a home interface, a component interface, a bean class, and a deployment descriptor which for an entity bean could be itself complex. Developers were also required to code methods for lifecycle management even if they were not called.

EJB 3.0 introduced the following major changes, which have led to a simplified programming model:

EJB 3.0 is formally defined in JSR 220: Enterprise JavaBeans 3.0.. This JSR is over 800 pages and is divided into three sections: the Java Persistence API defines the persistence framework and discusses entities; the EJB Core Contracts and Requirements section covers message-driven and session beans; and the EJB Simplified API provides an overview of the EJB development model;


How an EJB with a local interface works

Based on the previous sections, EJB 3.0 led to a significant simplification of the EJB specification. This is especially true for an EJB with a local interface (that is, an EJB that will run in the same JVM as the client). How simple? The following lines of code create an EJB interface.

package ejbeasy;

public interface EasyEJBClaim {
 public void stateClaim(String myName);}

These lines create the implementation in a stateless session bean.

package ejbeasy;

import javax.ejb.Stateless;

@Stateless
public class EasyEJBClaimBean implements EasyEJBClaim {
 public void stateClaim(String myName){
  System.out.println(myName + "says What could be simpler?");
 }}

The interface is a POJO interface and the bean class is a POJO. The @Stateless annotation converts the POJO to a stateless EJB.



Related concepts:

JNDI names


Related tasks:

Create EJB imports using the external service wizard

Create EJB imports using the assembly editor


JAXB and EJBs

A valid generated XML Schema Definition (XSD) is not necessarily valid in the context of generated Java beans based on it.


How XSD and JAXB differ

Because an XSD is consists of valid XML code, you should not assume that you can generate JavaBeans from it, which could be your goal if you work with the Java Architecture for XML Binding (JAXB). For example, you can have an element and an attribute with the same name and at the same level in XSD code. But converting this code to a Java bean, which has different rules governing its behavior, will result in an error.


How to modify an XSD to be acceptable to JAXB

If you are facing the previous problem, there are four ways you could modify the generated code to make it acceptable to the JAXB standard:

For example, suppose there is some XSD code containing an element and attribute with the same name, field2. You could use JAXB annotations to modify the Java property for the attribute to field4 as shown below.

<?xml version="1.0" encoding="UTF-8"?>
   <xsd:schema targetNamespace="http://JAXBExport"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    jaxb:version="2.0">
    <xsd:complexType name="Test">
     <xsd:sequence>
      <xsd:element minOccurs="0" name="field1" type="xsd:string">
      </xsd:element>
      <xsd:element minOccurs="0" name="field2" type="xsd:string" />
     </xsd:sequence>
     <xsd:attribute name="field2" type="xsd:string">
      <xsd:annotation>
       <xsd:appinfo>
        <jaxb:property name="field4"/>
       </xsd:appinfo>
      </xsd:annotation>
     </xsd:attribute>
    </xsd:complexType>
   </xsd:schema>



Related concepts:

JNDI names


Related tasks:

Create EJB imports using the external service wizard

Create EJB imports using the assembly editor


+

Search Tips   |   Advanced Search