152 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
inrecord.setFormatHandler(infh);
outrecord.setFormatHandler(outfh);
// invoke IMS transaction and store result
ii.execute(iis,inrecord,outrecord);
ii.close(); ic.close();
out = (OUTBUFFER) outfh.getObjectPart();
// set result
confirmation.setMessage("Transaction completed successfully");
confirmation.setStockOrderBO(request.getStockOrderBO());
} catch (NamingException e) {
e.printStackTrace();
confirmation.setMessage("Transaction failed");
confirmation.setStockOrderBO(request.getStockOrderBO());
} catch (ResourceException e) {
e.printStackTrace();
confirmation.setMessage("Transaction failed");
confirmation.setStockOrderBO(request.getStockOrderBO());
}
}
In the try or catch block of the runTransaction() method, you find statements to
create and initialize the J2C connection spec and interaction spec objects. Also,
we created a J2C connection at the J2C connection factory and initialized the
J2C interaction. The execute() method at the J2C interaction requires that input
and output parameters extend the interfaces javax.resource.cci.Record and
javax.resource.cci.Streamable. To make use of the WSIF format handlers for
byte stream generation, we created the JCARecord class that implements both
interfaces. Example 6-3 shows the JCARecord class. The read() and write()
operations are used by the J2C framework to access the byte stream.
Example 6-3 JCARecord utility class
package com.itso;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import javax.resource.cci.Record;
import javax.resource.cci.Streamable;
import org.apache.wsif.providers.jca.WSIFFormatHandler_JCA;
public class JCARecord implements Record, Streamable {
private WSIFFormatHandler_JCA formatHandler_ = null;
public WSIFFormatHandler_JCA getFormatHandler() {
return formatHandler_;
}
public void setFormatHandler(WSIFFormatHandler_JCA formatHandler) {
formatHandler_ = formatHandler;
Chapter 6. EIS integration using Java Message Service 153
}
public String getRecordName() {
return null;
}
public void setRecordName(String arg0) {
}
public void setRecordShortDescription(String arg0) {
}
public String getRecordShortDescription() {
return null;
}
public void read(InputStream arg0) throws IOException {
if (formatHandler_ != null) formatHandler_.read(arg0);
else throw new IOException("FormatHandler has not been set");
}
public void write(OutputStream arg0) throws IOException {
if (formatHandler_ != null) formatHandler_.write(arg0);
else throw new IOException("FormatHandler has not been set");
}
public Object clone() {
return null;
}
}
As you can see in the runTransaction() method in Example 6-2 on page 151, the
J2C connection factory is retrieved by passing a local JNDI name starting with
java:comp/env. Make sure that you have defined the connection factory in the
EJB deployment descriptor. Go to the References tab of the EJB deployment
descriptor, highlight the feature session bean, and click Add. Figure 6-13 on
page 154 shows the reference for the Trader IMS feature.
154 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Figure 6-13 Create a reference to the J2C connection factory
As discussed in Chapter 3, “Scenario overview and design” on page 65, we
focused on creating a simple but complete sample scenario. In real
environments, we recommend that you design a comprehensive framework for
features and feature registration. You should address topics such as dynamic
registration of features and exception handling. Also, you should consider
whether to generate features from models by using the pattern and code
template mechanisms of Rational XDE Developer.
Creating the integration bean
An EIS component typically comprises a set of features. The integration bean is
the channel to all the features of an EIS component. We have implemented the
integration bean as EJB session bean that provides an invoke() method. The
input and output for the invoke() method are business objects. Based on context
information and business object that are passed, the integration bean decides
which feature to call (see Example 6-4 on page 155).
Chapter 6. EIS integration using Java Message Service 155
Example 6-4 Trader IMS integration session bean method
public StockOrderConfirmation invoke(StockOrderRequest request){
char context[] = request.getContext().toCharArray();
StockOrderConfirmation confirmation = new StockOrderConfirmation();
confirmation.setStockOrderBO(request.getStockOrderBO());
switch (context[0]) {
// TraderIMS feature
case 't':
// call TraderIMS feature
try {
InitialContext cxt = new InitialContext();
TraderIMSFeatureLocalHome localhome = (TraderIMSFeatureLocalHome)
cxt.lookup("java:comp/env/ejb/TraderIMSFeature");
TraderIMSFeatureLocal local = localhome.create();
local.setInput(request);
local.runTransaction();
StockOrderConfirmation result = local.getOutput();
return result;
} catch (NamingException e) {
e.printStackTrace();
confirmation.setMessage("Feature not available");
return confirmation;
} catch (CreateException e) {
e.printStackTrace();
confirmation.setMessage("Feature not available");
return confirmation;
}
// no feature found
default:
confirmation.setMessage("Feature not registered");
return confirmation;
}
}
For the Trader integration bean, we implemented a simple decision and used a
switch statement. Example 6-4 shows the invoke() method of the session bean.
We directly called the feature by passing the business object. No data
transformation should be implemented here, because data mapping is performed
by the feature classes. To call the feature session beans, we again used a local
reference that was defined in the EJB deployment descriptor. The definition is
similar to the process of defining a reference to the J2C connection factory for
the feature session bean. Make sure that you add a Local reference and use the
Local home and bean interfaces when calling the features. Promote the invoke()
method to the remote interface of the integration session bean to be able to call
the EIS component remotely.
156 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
6.4.3 Enabling the EIS component using JMS
In our approach for EIS integration, the EIS component is called from a system
process that is implemented using BPEL technology. WebSphere Studio
Application Developer Integration Edition provides a number of tools to create
services from artifacts such as Java classes and EJBs. The service definitions
are kept in three WSDL files: interface definition, binding details, and service
location details. Furthermore, the tool provides wizards to generate different
service bindings for various technologies (for example, EJB, JMS, and SOAP
Web services). The service WSDL file that describes the actual location of the
service can be easily imported into a BPEL process as a BPEL partner link.
We evaluated the different options to enable the EIS component to be called
from a BPEL system process. We recommend that you use the service
enablement wizards if EJB binding is required. If JMS binding is needed, we
found that development of JMS artifacts such as sender beans and
message-driven EJBs is a better approach. In our view, JMS enabling the EIS
component by manually creating JMS code has the following advantages:
???? JMS APIs are called directly and no WSIF calls are required, which means
there is no overhead that may lead to performance issues
???? The architect and developer have more options to select the message type
and format of the data that is sent over the wire
???? JMS connection factories, destinations, and interaction parameters can be
defined more easily
???? JMS topics can be used to broadcast messages to multiple EIS components
For the Trader EIS component, we have developed an MDB that calls the Trader
Integration session bean. Example 6-5 on page 157 shows the onMessage()
method for the bean. We chose to send serialized Java objects that are
encapsulated in the JMS message type ObjectMessage. The Java data type that
is accepted as input is a StockOrderRequest business object. The
TraderIntegration session bean is called using its local interface.
When creating the MDB using the EJB Creation wizard, you are asked to enter a
name for the JMS listener port. A JMS listener is a WebSphere specific notion of
the queue the MDB listens to. You need to configure the JMS listener port for the
WebSphere test environment.
Having created a test server, you open its configuration editor by double-clicking
the test server in Server Configuration view. First, go to the JMS tab to set up
JMS connection factories and destinations. Make sure that you enter the
destination to the list of queues at the top of the editor window. Click Add in the
EJB tab of the editor to set up the JMS listener ports. Make sure that you select
to start the port in the JMS listener creation wizard.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.