To enable migrated applications to function in WebSphere® Process
Server consistently with their intended function in WebSphere InterChange Server, special
attention is required in some areas due to differences between the architectures
of WebSphere Process
Server and WebSphere InterChange
Server.
Compensation levels
Since there is no direct mapping
of the levels of compensation between WebSphere InterChange Server collaborations
and WebSphere Process
Server BPEL, the compensation level specified in the WebSphere InterChange Server Collaboration
is ignored and the default BPEL compensation level will be used in the migrated
application. You should understand BPEL compensation and adjust your migrated
applications accordingly to get the desired functionality.
InstallAdministrativeObjects.py script
For WebSphere InterChange
Server artifacts that have no corresponding artifact in WebSphere Process
Server, a Jython
® script is generated during migration. The script
can be run with the
wsadmin command to create WebSphere Process
Server configuration definitions corresponding to the original WebSphere InterChange
Server artifacts. The WebSphere InterChange Server artifacts that are
handled in this manner are DBConnection pools, relationship databases, and
scheduler entries. The Jython script that is generated is called
InstallAdministrativeObjects.py,
and a copy of it will be included wherever the shared artifacts are included.
That is, the
InstallAdministrativeObjects.py script is
included in every jar file created by the ReposMigrate command, and it is
put in the library project specified during import in WebSphere Integration Developer.
An
InstallAdministrativeObjects.py script is always generated
even if there are no artifacts that require it. This script can be modified
to add or delete entries before using
wsadmin to execute
it. Note the following:
- The InstallAdministrativeObjects.py script will use
default JDBC provider templates to create JDBC providers if an appropriate
JDBC provider is not already defined. A side effect of using these default
JDBC provider templates is that an empty, sample datasource definition is
created. This sample datasource is not used. Delete it to prevent exceptions
that might occur during server start-up due to the fact that the sample datasource
does not specify all of the information required for a datasource .
- To simulate the WebSphere InterChange Server environment, that
is, an environment in which resources are defined once for the WebSphere InterChange
Server system, the InstallAdministrativeObjects.py script
defines resources at the cell scope in WebSphere Process Server. WebSphere variables
are predefined in the WebSphere Process Server system for use by JDBC
providers created from the default JDBC provider templates. However, these
variables are defined at the node scope since they can be customized for
each node. Because of this scoping discrepancy, you will need to do one of
the following: define WebSphere Variables needed by the created JDBC
providers at the cell scope, or move the JDBC provider to the node scope after
running the InstallAdministrativeObjects.py script. Use
the administrative console to examine the JDBC providers that are generated
to determine which WebSphere variables are need. From the administrative
console, select Environment > WebSphere Variables to
create any required variables. (For more information, see "Configuring WebSphere Variables"
at the WebSphere Application Server Network Deployment
information center .
For more information about the wsadmin command,
refer to the "Wsadmin tool" in the WebSphere Application Server Information Center.
Access Enterprise JavaBean (EJB) support
WebSphere
InterChange Server supports the triggering of collaborations by client code
via a J2EE EJB (Enterprise JavaBeans™) protocol. Support for this
method of triggering collaborations is referred to as "Access EJB" or "Access
for EJB" support. For backward compatibility, WebSphere Process Server provides
deprecated support for Access EJB. The Access EJB support assumes that the
SCA BPEL modules to be invoked were generated by the WebSphere InterChange Server migration
tools described in this documentation. The mapping from the collaboration
name and port name (that is, the input parameters for the Access EJB) to the
SCA module name, interfaces and business object types assume the conventions
used by the migration tools. The Access EJB support in WebSphere Process
Server is delivered in the AccessEJB.zip project interchange file. It can
be found in the
install_root/HeritageAPI directory.
The AccessEJB support consists of an EJB (Access EJB) which references an
SCA module project (DynamicRouting) that invokes the SCA BPEL module. This
SCA BPEL module is the migrated version of the collaboration that was invoked
in WebSphere InterChange
Server. The DynamicRouting module uses a selector component to select the
correct SCA target based on the collaboration name and port name passed to
the Access EJB. To enable Access EJB support in WebSphere Process Server, do the following:
- Import the WebSphere InterChange
Server repository containing the collaboration that is the target of the Access
EJB invocation into WebSphere Integration Developer.
- Import the AccessEJB.zip project interchange file into WebSphere Integration
Developer.
- Open the DynamicRouting project and update the selector table to include
the migrated module that is to be invoked via the Access EJB.
- Go to the migrated project containing the BPEL component to be invoked
via the Access EJB, and drag the export that references the BPEL module over
to the DynamicRouting project.
- Repeat steps 3 and 4 for each BPEL module that is to be accessible via
the Access EJB.
- Build the project and deploy it to the WebSphere Process Server server.
- Ensure that any required data handlers are provided in the runtime classpath
of the WebSphere Process
Server server.
- To enable your Access client to use WebSphere Process Server, ensure that
it points to the WebSphere Process Server server and uses the JNDI
name com/crossworlds/access/business/cwsession/CwSession when
looking up the Access EJB.
DynamicSend API
In WebSphere InterChange Server, the
DynamicSend API can be used to directly invoke one collaboration from another.
The collaboration to be invoked does not have to be predetermined, instead,
it can be determined dynamically at runtime. The support for the DynamicSend
API in WebSphere Process Server uses the DynamicRouting project described
in "
Access Enterprise JavaBean (EJB) support." Follow the instructions
in that section to enable the DynamicSend API to be able to invoke the specified
BPEL modules.
Security
Methods are available for securing a business
integration system with WebSphere Process Server in ways equivalent to
the security which could be achieved with WebSphere InterChange Server. Article(s)
on this topic which you might find helpful are available on the IBM
® developerWorks
® web
site. Look in the "Technical Library" at
http://www.ibm.com/developerworks.
Event sequencing
Methods are available for sequencing
events with WebSphere Process
Server in ways similar to the way you could with WebSphere InterChange Server. Articles
on this subject that you might find helpful are available from the IBM developerWorks web
site. Look in the "Technical Library" at
http://www.ibm.com/developerworks.
Failed events
Methods for handling failed events in WebSphere Process
Server are described in article(s) that you might find helpful on the IBM developerWorks web
site. Look in the "Technical Library" at
http://www.ibm.com/developerworks.
Last updated: Thu 02 Nov 2006 03:41:28
(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)