Chapter 2. Architecture 39
Local versus remote EIS components
Table 2-9 looks at some of the key differences between using local and remote
EIS components.
Table 2-9 Local versus remote EIS components
Local Remote
EIS component is physically local to the
EIS system process and runs on the same
tier.
The EIS component can be physically
remote to the EIS system process on
another tier.
EIS component is exposed as a local
service, typically using a EJB binding.
The remote EIS component can be a J2C
service, in which case it is not the EIS
component being called, but rather a J2C
connector service. In this scenario, the
J2C connector is exposed as a service.
See Exploring WebSphere Studio
Application Developer Integration Edition
V5, SG24-6200 for detailed explanations
and samples on how to expose J2C
connectors using Web services.
The EIS system process has a static
reference to the EIS component that can
be a static partner link in a BPEL process.
The remote EIS component can have an
adapter (for example, a JMS, TCP/IP, or
SOAP/HTTP adapter) exposing it over the
WAN or even the Internet. In this scenario,
the adapter calls the local EIS component
(the EIS component that is local to the EIS
adapter).
An EIS component can be deployed on
another physical tier, where the remote
node (the node to where the EIS
component is deployed) does not have a
Business Process Choreographer engine
and container to execute the (BPEL) EIS
system process.
In this scenario, a business process calls
its local EIS system process, and the EIS
system process then calls the remote EIS
component.
The EIS system process can use proxies,
which can be defined in the configuration
source, to call a remote EIS component.
40 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
EIS integration feature classes
A J2C connector must have the correct byte buffer to integrate with a back-end
transaction. Likewise, a JDBC connection must have a SQL statement,
CallableStatement (for stored procedures) or a PreparedStatement. A feature
class must either create a byte buffer for a J2C connector (that is, CICS or IMS),
or it must create the SQL Statement, using a domain or general data object.
A feature class typically does the following:
???? Get data values from a domain or general data object to create:
– Statement, CallableStatement (for stored procedures) or a
PreparedStatement
– Byte buffer for a IMS or COBOL transaction
(See “Domain objects” on page 28 for a discussion on domain objects.)
Example 2-1 shows a feature class creating a back-end transaction request
record using a generic data object.
Example 2-1 Feature class creating a back-end transaction using a generic data object
/**
* get the data values from the generic request
* data object
* data values will be used to create a request
* for the back-end transaction
*/
public void setRequest(Object request) {
EISDataVO genericRequest = (EISDataVO) request;
// get the data attributes from the generic request data object
Attribute[] data = genericRequest .getChildren();
// get the data from the generic request record
companyName = EISDataVOHelper.getAttributeValue("company-name", data, true, "N/A");
userID = EISDataVOHelper.getAttributeValue("userid", data, true, "N/A");
String temp = EISDataVOHelper.getAttributeValue("number-of-shares", data, true, "0");
numberOfShares = Short.parseShort(temp);
}
/**
* create request byte buffer for back-end transaction
* using generated helper classes
*/
public Object createEISRequestRecord() {
COMMAREABUFFERFormatHandler handler = new COMMAREABUFFERFormatHandler();
COMMAREABUFFER buffer = (COMMAREABUFFER) handler.getObjectPart();
// set parameters to input record
Chapter 2. Architecture 41
buffer.setRequest__type("Buy_Sell");
buffer.setCompany__name(companyName);
buffer.setUserid(userID);
buffer.setNo__of__shares__dec(numberOfShares);
buffer.setUpdate__buy__sell("1");
buffer.fireElementEvents();
byte[] b = handler.getBytes();
return new GenericRecord(b);
}
–A J2C InteractionSpec (for example a CICS
com.ibm.connector2.cics.ECIInteractionSpec)
Example 2-2 shows a feature class creating a J2C CICS
ECIInteractionSpec.
Example 2-2 Creating a J2C CICS InteractionSpec in a feature class
public InteractionSpec getInteractionSpec() {
ECIInteractionSpec is = new ECIInteractionSpec();
is.setCommareaLength(commAreaLength);
is.setInteractionVerb(ECIInteractionSpec.SYNC_SEND_RECEIVE);
is.setReplyLength(commAreaLength);
is.setTPNName("TRDR");
is.setFunctionName("TRADERBL");
return is;
}
– JMS features that create a request data object and potentially handle a
response data object
The request or response data objects can be an XML document
???? Handle the response from a J2C connector or JDBC call to create a response
domain or general data object. (See “Domain objects” on page 28 for a
discussion on domain objects.)
For IMS and CICS ECI services, if you need to write code that works directly with
the byte buffers, you can use the WebSphere Studio Application Developer
Integration Edition to help you generate helper classes and format handlers from
your IMS or CICS ECI application's C structures or COBOL copybooks.
42 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Feature classes can use these generated classes to create the request byte
buffers and to parse the response byte buffers from the back-end system into a
bean.
Example 2-3 shows a feature class parsing a back-end transaction response,
using helper classes, into a generic response data object.
Example 2-3 Parsing a response byte buffer into a generic response data object, using helper classes
public Object handleEISResponseRecord(Object eisResponse) {
// cast eis response object to GenericRecord
GenericRecord gr = (GenericRecord) eisResponse;
// use generated helper classes to parse back-end transaction
// response byte-buffer
COMMAREABUFFERFormatHandler handler = new COMMAREABUFFERFormatHandler();
handler.setBytes(gr.getCommarea());
COMMAREABUFFER bean = (COMMAREABUFFER) handler.getObjectPart();
// create a generic response data object
List detail = new ArrayList();
detail.add(EISDataVOHelper.createAttribute("company1", bean.getCompany__name__tab(0)));
detail.add(EISDataVOHelper.createAttribute("company2", bean.getCompany__name__tab(1)));
detail.add(EISDataVOHelper.createAttribute("company3", bean.getCompany__name__tab(2)));
detail.add(EISDataVOHelper.createAttribute("company4", bean.getCompany__name__tab(3)));
EISDataVO response = new EISDataVO();
response.setName(("Trader Company List"));
response = EISDataVOHelper.setChildren(response, detail);
return response;
}
Alternatively, you can also use your own helper classes or frameworks that you
might have in your organization to create and parse the back-end transactions
byte buffers.
The function of an EIS integration feature class is to get data from domain or
general data object, create a request that can be handled by a J2C connector or
database Connection, and parse the response from the back-end system to
create a response data object.
A feature class knows how to use a domain or general data object. For example,
a CreateCustomerRecord feature class can cast a request Object into a Customer
domain object or bean. Alternatively, it can interpret a generic data object to get
the name and value pairs describing the customer record, or it can parse an XML
Chapter 2. Architecture 43
document to get the customer details. It uses these details to create the request
object (a byte buffer or a SQL Statement or even a XML document) that is used
by a J2C connector to connect to and execute a back-end transaction.
EIS components
The EIS component is a facade into any one of the EIS integration components.
The EIS component does not use a J2C connector or a DataSource directly.
Rather, it delegates a request from the EIS system process to one of its
integration components to handle the back-end system integration. See
Figure 2-10 on page 47 for a detailed view of the EIS component and its EIS
integration components in context to the structural view of the logical
architecture.
Note: Ideally, feature classes must be at a granular level that enables and
supports re-use of feature classes. Typically, you have a feature class for
every back-end transaction to create the request byte buffer and to handle the
response byte buffer from the back-end transaction. However, you can
potentially have one feature class supporting many back-end transactions or
many database transactions.
For example, you could have a JDBC feature class that performs multiple
database transactions. While this scenario is not a problem, consider that
other projects or developers might want to re-use some of your feature
classes in their development efforts. If your feature does many things, instead
of one thing, chances are good that your feature class is not re-usable across
projects or other use case implementations by other developers.
As an example, decide how you would implement the following scenario. You
must get the details of a branch or center, and you must get the description of
a product. You need to get this data in a business process for one of your use
cases. You can implement the feature(s) this way:
???? One feature class that performs two SQL queries
???? Two feature classes, each performing only one SQL query, one against the
branch or center table and the other against the product descriptions table
Both implementation options have benefits and drawbacks, depending on
which way you look at it (developer role versus enterprise architect versus
business executive). Think of performance versus re-use and so on.
Be aware that you do have choices when you design and implement your
feature classes. Consider not only the standards and principles of your
project, but also what your organization or customers’ standards and
principles are, specifically considering re-use of components across projects
and development teams.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.