This section describes the development model you follow in order to develop a business integration system.
In most cases it makes sense for a single individual to develop an entire interface. You will follow the stages of implementation as described on page "Stages of an implementation" to develop the individual integration components that will work together to satisfy the requirements of your interface.
When you develop integration components you use the WebSphere InterChange Server toolset.
You first prepare your development environment. This involves installing WebSphere InterChange Server on your local system. For more information, see Preparing environments.
Next you define an integration component library to store your component definitions and a user project to represent your interface. You then create and store the integration components for your interface in the library and add shortcuts for them to the user project as you do so. For more information, see Working with integration component libraries and Working with user projects.
While you are developing the integration components they only exist in your local file system. When the interface is complete you deploy the user project to your local InterChange Server instance, where the component definitions are stored in the repository. Although prior to release 4.2.0 of InterChange Server you worked with component definitions directly in the repository, you now work exclusively with component definitions in the local file system and then deploy them to the server. This development model is called "static metadata administration". It separates development activities from runtime activities and reflects the J2EE development model. For more information on deploying user projects, see Exporting components to a package using System Manager.
After you have deployed an interface to your local InterChange Server instance, you should test the interface to verify that it meets the customer requirements. For more information on testing, see Using Test Connector and Using Integrated Test Environment.
After you have validated the integrity of your interface in your local InterChange Server instance, you must coordinate with the other developers on the project to combine it with their interfaces as a business integration system. For more information, see The life cycle of a business integration system.
The life cycle of an interface describes how you develop an interface on your local system. This section describes how you work with other developers to deliver a business integration system.
When you finish developing and testing the interface on your local system, you must coordinate with the other developers who are also working on interfaces in the project to create a business integration system. Each developer must deploy their interface to a common environment--frequently called a development integration environment.
To do this, you create an integration component library in the development integration environment, and then each developer exports a package that contains the components in their interface and imports the package into the new library.
After all redundancies have been resolved and modifications have been made, you deploy the components that represent the collection of interfaces to the local server instance in the development integration environment.
When the interfaces for a business integration system (or a particular phase of the implementation of the system) are combined, they should be tested again. This ensures that each interface still satisfies its business requirements as defined by the customer when executing along with other interfaces. If there were any problems or oversights in the migration from local development environments to the integrated development environment--such as failing to properly update a shared component--then they will be identified through rigorous testing at this stage.
Depending on the site, the integration testing might either be done in the development integration server or in a dedicated testing environment. If you maintain a separate test environment then you can combine all the interfaces in the development integration environment and validate its integrity before altering the test environment. This way, tests can be performed in the test environment for any existing interfaces there while new interfaces are prepared in the development integration environment. This approach does, however, require that the customer purchase the equipment necessary to support another environment, and that the environment be configured.
After you have performed integration testing to verify that the collection of interfaces still satisfy their functional requirements, you might perform stress-testing to ensure that the business integration system can meet the customer's performance requirements.
If you configure the performance-testing environment to be identical to the production environment then the simulated throughput will be a more accurate prediction of what the production performance will be like. Production environments can be expensive, however, and the customer might not make the investment to create a performance-testing environment that mirrors production closely.
To migrate the business integration system into the performance-testing environment you follow the same procedure that you did when migrating into the development integration environment:
If you find that performance is not satisfactory then some components might need modification or re-configuration. For more information on some configurations and techniques that affect performance, see Performance tuning.
After you have validated that the business integration system satisfies the functional and performance requirements, you migrate the collection of interfaces into a production environment.
To migrate the business integration system into the production environment you follow the same procedure as when migrating from previous environments:
Figure 1 illustrates the flow of integration components from integration component library to user project to server repository to exported package across the typical environments.
The development team must perform a knowledge transfer to equip the site administrator with the skills and information they need to manage the collection of interfaces. You are then either done with the integration implementation, or begin development of a new interface as part of the next phase.