Jcid V1

[Beichen Poque]

Toa J2EE client, a JEJB proxy service looks like a stateless session bean. A JEJB proxy service, on receiving the method arguments, passes their XML representation in the pipeline $body variable. POJO arguments are represented as the XML fragment, which contains the location of the actual POJO stored in the object repository within the pipeline. XML arguments can either be passed by value or by reference (referencing the actual object stored in the object repository). Primitive types are always passed by value.

The EJB transport, available only for business services, invokes remote EJBs through the Java Web Services (JWS) framework. The JEJB transport, which lets you invoke remote EJBs and external services with POJOs, passes POJOs directly through Service Bus to the target EJB methods using an RMI serialization/deserialization cycle. The EJB transport provides a "Support Transaction" flag, but all proxy services provide transactional support, making the transaction option unnecessary for JEJB business services.

For proxy and business services, the JEJB transport generates a Document-style WSDL file with Literal encoding that is used solely for describing the message passed to the pipeline. The WSDL format lets you leverage Service Bus WSDL features such as per-operation monitoring. The message structure defined in the WSDL file may differ from the actual pipeline message at runtime if you inline your POJO arguments in the message using the Pass XMLBeans by value option, described in Table 30-1.

The JEJB transport stores request exceptions in the object repository and propagates them to the JEJB proxy service through the $fault variable. The $fault variable would contain the location of the exception instance within the element, where jcid is the reference to the exception instance stored in the object repository.

A runtime or remote exception is thrown and the ongoing transaction has been set as rollback-only (likely by the EJB container), signifying the EJB container has been reached and a fatal error either occurred within the container or within the EJB itself.

Define an interface of type java.io.Serializable and include any necessary helper classes, such as business exceptions. The interface does not need to extend any class as long as the interface is valid for one of the RMI protocols described in JEJB Transport Endpoint URI, or is valid for JMS messages if you are using JMS to invoke EJBs.

Though not required, you can make the interface a remote interface as defined by the EJB 2.1 specification or annotate methods with the javax.ejb.Remote annotation to designate it as an EJB 3.0 business interface. For a simple POJO interface (no EJB remote interface) or an interface annotated with javax.ejb.Remote, the JEJB transport provider generates the 3.0 EJB interface out of the JEJB proxy service. For a remote interface, the JEJB transport provider generates the 2.1 EJB interface out of the JEJB proxy service.

To avoid unnecessary serialization/deserialization cycles, do not duplicate the JAR files uploaded as Service Bus archive resources to support Java callouts. Package all archive resource classes in a single JAR file so multiple Java callouts do not serialize/deserialize the objects.

Package your interface and dependent classes in a single client JAR file and import it into Service Bus. While this is the client JAR file you will select when configuring a service, it is not technically a fully expanded EJB client JAR file because it contains no stubs. The actual bean (hence WebLogic Server stub generation) does not exist until a JEJB proxy service is created and activated.

A JNDI provider resource allows you to specify the communication protocols and security credentials used to retrieve EJB stubs bound in the JNDI tree of remote Oracle WebLogic Server domains. Typically, the target EJB is not located in the same domain as Service Bus. In this case, you must register a JNDI provider resource. When the EJB is located in the same domain, you can define a provider to specify credentials and take advantage of stubs caching, though doing so is optional.

The JNDI provider has a high performance caching mechanism for remote connections and EJB stubs. The preferred communication protocol from Service Bus to an Oracle WebLogic Server domain is t3 or t3s. If messages need to go through a firewall, you can use HTTP tunneling.

In Figure 30-1, the JEJB proxy service serves as a stateless session bean to the EJB client interface. The JEJB transport provider for the proxy service generates a stateless session EJB from the remote/business interface in the client JAR and the pipeline, then deploys it as an EAR at the JNDI address specified in the endpoint URI.

The EJB client interface is a POJO with method arguments that the JEJB transport provider represents as a WSDL file and passes into the proxy service $body variable as XML. You can introspect the $body content to transform the message into the required format to pass to the business service and invoke the external service. The actual POJO is stored in the object repository, and the XML in the $body references it with a element.

In the response, provide a Java callout that converts the response to an EJB return format that is passed to the calling EJB method. View the proxy service's generated WSDL file to see the expected message format.

In Figure 30-2, a non-EJB client makes a call to a proxy service configured with a transport that matches the request; for example, a JMS proxy service making an invocation with a JMS topic or queue.

You configure a Java callout in the request, which converts the request into an XML representation of an EJB call in the $body variable. Put operations in the $operation variable. View the business service's generated WSDL file to see the expected message format. The JEJB business service uses its generated WSDL file to map the incoming message to the EJB remote interface and invoke the remote EJB method directly.

In Figure 30-3, the EJB call is passed through the proxy and business services to invoke another EJB method. Rather than making a direct RMI call outside of Service Bus, this architecture lets you leverage Service Bus features such as message routing, UDDI integration, alerts, monitoring, reporting, and result caching.

The JEJB transport provider for the proxy service generates a stateless session EJB from the remote/business interface in the client JAR file and the pipeline, and then deploys it as an EAR file at the JNDI address specified in the endpoint URI.

At runtime the JEJB proxy service receives a POJO as method argument, stores it in the object repository, and generates an XML representation of the POJO in the proxy service $body variable according to the generated proxy service WSDL file. The proxy service passes the message to the business service, and the business service uses its generated WSDL file to map the message to the remote interface and invoke the remote method directly.

Method names. The following are not included: operation aliases, parameters, and return details. Method names are passed in one property with all the method signatures appended. Method signatures are separated by the pound (#) character.

If the transport provider cannot find a JNDI provider, the import fails. However, if no JNDI provider is found but the host and port match the localhost IP and listen port, the resulting business service will be local (no JNDI provider).

Client JAR: The transport provider downloads the client JAR files and, if the manifest classpath exists in the JAR files, creates the corresponding JAR resources in the matching directory structure. The first URI in the list is the root client JAR file. If no manifest classpath exists in the JAR files, you must manually add the resource JAR files as dependencies to the root JAR file. If a resource in the imported client JAR file has the same name as another resource in the domain, the imported resource overwrites the existing resource.

The URI configured for a JEJB proxy service becomes the global JNDI name for locating the stateless session bean generated by the JEJB transport from the remote/business interface in the client JAR. The URL format is ejb_jndi_name.

For EJB 3.0, ejb_jndi_name is the mappedName attribute of the @javax.ejb.Stateless annotation in the generated bean. The lookup JNDI name for the generated EJB service is suffixed with #interface_class, which is the fully qualified name of the business interface.

Note: Type information is not available inline for XMLObjects passed by value. If you use this option, you cannot pass the typed XMLObject as the argument in a Java Callout in a proxy service pipeline.

Supports: The transport accepts an incoming transaction. Quality of service is exactly-once if the operation is invoked in a transaction and best-effort if the operation is invoked outside of a transaction.

Click Browse and select an EJB client JAR resource from the list displayed. The client JAR contains the remote or business interface for the remote EJB. The client JAR is registered as a generic archive resource.

Select the required methods from the list of available methods. The available methods depend on the JAR file being used. By default, all methods are selected. Expand a method to edit the default parameter values.

You can change the default operation name for a given method. By default, the operation name is the method name. If an EJB contains methods with same name (overloaded), you must change the operation names so that they are unique. WSDL files require unique operation names.

Enter a service account that will be used for authentication to access the service. If no service account is specified, an anonymous subject is used. This field is required if you selected Basic authentication.

3a8082e126