Hitachi consulting has a blog
here. They talk a little about the IS object model and refer to its complexity. Notably they talk about the inner vs. outer objects.
Anyone that starts coding against the IS object model will see this almost immediately. I'm going to try to give some real quick pointers here about it, explain some of the rationale behind the inner/outer object design. Later in this blog I'll try to drill down on it a bit more.
The inner/outer object discussion is really only related to the runtime. The pipeline doesn't support wrapping objects for transformations because of a number of reasons, most notably, to make transforms extremely light and fast so that the overall pipeline will be fast. Looks like it worked. :)
So, when discussing inner and outer objects, we're really talking about the runtime, which controls everything you see in the workflow window in the designer and a few other things like logging, connections and events, etc. It's easiest to think about outer objects from the perspective of the inner objects, the pluggable components. When you the user, create a custom task, or foreachenumerator, you put properties on it that the runtime cannot know about. In other words, the runtime may discover that the custom component has certain properties, but it cannot know what those properties are for, usually. On the other hand, there are features that you'd like your component to always take advantage of. Say, you'd like to have your task support the OnPreExecute breakpoint. But, that code is somewhat complicated and, besides, why should you have to write it if Microsoft has already written it for their components. Why doesn't Microsoft just provide a way for you to expose that breakpoint so you don't have to write all that code. Well this is the beginnning of the rationale for having outer objects. We call them hosts. Essentially, they are wrapper objects that perform a lot of default behaviour for stock and custom components.
Custom components or stock components (Ones Microsoft writes and provide in the box) are all instatiated inside a host. That is, all components that may be created by third parties, explicitly, Tasks, Log Providers, Connection Managers, and ForEachEnumerators are hosted. The rationale behind this is many fold, but it begins with the premise that Microsoft wished to make it very simple to write custom components, (The notion of a platform). With the host pattern, Microsoft is able to do things like provide a common implementation of property expressions, breakpoints, properties collections, transaction interaction, variable scoping, persistence and other features without one line of code in the custom component.
So, when working in the IS object model (Still IDTS... interfaces however), the outer or host objects for tasks and other components will always be the same. Generally, you should never need to access the inner objects since you can configure them through the properties collections on their hosts. But, in the case where you do need to modify the custom/stock component directly, you can use the "InnerObject" property on all hosted objects to retrieve a reference to it.
For tasks, the host carries the additional burden of being a special container. It inherits some of the same behaviours as sequences, loops and the package. It provides variables scope and transaction scope for example. This makes it possible to do things like the Execute Package task because the container hierarchy principle holds true even for the task.
Understanding the rationale and principles behind the design I hope will help to better understand how to work with the object model. Keeping the notion of inner and outer object in mind, it should be easier to see how to create programs programatically etc.
Thanks to the folks over at Hitachi for a great segue. :)
Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden