To design the connector architecture, consider evaluating the following areas of the application that the connector is to support:
The specific areas within an application that affect connector design are illustrated in Figure 13.. In this figure, the clouds show the high-level tasks required for connector development.
Figure
13. Areas of an application that affect connector
design
Understanding the application environment is the first step in assessing the feasibility of a connector development project. To obtain an understanding of the aspects of an application that affect connector development, consider these topics and questions:
Alternatively, in a client-server architecture, the database might reside on a server, and the application front-end program might be a client running on another machine, such as a personal computer. Other types of application execution architecture are online transaction processing and file server architecture.
During project assessment, you may want to identify and work with an application expert. This person can also provide assistance during business object development and connector development.
Early on in the project planning phase, you need to determine what roles the connector will perform for the application:
These roles determine the directionality that the connector supports:
For example, a connector might simply need to receive request business objects from an integration broker and pass them to an application. The connector for an application that serves only as the destination is a unidirectional connector - it implements request handling to pass data to the application, but it does not implement event notification. Knowing early in the development cycle that your connector will operate unidirectionally can save a significant amount of development time.
To be bidirectional, your connector needs to support both event notification and request processing.
For information on how to provide event notification support in your connector, see Event notification.
An important aspect of the connector development project plan is to determine how the connector will get data into and out of the application. Ideally, an application provides an application programming interface (API) that includes all of the following features:
Typically, however, an application interface falls short of this ideal.
In your project plan, you need to establish whether a formal application API exists and evaluate its robustness, or, if an API does not exist, determine whether there is a suitable workaround. Keep in mind that an application CRUD interface can be anything from batch file imports and extracts to a COM/DCOM server, so be sure to explore all possible avenues. Refer to the application business object scope specified in Table 13 when exploring the application object CRUD interface.
Consider the following tasks:
These questions are discussed in more detail in the following sections.
If you have access to previous efforts to integrate other applications with your application, you might be able to find ways of getting data into and out of the application. Even if you decide to implement another approach to application integration, the previous integration effort may provide useful design information.
When examining previous integration efforts, consider these questions:
In your answers, include information on all previous integration efforts that interact with the application in different ways.
Your application might be one of several applications creating or updating data in a single database. In this case, your connector might have to consider an application data entity based on work that other applications are also doing. If you determine that your connector will be sharing application data with other applications, consider these questions:
Provide answers to these questions for all applications that share the application data.
If the application provides an API or other mechanism that the connector can use to communicate with the application, examine the API and review any available documentation. Keep in mind the following questions about the API:
The recommended approach to connector development is to use whatever API the application provides. The use of an API helps ensure that connector interactions with the application abide by application business logic. In particular, a high-level API is usually designed to include support for the business logic in the application, whereas a low-level API might bypass application business logic.
As an example, a high-level API call to create a new record in a database table might evaluate the input data against a range of values, or it might update several associated tables as well as the specified table. Using SQL statements to write directly to the database may bypass the data evaluation and related table updates performed by an API.
If no API is provided, the application might allow its clients to access its database directly using SQL statements. If you use SQL statements to update application data, work closely with someone who knows the application well so that you can be sure that your connector will not bypass application business logic.
This aspect of the application has a major impact on connector design because it affects the amount of coding that the connector requires. The easiest application for connector development is one that interacts with its database through a high-level API. If the application provides a low-level API or has no API, the connector will probably require more coding.
A final aspect of the application business object interface that you need to investigate is whether the application uses any batch clean-up or merge programs to purge redundant or invalid data. For example, an application may run a batch program once a day to standardize site names that operators may have typed in incorrectly or incompletely. This program might, for example, change all sites named IBM WebSphere to IBM WebSphere Software.
When this type of batch program runs, all changes to the database may also need to flow through an InterChange Server customer synchronization system. A program like this may result in hidden requirements for your connector. For example, even if it appears initially that your connector does not need to provide Delete functionality, you may need to provide Delete functionality to support a batch clean-up program that deletes all sites named IBM WebSphere.
You may decide that you want to handle batch clean-up tasks periodically, such as once a month, rather than synchronously. In any case, an important planning task is to gather information about any programs that result in unanticipated requirements for your connector.