Considerations: General development

There are several considerations which apply broadly to most of the integration artifacts. In general, the artifacts which leverage the facilities provided by the tools and conform to the metadata models enforced by the tools will migrate most smoothly. Also, artifacts with significant extensions and external dependencies are likely to require more manual intervention when migrating.

The following list summarizes the considerations for general development of WebSphere InterChange Server based solutions to help ease future migration:

Document the system and component design
Use the development tools to edit integration artifacts
Leverage suggestions for defining rules with the tools and Java snippets

It is important for integration solutions to adhere to the programming model and architecture provided by WebSphere® InterChange Server. Each of the integration components within WebSphere InterChange Server plays a well-defined role within the architecture. Significant deviations from this model will make it more challenging to migrate content to the appropriate artifacts on IBM® Business Process Manager.

Another general practice which will improve the success of future migration projects is to document the system design. Be sure to capture the integration architecture and design, including functional design and quality of service requirements, the interdependencies of artifacts shared across projects, and also the design decisions that were made during the deployment. This will assist in system analysis during migration, and will minimize any rework efforts.

For creating, configuring, and modifying artifact definitions, use only the development tools provided. Avoid manual manipulation of artifact metadata (for example, editing XML files directly), which may break the artifact for migration.

Follow these guidelines when developing Java™ code within collaboration templates, maps, common code utilities, and other components:

Use only the published APIs.
Use the activity editor.
Use adapters to access EISs.
Avoid external dependencies in Java snippet code.
Adhere to J2EE develop practices for portability.
Do not spawn threads or use thread synchronization primitives. If you must, these will need to be converted to use Asynchronous Beans when you migrate.
Do not do any disk I/O using java.io.* Use JDBC to store any data.
Do not perform any functions that may be reserved for an EJB container such as socket I/O, classloading, loading native libraries, and so forth. If you must, these snippets would need manual conversion to use EJB container functions when you migrate.

Use only the APIs published in the WebSphere InterChange Server product documentation for the artifacts. These are outlined in detail in the WebSphere InterChange Server development guides. Compatibility APIs will be provided in IBM Business Process Manager for published WebSphere InterChange Server APIs. Although WebSphere InterChange Server has many internal interfaces which you may use, this practice is discouraged because these interfaces are not guaranteed to be supported in the future.

When designing business logic and transformation rules in maps and collaboration templates, try to avoid field developed common code utility libraries, included as a Java archive (*.jar) file in the classpath of WebSphere InterChange Server, as these will need to be migrated manually.

Use the activity editor tool to the greatest extent possible. This will ensure that the logic is described through metadata which can more readily be converted to the new artifacts.

In any Java code snippets that may need to be developed, the code be as simple and atomic as possible. The level of sophistication in the Java code should be on the order of scripting, involving basic evaluations, operations, and computations, data formatting, type conversions, and so forth. If more extensive or sophisticated application logic is required, consider using EJBs running in WebSphere Application Server to encapsulate the logic, and use web service calls to invoke it from WebSphere InterChange Server. Use standard JDK libraries rather than third party or external libraries which would need to be migrated separately. Also, collect all related logic within a single code snippet, and avoid using logic where connection and transaction contexts span multiple code snippets. With database operations, for example, code related to obtaining a connection, beginning and ending a transaction, and releasing the connection should be in one code snippet.

In general, ensure that code which is designed to interface with an Enterprise Information System (EIS) is placed within adapters, and not within maps or collaboration templates. This is generally a recommended practice for architecture design. Also, this will help avoid prerequisites for third party libraries and related considerations within the code, such as connection management and possible Java Native Interface (JNI) implementations.

Make the code as safe as possible by using appropriate exception handling. Also make the code compatible to run within a J2EE application server environment, even though it is currently running within a J2SE environment. Adhere to J2EE development practices, such as avoiding static variables, spawning threads, and disk I/O. While these are generally good practices to adhere to, they can improve portability.