The Container Concept

Containers are new in Integration Services. Data Transformation Services (DTS) had something called a Step object that was similar to the Taskhost, but not as encompassing. In Integration Services, the container concept is much more developed and prevalent throughout the object model.

Organizing

Containers are not a new concept. If you think of the containers in your home, you can probably come up with several different types. There are food containers, drawers, book shelves, and cabinets. All of these share a common purpose, which is to organize your stuff. Containers in Integration Services serve the same purpose. They organize the objects in the package.

Reducing Complexity

Containers make it possible to divide your package into subgroups. The average human brain can only comprehend five to seven different concepts or objects simultaneously. When confronted with a package that has 10 or 20 tasks, most people cannot describe what the package does without first studying the package for some length of time. However, when packages are subdivided into smaller parts, using containers, it is much easier to comprehend them. This is especially true if the containers are accurately labeled with names that describe the container's overall function.

Figure 7.1 shows how a typical workflow might look without containers. As you can see, it's complex and hard to understand. There is very little indication, other than the task icons and task names, what each of the tasks do or how they relate to each other. The person viewing the package must make the conceptual leap between all the various tasks and containers shown in the designer and what their overall purpose is. Grouping and labeling tasks and containers reduces the necessity for such conceptual leaps by abstracting the details of the package and makes packages much easier to comprehend at a glance.

Figure 7.1. Package workflow can often become complex

Figure 7.2 shows how containers can help to reduce complexity by grouping tasks together based on their function or relationship to each other. The Foreach Loop actually makes it possible to eliminate and reuse tasks. Note that these two packages are not identical. For example, the Foreach Loop executes the tasks it contains serially, whereas the first package shown in Figure 7.1 executes them in parallel. If it was important to execute the FTP and other tasks in parallel, they could still be placed in a Sequence container for better organization.

Figure 7.2. Containers organize related workflow into one location

Figure 7.3 shows how the containers can be collapsed to take up less space in the designer. As you can see, it's much easier to understand the three-step package in Figure 7.3 than it is to understand the 32-step package in Figure 7.1. Combining related workflow into containers removes complexity and makes it possible to view the package as a set of high-level steps.

Figure 7.3. Collapsing containers makes packages simpler

Structuring Solutions

Another benefit of containers is the ability to structure your package in such a way that it better reflects the high-level processes of your solution. For example, it's often desirable to build more than one optional execution path for the workflow based on some external constraint, such as the day of the week or month. You might want to perform some basic workflow daily, but then on the first day of the month, you might also want to do additional work. Although it's possible to do this without containers using annotations or placement, it's easier to separate the workflow into logical groupings in a visual way with containers. Figure 7.4 shows how containers can be used to structure packages into conditional parts that represent an overall process view.

Figure 7.4. You can easily structure packages to visually represent a process