Michael Entin's notebook : SSIS

Does buffer.NextRow() skips the first row in a buffer?

michen — Sun, 19 Oct 2008 10:33:40 GMT

I got a follow up question to my old post regarding enumerating rows in SSIS buffer, that suggested using following code to process rows in custom SSIS transform:

while (buffer.NextRow())
{
// do something with the row
}

Here is the question:

buffer.NextRow() moves the pointer forward, so following your code to the letter will make you skip the first row.

Does it? Actually, no. It behaves like many other enumeration interfaces, e.g. COM's IEnumVariant and .NET's IEnumerator, so I'll quote documentation from IEnumerator::MoveNext:

After an enumerator is created or after the Reset method is called, an enumerator is positioned before the first element of the collection, and the first call to the MoveNext method moves the enumerator over the first element of the collection.

Can you guess why it was designed this way? Let's think what would happen, if the enumerator was positioned on the first element (row in SSIS case) initially. How would we know if the first element exists at all? The enumerator would have to provide another property, like EndOfCollection - making everything more complicated. Note that as explained in my linked post, buffer.EndOfRowset() is not such an indicator. It does not tell you that enumerator finished enumerating rows in current buffer, it tells you that current buffer is the very last buffer you will receive.

With enumerator initially positioned before first row, you call NextRow() which will immediately return false if the collection is empty, and position iterator to first row if it exists. So the code is correct.

A note regarding my original post: the SSIS team found that this change caused too many problems for the users, so the final release of SSIS 2008 reverted back to the SSIS 2005 behavior. Interestingly, it was not a simple undo of code change, as the data flow engine has been substantially rewritten, but a new code to simulate the old behavior. Thus the "wrong" code will keep working in 2008. I still recommend changing it according to my previous blog - I think my loop just looks cleaner :).

Lookup multiple rows?

michen — Sat, 07 Jun 2008 11:37:00 GMT

Can SSIS Lookup do what this user wants it to do?

I have a problem with a lookup output, I get this warning: The Lookup transformation encountered duplicate reference key values when caching reference data. I know what it is, but I don't like to avoid this warning, I'd like to get all the rows (two in this case) that the lookup output provides me.

Unfortunately, no - the reason is that Lookup transform is synchronous, i.e. it does not add new rows or remove rows*, it just modifies the values - i.e. it can't produce two output rows for one input row.

It would of course be possible to make an asynchronous Lookup, or provide an option, but the current Lookup is complex enough, that I think more options would kill it :)

If you need this functionality, you can use Merge Join transform.

Notes
*What happens with the rows that are redirected to "not found" output in SSIS 2008? They are not deleted from the buffer (synchronous transform can't do it), they are just marked as belonging to the other path, and the components on the main path do not see them.

Configuring .NET for running SSIS packages from custom applications

michen — Sat, 15 Mar 2008 01:45:00 GMT

If you execute SSIS packages from custom applications, you own the application and thus you are responsible for configuring .NET runtime properly to get the maximum performance.

.NET configuration is usually performed using .exe.config files, so it is a just matter of providing good config file. How do you know what is good? The simplest way is to look at the config file that SSIS provides, and copy the appropriate settings. Now let's take a look at DTExec.exe.config provided with SQL Server 2008 and discuss the choices made by SSIS team.

requiredRuntime - this line simply tells which version of .NET you want to use. 2.0 or above should be good.

gcServer - DTEXEC uses the "server" version of garbage collector. Server GC performs better for typical SSIS load, especially on multiprocess machines. This is important if your SSIS package uses managed transforms (e.g. ADO.NET source, script transform, or custom transform written in .NET).

disableCommitThreadStack - by default .NET commits the thread stacks (i.e. reserves memory for stacks - usually from page file). But SSIS creates a lot of threads, while typically uses little stack space, so it performs better if stack memory is not immediately committed when the thread is created. With this option your application might perform a bit better and require smaller page file (note that anyway, the page file is not really used until needed). The drawback of this choice is that application might fail if Windows is totally out of memory, and application can't extend its stack. But in this situation something has already gone bad, and it is probably better to fail fast in this case anyway.

generatePublisherEvidence - this tells .NET runtime the DTEXEC does not use Publisher evidence, and thus .NET does not have to verify authenticode signatures. This increases the startup performance a little bit, but mainly prevents problems that may occur when authenticode checks certificate revocation list.

Now that you know these options made by SSIS team, you may test and decide whether they are appropriate for your application as well, and copy them to your application's config file if needed.

P.S. Also make sure you create SSIS package using MTA thread, see Matt's blog for details:
http://blogs.msdn.com/mattm/archive/2007/09/14/running-packages-from-custom-applications.aspx

SSIS event handler threading

michen — Fri, 01 Feb 2008 23:25:00 GMT

I've got an interesting question/statement about event handlers:

Tasks fire the same EH at the same time. My understanding is all EHs fire at the same time (Parallel).

If I understand the question correctly, the package has an event handler that can handle multiple events, and these events fire at about the same time. What happens?

Well, I did not work much with event handlers, so let's experiment and test how it works. This is really simple. I've create a package with two dummy script tasks A and B (not connected with any precedence constraints) that fail (by returning failure) and OnError event handler on the Package. The event handler contains a simple script task that prints the name of the event source:

MsgBox(Dts.Variables("SourceName").Value, MsgBoxStyle.Information, "Event Handler")

What will be the result of executing this? Will we get two message boxes at the same time, or sequentially two message boxes?

The answer is - two message boxes popup sequentially one after another, but never at the same time. Ssometimes A is the first, sometimes B. The event handler (like any other task) is not reentrable and only a single instance of an event handler can be running at a time, thus the second event has to wait for the event handler to finish processing the first event before processing the next one.

SQL 2008 & VS 2008

michen — Wed, 05 Dec 2007 09:42:00 GMT

Currently SQL Business Intelligence Development Studio (BIDS) and all the project types (AS, IS and RS) live in Visual Studio 2005. So don't try to open a solution that contains IS project in VS 2008 yet. What about final SQL 2008 - now that Visual Studio 2008 is released - what are the plans for BIDS and support of BI projects VS 2008?...(read more)

Deploying packages

michen — Wed, 07 Nov 2007 12:48:00 GMT

How can one deploy packages programmatically? Here is the original question -

Is it possible to deploy a package programmatically? We have an application which has a work flow for approval of object. If the object (ssis package) is approved by the concerned authority it has to be deployed to sql server. How can this code be integrated into the application?

First, what does it mean to deploy a package? The package is simply a document (DTSX file). SSIS utilities (DTEXEC, DTUTIL and other) natively support three locations for such files: the actual file in the OS file system, a row in SQL table, or virtualized file in SSIS storage (which wraps the previous two). If you use custom application to run your packages, you can store them anywhere you want (e.g. application resources) - and use LoadFromXML to load it.

Since package is just a file, in most cases simply copying a file to destination directory location, or to SQL table is all it takes to deploy a package. One can use SSIS API (like SaveToSqlServer) to do this, run DTUTIL, or copy file using Win32 or .NET APIs.

In some cases it is necessary to make some adjustments to the package, e.g. if you have multiple packages calling each other - modify the parent package to correctly reference new location of child package(s). This can be done using SSIS API as well, but it is easier and usually better for maintainability to do this using SSIS configurations - edit the configuration values instead of the package itself.

Don't run SSIS package using SQL/CLR

michen — Sat, 25 Aug 2007 03:57:00 GMT

A recent commenter suggested running SSIS using SQL/CLR:

Just an idea on how to do this that may be a bit easier than any of the methods covered. IF you were to write a CLR procedure which accepts a string as its parameter. The string passed in would be the xml definition of a package (either loaded from a source (file, server, etc)or from an application which is able to create the package definition). Then using the CLR procecure that I mentioned above (which has references to the DTS runtime), you could use the Microsoft.SqlServer.Dts.Runtime.Package LoadFromXML() method to flesh out an empty package and then the Execute() method to actually run it.

This may look like a good idea, but don't do this. The reason is that SQL Server has very strict requirements on the type of code running inside (this is how it achieves the great reliability, and why by default it only allows "safe" .NET code and only selected system assemblies). It takes a lot of effort to "harden" code to satisfy these requirements. See e.g. this excellent article by Joe Duffy describing one of the issues: http://www.bluebytesoftware.com/blog/2007/08/23/ThreadInterruptsAreAlmostAsEvilAsThreadAborts.aspx. Only a subset of .NET framework has been "hardened" to qualify.

The SSIS uses "unsafe" .NET code, and we've not done enough testing of SSIS and dependencies inside SQL Server to recommend running it this way, so it is unsupported.

You'd be safer if you write a web service application that does it, and the extra benefit - SQL Books Online has sample code!

Do I have to be admin?

michen — Tue, 26 Jun 2007 07:28:00 GMT

Often, I see people reporting "zzz fails if I'm not admin". Do I have to be machine admin to use SSIS?

Well, absolutely no. Most SSIS tasks can be performed without being admin at all. Actually, I develop on Vista machine and I very rarely need to elevate to admin status.

Then why would you get errors if you are not admins? Most often you don't have access to whatever data source or package location you use. E.g. if you load a package from SQL Server, you need to have access to this SQL Server. Often people automatically get access because they are local admins, but for other users, access should be configured explicitly.

Same is true for database and file connections at package execution time: if package tries to access something, the user who runs the package has to have an access to this resource (assuming package is using integrated authentication). So if your package fails when run as non-admin, the first step to do is turn on SSIS or console logging and see what error you get - this will point to the resource for which you need permissions.

Do I ever have to be machine administrator when working with SSIS? Yes, there are several situations when admin is needed.

First, when you look at the running packages in SSMS, you'll only see your own packages if you are non-admin. If you need to see all packages, you need to be machine admin (unfortunately, it is controlled by admin membership - would be better to have specialized role for this).
Second, if you are developing custom task or transform in managed code, you'll need to install it to GAC - this requires machine admin as well.
When developing in native code, this is usually simpler - you register the task once as admin; later you can compile it as regular user.

SSIS Backpressure Mechanism

michen — Wed, 13 Jun 2007 05:28:00 GMT

One of the mechanisms that SSIS data flow engine utilizes to achieve high performance is “back pressure”.

Let’s consider a simple package with a source and destination. What happens if the source is fast and destination is slow? Say source is huge local raw file and destination is a remote relational database. If we read the source data with full speed, we would need a lot of memory to store all the data we’ve read, but could not write yet. In many cases we’d simply run out of memory or had to swap data to hard drive.

To avoid this, SSIS limits the speed of sources by controlling the number of active buffers inside each execution tree. This way you can process fast sources without running out of memory.

If a source or an async component is too fast (compared to the the transformations or destination down the path), the source is suspended when its execution tree gets too many buffers (currently this is fixed at 5 buffers). If the source is slow (i.e. transforms and destinations can process data faster than sources generate it), the back-pressure mechanism does not get involved and sources can run with full speed.

Unfortunately, in SQL 2005 we did not have any diagnostics that would tell user what is the slow part of the flow - the source or the transforms/destination. In Katmai (SQL 2008) if the back-pressure kicks in during package execution, at the end of package execution we report the total time that the source had to wait because of this mechanism.

What would you do with this information? If you run the package and see that the time a particular source was suspended is zero or relatively low (compared to the total execution time), you know the source is the slowest part of the data flow, and you need to focus on optimizing the source. E.g. you may remove unused columns from the query, simplify SQL statements, create indexes, etc.

But if a source reported that it has been suspected most of the time (considerable part of the total package execution time), you know the source is fast enough and you need to concentrate on performance of transforms and destinations.

Another implication of back pressure is that the source database connection can be opened longer than it is needed to execute the query otherwise. If you see that a source has been suspended for several minites, and you don't want to hold the appropriate database connection for such a long time, consider staging source data in raw files as suggested by Jamie Thomson at
http://blogs.conchango.com/jamiethomson/archive/2006/12/12/SSIS_3A00_-Dropping-data-into-a-raw-file.aspx

Katmai SSIS data flow task improvements

michen — Mon, 11 Jun 2007 10:00:00 GMT

With first Katmai (SQL Server 2008) CTP out, I think it is time to blog about some performance and scalability improvements in this release.

I'll assume readers are familiar with SSIS data flow performance concepts, if not make sure you've read these two articles:
http://www.microsoft.com/technet/prodtechnol/sql/2005/ssisperf.mspx
http://www.simple-talk.com/sql/sql-server-2005/sql-server-2005-ssis-tuning-the-dataflow-task/

The most important concepts for today are:
Asynchronous components - components that create new rows and thus new data flow buffers (compare to synchronous components that modify data in the incoming buffers, but can't create or remove rows). Both blocking and partially blocking components (in terms of ssisperf whitepaper linked above) are asynchronous.
Execution trees - the tree describing the path a data buffer takes through the components, from start to end. The tree starts with a source or async component and usually ends with a destination or sometimes with a transform. It is a tree (not a simple list) because some transforms, e.g. Multicast "split" the data flow into multiple logical paths, but avoid buffer duplication - all sub-trees use the same "physical" buffer.

In SQL 2005 each execution tree was assigned a single OS thread ("worker thread"), and under some conditions (complex packages with small data flow EngineThreads property value) several execution trees could share a thread. One benefit of this approach is that all thread scheduling was done in advance during pre-execution phase, so the data flow did not have to spend any time to assign threads at runtime.

But there were several drawbacks: since the data flow did not know relative amount of work per execution tree, the scheduling could be suboptimal. Also, if you had simple package with just one or two execution trees, you would only use one or two processors, and the package might not benefit from high-end multiprocessor machine. You may have a lot of synchronous components, but if they share the same execution tree, they used to share the thread too. Even if you logically split the data flow using Multicast (synchronous transform), all output paths of Multicast belong to the same execution tree, and thus are executed serially by Yukon data flow task.

To achieve high level of parallelism on a multiprocessor machine, you had to split an execution tree, either by splitting the tree into independent paths, or by inserting async transforms to create a new tree. UnionAll could be used for later, as described in the ssisperf whitepaper. If you insert UnionAll with one input, it does not change the outputs, but splits the execution tree into two new trees - each can be executed on its own processor. The drawback is that the UnionAll is async transform, and thus has to copy data, so it might have a noticeable performance overhead. You should only use this trick if you checked that your package benefits from this extra parallelism. Usually packages already have multiple data flows, or multiple execution trees inside single data flow, so they don't need to do this. But if you have a very high-end machine and a pipeline that takes too long and does not use all the processors, you should try it (make a backup copy of original package and compare the performance before commiting to this change).

Now the good news: you don't need to worry about any of this or use the UnionAll trick anymore! In Katmai, the data flow was redesigned to do dynamic scheduling and can now execute multiple components in parallel, even if they belong to the same execution tree. The overhead of dynamic scheduling is very small. We sometimes saw a very small (~1%) performance loss on single processor machines, but on multiprocessor machines you'll usually see performance improvement, especially if you had to use UnionAll trick to introduce more parallelism and remove it when you move to Katmai.

As most server machines now have two or more processors or at least Hyper Threading, we think most users will see the performance improvements from this change. And you get the best performance automatically, no need to think if you need to introduce more parallelism by adding UnionAll transform, one less bullet to worry about.

SqlPerf blog on SSIS performance

michen — Tue, 24 Apr 2007 21:40:00 GMT

Runying Mao and Len Wyatt did a great study of SSIS performance, and posted some results:

Getting Optimal Performance with Integration Services Lookups

http://blogs.msdn.com/sqlperf/archive/2007/04/24/getting-optimal-performance-with-integration-services-lookups.aspx

OLEDB Source with Views

http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently.aspx

BLOB and buffer temporary storage

http://blogs.msdn.com/sqlperf/archive/2007/05/01/set-blobtempstoragepath-and-buffertempstoragepath-to-fast-drives.aspx

SSIS Performance Counters

http://blogs.msdn.com/sqlperf/archive/2007/05/01/something-about-ssis-performance-counters.aspx

Buffer size adjustments

http://blogs.msdn.com/sqlperf/archive/2007/05/11/adjust-buffer-size-in-ssis-data-flow-task.aspx

Parallel execution

http://blogs.msdn.com/sqlperf/archive/2007/05/11/implement-parallel-execution-in-ssis.aspx

COM references within an SSIS Script Component

michen — Sun, 22 Apr 2007 12:06:00 GMT

The SSIS Script Task and Script Component editors don't provide functionality (available in full VS) to add a reference to unmanaged COM components. Can this be done at all?

Well, yes, although lack of GUI option in VSA (which SSIS uses for editing and debugging scripts) makes it a bit complex. We'll need to create an interop assembly using command line tools, install the assembly into GAC and .NET Frameworks folder, and then VSA will be able reference it. You'll need .NET SDK or Visual Studio to do this.

Open .NET SDK command prompt. First, generate a key for creating strong names for your assemblies. You may have already created a key for custom task or transform - then skip this step and use existing key.

sn.exe -k MyKey.snk

Now find the COM component and generate interop assembly:

tlbimp.exe "C:\...\MyComObj.dll" /out:Interop.MyComObj.dll /keyfile:MyKey.snk

Install the assembly into GAC: drag it to c:\Windows\Assembly folder or run following command (this step should be repeated on every machine where you'll run this package):

gacutil.exe /i Interop.MyComObj.dll

and also copy it to c:\Windows\Microsoft.NET\Framework\v2.0.50727 folder (this step is only required on machine where you edit the scripts, except if you turn off the option to precompile scripts - then it is also needed at machines where you run packages).

Things to be aware of: the code executed by script task or script component always runs on multi-threaded COM apartment (MTA, same as when using [MTAThread]), so using COM components marked as Free/Both is fine, but using STA components will use marshalling and might be slow or broken (as in case of SqlXml).

This blog by Jamie Thomson contains some useful background information as well:
http://blogs.conchango.com/jamiethomson/archive/2005/11/02/2341.aspx

64-bit references within an SSIS Script Component

michen — Fri, 20 Apr 2007 01:33:00 GMT

I was forwarded a question about SSIS Script Component on 64-bit, I think the answer may benefit others as well:

Currently we are referencing a 32-bit third party component in a script component and running the SSIS package in 32 bit mode on a X64 bit server. Recently, the third party vendor has made available a 64-bit version of this component and we would like to reference this version in our script task in order to run the package in 64-bit mode.

What we are experiencing is that script component “Add Reference” dialog only browses to the 32 bit framework folder and not the framework64 folder.

Is it possible for the script component to reference a 64-bit assembly?

First a small explanation for those puzzled by the question. Most .NET assemblies are platform neutral, meaning the same assembly can be run on 32-bit and 64-bit platform. For neutral assemblies the problem does not occur at all. But some assemblies may be created for 32-bit or for 64-bit platform only, or a separate version of the assembly is built for each platform. E.g. if some external unmanaged code (usually a COM component) that the assembly uses is available on 32-bit platform only, you should mark your assembly as 32-bit only to prevent attempts to use it on 64-bit. If the interface of dependency is different between the platforms, you might build a separate version for each platform. E.g. Microsoft does this for System.Transactions assembly.

Now back to the question: can one use 64-bit version of external assembly in Script Component?

Well, you can't reference the 64-bit assembly in the Script editor (VSA), because it is 32-bit application. But let's look at how .NET loads depedent assemblies from GAC: it first tries to load current platform-specific version, if it is not found it tries MSIL (neutral) version. The "current" here means determined by bitness of the current process. It does not matter if the assembly was compiled with 64-bit or with 32-bit version.

So you should reference the 32-bit version of the assembly during design time. At runtime .NET will choose the appropriate version for the current process from those available in the GAC. 32 process will use 32-bit version of the assembly, and 64-bit process will use 64-bit version. Goal achieved.

This is similar to how SSIS uses OLEDB providers – you reference 32-bit one at design time, and we pick up matching 64-bit OLEDB provider at runtime if the package is executed in 64-bit process.

Note that this is only possible if you have both 32-bit and 64-bit versions of external assembly. Also since the script task keeps only one platform neutral assembly for its own code, the metadata for 32-bit and 64-bit assemblies should be the same. I.e. they should have the same assembly name and version, define the same class names, function prototypes, etc.

Using SSIS object model from C++

michen — Fri, 30 Mar 2007 03:18:00 GMT

All the samples in MSDN show how use SSIS API from C# or VB.NET code. Is it possible to do this from C++ code? The answer is yes, if you know COM it should be quite easy for you, and the COM API is very close to .NET API (I think .NET API is nicer due to rich type system and properties).

Note that you still need to install either SSIS (if you want to execute package) or Workstation Components (if you write client tool that does not execute packages) - so you have something that implements the API you will be using :). This of course installs .NET 2.0 - so even if you don't use it, it has to be installed.

Instead of referencing .NET assemblies you will use COM interfaces, declared in DTS.H (from C:\Program Files\Microsoft SQL Server\90\SDK\Include). Here is a sample how to count the packages in SSIS server from C++. All error checking is removed for clarity, if you use this code in production - add error checking. Alternatively, you can #import <dts.dll> if you like VC com support classes - they provide automatic HRESULT-to-exception translation.

#include "dts.h"

void EnumPackages()
{
CComPtr<IDTSApplication90> app;
CComPtr<IDTSPackageInfos90> pkgInfos;

app.CoCreateInstance(__uuidof(Application));
app->GetDtsServerPackageInfos(CComBSTR(L"File System"), CComBSTR(L"."), &pkgInfos);

LONG count;
pkgInfos->get_Count(&count);

printf("found %d packages", count);
}

int _tmain(int argc, _TCHAR* argv[])
{
CoInitializeEx(NULL, COINIT_MULTITHREADED);

EnumPackages();

CoUninitialize();
return 0;
}

Running SSIS package programmatically

michen — Fri, 23 Mar 2007 01:27:00 GMT

I got several questions asking what is the best way to run SSIS packages programmatically. One question is about running SSIS from a .NET 1.1 application (SSIS uses .NET 2.0). Another about running package remotely "Do I really have to write an ASP.net app just to run a package on the server?" There were also questions about running package from ASP.NET page (which second user tries to avoid, but surprisingly many people want).

Let's review what options are available, and discuss which is most appropriate for each case.

1. Run package programmatically using SSIS Object Model. This is discussed in details in Books Online here: http://msdn2.microsoft.com/en-us/library/ms136090.aspx

Benefits: everything runs in process, it is very easy to set variables or modify package before executing it. You can also get events about package progress or ask it to stop by setting CancelEvent.

Drawbacks: Obviously this is local execution - you need to install SSIS on same machine where your app runs. This method also can't be used from .NET 1.1 application, unless it is moved to .NET 2.0 (which should be very easy to do, and in my experience improves the performance as well).

ASP.NET specific: the impersonation context does not get passed to additional threads SSIS package creates, so the data source connections will not be impersonated. Also, ASP.NET can be configured to recycle the worker process in case it consumes too much memory to improve availability of ASP.NET application. Since SSIS is likely to consume a lot of memory if you have lots of data, it can trigger this recycling and lower reliability of your application.

2. Start DTEXEC.EXE process. DTEXEC is command line utility for executing SSIS packages. See its command line options here: http://msdn2.microsoft.com/en-us/library/ms162810.aspx

Benefits: running package out of process gains reliability. Can be used from any programming language (including .NET 1.1 :)). Easy to pass parameters by setting variables values.

Drawbacks: Also local only. Harder to get information about package progress (but SSIS logging can give you most functionality). Some overhead on starting new process (likely minimal compared to execution time for big packages).

ASP.NET specific: Win32 CreateProcess function ignores the thread impersonation. So if you want DTEXEC to run under account different from ASP.NET process account, you should either make user enter name/password and pass it to Process.Start, or use method described in the following KB to run child process under impersonated account http://support.microsoft.com/kb/889251.

3. Use SQL Agent. You can configure an Agent job to run your package (either do it manually in advance if the package is static, or programmatically using SMO or using SQL stored procedures just before running the package), and then start it programmatically using SMO or sp_start_job.

MSDN has sample of calling sp_start_job from managed code: http://msdn2.microsoft.com/en-us/library/ms403355.aspx. Also make sure you implement logging as described in this KB http://support.microsoft.com/kb/918760 so if anything goes wrong you could troubleshoot it. This article also describes what can go wrong with the package when scheduled in Agent.

Benefits: You get remote package execution. You get execution serialization (only one instance of a job runs at a time). You can run the package under any account (use Agent proxy).

Drawbacks: Agent requires installation of SQL Server engine. You can't pass parameters directly - it requires modification to the job, or some side-channel, e.g. config file or SQL table.

4. Use some other utility to start DTEXEC for you.

Of course, you can use any other generic task scheduler instead of SQL Agent, if you don't want to use Agent for some reason. If you have some scheduler or remote execution infrastructure already in place - use it. All you need is a tool that can start an executable (DTEXEC) and pass command line arguments.

5. Create a custom application that will run the package (either using OM as described in method #1, or using DTEXEC as in method #2). Expose it as a web service or DCOM class, call this service from your program.

MSDN has sample code for both the web service and its client: http://msdn2.microsoft.com/en-us/library/ms403355.aspx (second part of this page).

Benefits: Easy to add custom logic. You get remote package execution. Easy to pass parameters.

Drawbacks: Need to write code.

6. Invent your own - I probably missed several ways. Please post comments with any ideas.

Now you should be able to answer the questions in the beginning of this blog:

.NET 1.1 app - #2 is probably the easiest way to do it.
Running package remotely: Agent (#3) is likely the simplest way.
ASP.NET app - Again, #3 is usually the best and most reliable, as it allows you to configure the package to run as a user different from account of ASP.NET process, and you can install SQL and run SSIS packages on a separate box to isolate it from web server even more.