Summary set of planning questions
The following table lists the set of planning questions
provided in this chapter. You can use this table as a worksheet
for gathering information about your application. As you gather
information, get copies of any documentation that can help in the
planning, design, or development phases of the project.
Figure 18. Summary set of planning question
- Understanding the Application
- What is the application operating system?
- What programming languages were used to create the application?
- What is the execution architecture of the application?
- Is there a central database for application data? What type
of database is it?
- Is the application or its database distributed across multiple servers?
- Identifying the Directionality of the Connector
- Does the connector need to send data, receive data, or both?
- Identifying the Application-Specific Business Objects
- Do application entities have contained entities?
- Are there application business entities that are the same type
but have different physical representations in the application?
- Are there application entities that reside in more than one
location in the database but correspond to the same logical entity?
- Are there batch processes associated with the creation of application entities?
- Investigating the Application Data Interaction Interface
- Have there been any other efforts to integrate with this application?
- What was the purpose of the integration?
- Does the integration use interfaces that modify or retrieve
information?
- If the integration is able to process an event generated in
the application, what is the mechanism used to trigger event processing?
- Will your connector replace the pre-existing integration?
- Is application data shared by other applications?
- Do other applications create, retrieve, update, or delete this
application's data?
- What is the mechanism used by other applications to gain access
to the data?
- Is there object-specific business logic used by other applications?
- Is there a mechanism that the connector can use to communicate
with the application?
- Does the API allow access for create, retrieve, update, and
delete operations?
- Does the API provide access to all data entity attributes?
- Does the API allow access to the application for event detection?
- Are there inconsistencies in the API implementation?
- Describe the transaction behavior of the API.
- Is the API suited for meta-data design?
- Does the API enforce application business rules?
- Are there batch clean-up or merge programs used to purge redundant
or invalid data?
- Investigating the Event Management and Notification Mechanism
- Describe the event management mechanism.
- Does it provide the necessary granularity to establish the distinct
object and verb?
- Does event notification occur at a level that can support application
business logic?
- Investigating Communication Across Operating Systems
- Does the API handle the communication mechanism between the
application operating system and the connector operating system?
- If not, is there a mechanism available to handle communication
across operating systems?
Evaluating the findings
As you assemble the answers to the questions presented
in this chapter, you acquire essential information about application
data entities, business object processing, and event management.
These findings become the basis for a high-level architecture for
the connector.
When you have determined what entities your connector will support
and have examined the application functionality for database interaction
and event notification, you should have a clear understanding of
the scope of the connector development project. At this point, you
can continue with the next phases of connector development--defining
application-specific business objects and coding the connector.
Figure 19 shows a partial write-up
of information about a sample connector. Figure 20 illustrates a high-level architecture diagram for an
ODBC-based connector.
Figure 19. Sample results write-up
- Understanding the Application
- Application is running on UNIX.
- Programming language used is Visual C++ with the Microsoft MFC
libraries.
- Application is client-server.
- Application has a central database. Type is RDMS.
- Application is not distributed.
- Identifying the Directionality of the Connector
- Connector will be bidirectional.
- Identifying the Application-Specific Business Objects
- Business objects have contained objects. Contained business
objects are:
- Customer "Address "Site Use and Site Profile
- Item "Status
- Contact "n Phones and n Roles
- Application business entities do not have different physical
representations in the application.
- Application entities do not reside in more than one location
in the database.
- No batch processes are associated with the creation of these
objects.
- Examining the Application Data Interaction Interface
- No previous efforts to integrate with this application.
- Application data is not shared by other applications.
- The application provides the OpenProduct API.
- OpenProduct allows for Creates and Updates but not Retrieves
and Deletes.
- The API provide access to all data entity attributes.
- The API allows access to the application for event detection.
We can create an event table and poll for events at a specified
interval.
- There are no inconsistencies in the API.
- The API has a batch interface.
- The application is table-based, and the API is suited for meta-data
design.
- ...
Figure 20. Sample ODBC-based connector architecture
