Designing / abstracting a broker for multiple types of tasks
My application deals with various tasks where a `Task` is an abstract base class.

Tasks are programmed into the system on an ongoing basis and the nature of tasks can vary.

Some examples of tasks:

 - Use interop to open word and insert some text.
 - Use MS DAO to create a new Access Database.
 - Use interop to open open a database.
 - Copy a file from Folder1 to Folder2.
 - Open up IE and navigate to SomeUrl.

Each task has a unique identifier and returns a bool result.

I want to develop some kind of a broker architecture that can be used to dispatch such tasks to classes that are not known at compile time.

The question here is: What kind of an architecture would best suit this scenario? Should I be looking at some specific design patterns?
Designing / abstracting a broker for multiple types of tasks
===

My application deals with various tasks where a `Task` is an abstract base class.

Tasks are programmed into the system on an ongoing basis and the nature of tasks can vary.

Some examples of tasks:

 - Use interop to open word and insert some text.
 - Use MS DAO to create a new Access Database.
 - Use interop to open open a database.
 - Copy a file from Folder1 to Folder2.
 - Open up IE and navigate to SomeUrl.

Each task has a unique identifier and returns a bool result.

I want to develop some kind of a broker architecture that can be used to dispatch such tasks to classes that are not known at compile time.

The question here is: What kind of an architecture would best suit this scenario? Should I be looking at some specific design patterns?