1) Include a SQL Script Task in the control-flow, probably before your data-flow task runs.

2) Yes, but it is a Kludge and a potential security issue. SSIS, is not really meant for the development of end-user tools or functionality, it's really targeted at implementing operational features and background tasks.

However, if you feel the you must have this here are your options:

A) Have your client applications/SW run the SSIS package itself by using DTExec.exe at the command line. This is easily the most direct, least kludgey solution and it generally bypasses the security issues (because it just uses the Users or the Apps authorization, hopefully).

B) Write a stored procedure that uses sp_cmdshell to execute the package DTExec, at the command-line, from SQL Server. This works, but is obtuse (because you have to go out to DOS and then DTExec has to log back into SQL Server), and also could be a security problem.

C) Define a SQL Agent SSIS Job Step to run your package. This works, is probably secure, but is hard to implement (it's a PITA trying to run a Job from a session connection), and has reportability issues (as in, it runs asynchronously in another session, so your user will not know when its done or whether is was sucessful or not).