4 Managing Environments
This chapter provides information about managing the integration project environments.
This chapter includes the following topics:
Managing Environments
Integration projects exist in different environments during their lifecycle (development, test, production) and may even run in different environments in production (multiple site deployment). Oracle Data Integrator makes easier the definition and maintenance of these environments, as well as the lifecycle of the project across these environments using the Topology.
The Topology describes the physical and logical architecture of your Information System. It gives you a very flexible way of managing different servers, environments and agents. All the information of the Topology is stored in the master repository and is therefore centralized for an optimized administration. All the objects manipulated within Work Repositories refer to the Topology. That's why it is the most important starting point when defining and planning your architecture.
The Topology is composed of data servers, physical and logical schemas, and contexts.
Data servers describe connections to your actual physical application servers and databases. They can represent for example:
-
Apache Hive
-
An Oracle Instance
-
An IBM DB2 Database
-
A Microsoft SQL Server Instance
-
A File System
-
An XML File
-
and so forth.
At runtime, Oracle Data Integrator uses the connection information you have described to connect to the servers.
Physical schemas indicate the physical location of the datastores (tables, files, topics, queues) inside a data server. All the physical schemas that need to be accessed have to be registered under their corresponding data server, physical schemas are used to prefix object names and access them with their qualified names. When creating a physical schema, you need to specify a temporary, or work schema that will store temporary or permanent objects needed at runtime.
A logical schema is an alias that allows a unique name to be given to all the physical schemas containing the same datastore structures. The aim of the logical schema is to ensure the portability of procedures and models on different design-time and run-time environments.
A Context represents one of these environments. Contexts are used to group physical resources belonging to the same environment.
Typical projects will have separate environments for Development, Test and Production. Some projects will even have several duplicated Test or Production environments. For example, you may have several production contexts for subsidiaries running their own production systems (Production New York, Production Boston, and so forth). There is obviously a difference between the logical view of the information system and its physical implementation as described in Figure 4-1.
Figure 4-1 Logical and Physical View of the Infrastructure
Description of "Figure 4-1 Logical and Physical View of the Infrastructure"
The logical view describes logical schemas that represent the physical schemas of the existing applications independently of their physical implementation. These logical schemas are then linked to the physical resources through contexts.
Designers always refer to the logical view defined in the Topology. All development done therefore becomes independent of the physical location of the resources they address. At runtime, the logical information is mapped to the physical resources, given the appropriate contexts. The same scenario can be executed on different physical servers and applications simply by specifying different contexts. This brings a very flexible architecture where developers don't have to worry about the underlying physical implementation of the servers they rely on.