Event Collection Architecture
Event collection is the process of gathering event data from one or more sources such as XML files, applications, or databases, and submitting this information to a notification application. This is the job of event providers.
Each application uses one or more event providers for collecting events. Each event provider submits data to the application using one of the three event APIs: an event object API, an XML API, or a SQL Server API. The following illustration shows a high-level view of how these APIs function.
.gif "Events collection architecture")
- The event object API uses the Event and EventCollector objects to submit individual events. Using the names of the fields in an event table, an application submits an Event object to the event collector, which then writes the data to the event table.
- The XML API provides a way to bulk load XML data. The XML event provider collects an XML document or stream from an event source and submits the data to the XML EventLoader, which then writes the events to the event table.
- The SQL Server API uses stored procedures to load event data from database objects. Two typical ways of using the SQL Server event provider are to invoke the provider using a stored procedure, and to run a query according to a schedule. The event provider receives a result set and writes it to the event table using the API stored procedures.
Event Class Views
When you create a Notification Services instance, Notification Services adds a view that has the same name as the event class. This view is the event source for your notification generation queries.
SQL Server 2005 Notification Services also supports inserting events into this view. Inserting events into this view causes Notification Services to create and close an event batch for each insert statement.
Standard and Custom Event Providers
Notification Services application developers can write their own custom event providers using any of the APIs listed above, or they can use one of the standard event providers supplied with Notification Services. The standard event providers can pick up XML data from a watched folder, can query SQL Server databases, and can query Analysis Services cubes. For more information, see Standard Event Providers.
Custom event providers provide functionality that is not available from one of the standard event providers. For example, you might want to collect data from a comma-delimited file from a stock ticker. Using the Notification Services API, the developer can create an event provider with this functionality. For more information about custom event providers, see Developing a Custom Event Provider.
Hosted and Non-Hosted Event Providers
Event providers are either hosted or non-hosted.
Hosted event providers run within Notification Services. Hosted event providers can either run continuously or according to a schedule defined in the application definition. These event providers are run by a Notification Services component called the event provider host. The event provider host runs using the same schedule as the generator component, which is specified in the application definition.
Non-hosted event providers run as external applications and submit events on their own schedule. For example, an event provider hosted by Internet Information Services (IIS) that exposes a Web method for submitting events is a non-hosted event provider. An event provider that is hosted inside a process you write is also a non-hosted event provider.
Batching of Events
Event providers write events in batches. Writing events in batches allows the generator to join the current set of subscriptions with all of the events in an event batch at one time. This batch-oriented processing improves application performance.
See Also
Concepts
Subscription Management Architecture
Subscription Processing Architecture
Notification Formatting and Delivery Architecture
Other Resources
Notification Services Views
Defining Event Classes
Defining Event Providers