Overview of Notification Delivery in SQL-NS

An important part of designing a SQL-NS application is deciding how notifications will be sent to subscribers. You may choose to send notifications via email, instant messaging, or Short Message Service (SMS), for example. These are just a few possibilities; the SQL-NS framework enables you to support almost any delivery method you choose.

A single SQL-NS application may use multiple notification delivery methods. When building an application, you must decide which delivery methods make sense for the subscribers you're targeting.

After you decide on a set of delivery methods you want to support, you need to obtain delivery protocol components that implement those delivery methods. SQL-NS provides two built-in delivery protocols: the File protocol that we've been using in the prototype until now, and the SMTP protocol that we look at in this chapter. The File protocol is unlikely to be useful in a production application, although, as you've seen, it is useful in the prototype stage. The SMTP protocol, however, is commonly used in production applications. It implements the Simple Mail Transfer Protocol (SMTP) to send notifications via email. If email is one of the delivery methods you want to enable, you can use the built-in SMTP protocol.

If your application needs to support another delivery method, you have two choices: You can either implement a custom delivery protocol yourself (as explained later in this chapter), or you can obtain a custom delivery protocol from a vendor. Implementing a custom delivery protocol yourself is easy. As with other SQL-NS custom components, you develop a class that implements a SQL-NS interface. Because custom delivery protocols developed this way are reusable components, there is a growing community of independent software vendors building and licensing them for general use in SQL-NS applications. Today, various vendors have already made available delivery protocols that support delivery via SMS, fax, and voicemail. If they fit your needs, you can leverage these prebuilt custom delivery protocols instead of writing your own. As the SQL-NS development community grows, additional delivery protocols will certainly be implemented. You can find a list of Microsoft's partners that provide delivery protocol implementations and other delivery services at http://www.microsoft.com/sql/ns/partners/delivery.asp.

This section describes the basic concepts behind the delivery protocol infrastructure in SQL-NS. As a SQL-NS application developer, it's important to understand these concepts, whether or not you intend to build a custom delivery protocol.

Delivery Protocols in the SQL-NS Engine

In the SQL-NS engine, the distributor handles the formatting and delivery of notifications. The distributor hosts both content formatters and delivery protocols and forms a distribution pipeline for the notification data, as shown in Figure 10.1.

Figure 10.1. The notification distribution pipeline.

In this pipeline, the content formatter turns the raw notification data into a readable message, and the delivery protocol sends this message out to an external delivery system.

To send the message, the delivery protocol may need to wrap it with additional information required by the delivery system. For example, if the delivery protocol sends email, it adds a number of headers, specifying the recipient's email address, the subject line, the content type (text or HTML), and other information, before sending the message to a mail server. To draw a simple analogy, you can think of the content formatter output as a letter; the delivery protocol places this letter in an envelope, writes the destination address on it, and then sends it out. The nature of the envelope and the form of the address information vary per delivery protocol.

As described in Chapter 9, an application can have multiple distributors, but each one is an identical copy of the others. Each distributor hosts its own copy of the delivery protocol components, which it uses to deliver the notifications it handles. When we use the term "the distributor," we are referring to the set of distributors in an application collectively.

Configuring Delivery Endpoints: Delivery Channels

The most often confused concept in SQL-NS is the distinction between delivery protocols and delivery channels. This distinction was called out in the section, "Delivery Protocols and Delivery Channels," (p. 99) in Chapter 4, "Working with SQL-NS Instances," but it's worth revisiting here.

A delivery protocol is a component that is hosted by the SQL-NS engine and implements the communication scheme required to send notifications to a particular type of delivery system. This communication scheme usually consists of a network protocol that specifies a message format and sequence of exchanges. For example, the built-in SMTP delivery protocol implements the Simple Mail Transfer Protocol, which defines the format of email messages, as well as the means by which those messages should be sent to mail servers. To create a custom delivery protocol component, you write code that implements the message exchange defined by some network protocol.

A delivery channel in a SQL-NS instance represents a specific delivery endpoint. The actual communication with the endpoint is handled by a delivery protocol, but the delivery channel definition captures the information required by the delivery protocol to connect to the endpoint. In other words, the delivery protocol implements a communication scheme that can be used with any endpoint that understands it, but the delivery channel identifies a specific endpoint used by the applications in a SQL-NS instance.

When you create a SQL-NS instance, you define a delivery channel in the ICF for each delivery endpoint to which notifications will be sent. A delivery channel's definition specifies a logical name (used later to identify the delivery channel), the delivery protocol used to communicate with the endpoint, and a set of arguments. The arguments typically specify the connection information needed to establish communication with the endpoint that the delivery channel represents. For example, the arguments might specify a particular server address and port. At runtime, the delivery channel arguments are passed to the delivery protocol component.

Note

Although a delivery channel is really nothing more than a named configuration representing a delivery endpoint, the concept of a delivery channel is often extended to encompass the endpoint itself. For example, it's common in SQL-NS parlance to refer to "using a delivery channel" to send a notification. What's really being used isn't the delivery channel, but rather the endpoint that the channel represents. However, this usage is generally accepted.

Another variation on this usage is to say that a delivery channel "uses" a delivery protocol. Actually, the distributor uses the delivery protocol to communicate with the endpoint that the delivery channel represents, but this usage is an accepted shorthand.

To clarify the distinction between delivery protocols and delivery channels, it may help to go back to the letter and envelope analogy used in the previous section. In this analogy, the delivery protocol is a component that implements the format and conventions of postal delivery: Letters go in envelopes, envelopes specify destination and return addresses, addresses contain postal codes, and envelopes need stamps of appropriate value. The delivery channel, on the other hand, represents a specific post office at which the delivery protocol can drop off the envelopes to have them delivered to their final recipients.

Consider a more concrete example in the context of SQL-NS. To send notifications via email using the SMTP delivery protocol, you need an SMTP server that will receive the messages from your SQL-NS application and route them to their destinations. That server is considered a delivery endpoint, and you configure your SQL-NS instance to use it by creating a delivery channel definition in the ICF. In this example, the delivery channel arguments would specify the SMTP server name and possibly other configuration options, such as authentication information. At runtime, the SMTP delivery protocol uses this information to connect to the SMTP server to deliver notifications. The nature of the configuration information required in a delivery channel definition varies, depending on the delivery protocol it uses.

Figure 10.2 illustrates the relationship between delivery protocols, delivery channels, and delivery endpoints.

Figure 10.2. Delivery protocols and delivery channels.

Notice that different delivery channels can refer to the same delivery protocol. In the SMTP example, if you have more than one SMTP server that you use to deliver email, you create a separate delivery channel definition for each one. All these delivery channels refer to the same SMTP delivery protocol.

Note

Because of the confusion around delivery protocols and delivery channels, you will often hear people talk about "implementing a custom delivery channel." This is an incorrect use of the terminology. When people say this, they actually are talking about implementing a custom delivery protocol. You cannot implement a custom delivery channel, but you can define a delivery channel that uses a custom delivery protocol to communicate with a delivery endpoint.

Routing Notifications to Delivery Channels

When subscribers register with your SQL-NS instance, they create one or more subscriber device records to represent the devices on which they want to receive notifications. Each subscriber device record specifies a delivery channel name, which identifies the delivery channel used to send notifications to the device.

When creating a subscriber device record, the delivery channel name is usually assigned by the SMI based on choices that the user makes. For example, your SQL-NS instance may use one SMTP server to deliver email to subscribers in North America, and another to deliver email to subscribers in Europe. Each SMTP server would be represented by a delivery channel with a unique name. A subscriber registering with your SMI would specify his location, and the SMI code would choose the appropriate delivery channel name when creating the subscriber device record.

When match rules insert rows into the notifications view, the values given for the DeviceName column specify the name of the subscriber device to which each generated notification should be delivered. In the early versions of the music store application prototype, we passed a hard-coded value for the device name. In Chapter 9, we changed the match rules to pass the device name specified in a subscription field. The insert trigger on the notifications view writes the given device name to the notifications table, along with the other notification data.

When the distributor reads a notification from the notifications table, it uses the subscriber ID and device name to look up the corresponding subscriber device record. It then uses the delivery channel name in this record to identify the delivery channel that should be used for delivery. After formatting the notification data, the distributor passes it to a delivery protocol component configured to use the specified delivery channel. Thus, the subscriber device represents the link between notifications and delivery channels, as shown in Figure 10.3.

Figure 10.3. Subscriber devices relate notifications and delivery channels.

Note

Because subscriber device names are unique only within the context of a subscriber, it is really the combination of subscriber ID and device name that uniquely identifies a subscriber device in the system. The notifications table tracks both the subscriber ID and the device name for each notification.

Declaring Delivery Channels and Custom Delivery Protocols in the ICF

To use a delivery protocol, you must define one or more delivery channels that reference it. Delivery channels are declared in the <DeliveryChannels> element of the ICF. When declaring a delivery channel, you provide the name of the delivery protocol it uses in the <ProtocolName> element. The names of the built-in delivery protocols, File and SMTP, are well known, and you can use them directly. For example, Listing 10.1 shows the declaration of a delivery channel that uses the File delivery protocol (taken from the music store ICF).

Listing 10.1. Declaring a Delivery Channel That Uses the File Delivery Protocol in the ICF

 <NotificationServicesInstance>   ...   <DeliveryChannels>     <DeliveryChannel>       <DeliveryChannelName>FileChannel</DeliveryChannelName>       <ProtocolName>File</ProtocolName>       <Arguments>         <Argument>           <Name>FileName</Name>           <Value>%_InstanceBaseDirectoryPath_%\FileNotifications.txt</Value>         </Argument>       </Arguments>     </DeliveryChannel>   </DeliveryChannels>   ... </NotificationServicesInstance> 

Unlike the built-in delivery protocols, all custom delivery protocols must be explicitly declared before you can refer to them in delivery channel definitions. The declarations of custom delivery protocols are made in the <Protocols> element of the ICF. A custom delivery protocol declaration assigns a name to the protocol and provides the configuration information required to load the custom delivery protocol class at runtime. After declaring a custom delivery protocol, you can reference it by name in a delivery channel definition. Listing 10.2 shows the outline of a custom delivery protocol declaration and a delivery channel definition that references it. Listing 10.2 is just meant to give you an idea of the structure and placement of the ICF elements; we examine their syntax and subelements (some of which are not shown here) in detail later in this chapter.

Listing 10.2. Declaration of a Custom Delivery Protocol and a Delivery Channel That Uses It

 <NotificationServicesInstance>   ...   <Protocols>     <Protocol>       <ProtocolName>MQProtocol</ProtocolName>       ...     </Protocol>   </Protocols>   <DeliveryChannels>     ...     <DeliveryChannel>       <DeliveryChannelName>MQChannel</DeliveryChannelName>       <ProtocolName>MQProtocol</ProtocolName>       <Arguments>         ...       </Arguments>     </DeliveryChannel>   </DeliveryChannels>   ... </NotificationServicesInstance> 

Note

Don't confuse the declaration of a custom delivery protocol with the declaration of a delivery channel that uses it. The delivery protocol declaration establishes the protocol name and tells the distributor how to load it. After you've declared a custom delivery protocol, you can declare one or more delivery channels that use it.

Because delivery channels and custom delivery protocols are declared in the ICF, their declarations apply to all applications in the instance. The distributors in all the applications can load the custom delivery protocols and use them with the declared delivery channels.

Declaring Protocol Support in the ADF

When you declare a notification class in the ADF, you specify which protocols can be used to deliver notifications of that notification class. When we were using only the File delivery protocol, the NewSong notification class in the music store ADF contained a <Protocols> declaration, as shown in Listing 10.3.

Listing 10.3. Declaring Support for the File Delivery Protocol in the NewSong Notification Class

 <Application>   ...   <NotificationClasses>     <NotificationClass>       <NotificationClassName>NewSong</NotificationClassName>       ...      <Protocols>        <Protocol>          <ProtocolName>File</ProtocolName>        </Protocol>       </Protocols>     </NotificationClass>   </NotificationClasses>   ... </Application> 

The <Protocol> declaration for the File delivery protocol just specifies the protocol name. This is sufficient to allow the distributor to deliver NewSong notifications via any delivery channel that uses the File protocol. As we add support for additional protocols, we provide additional <Protocol> declarations in the notification class. The information in these declarations enables the distributor to use the specified delivery protocols to deliver notifications of the notification class.

Note

The notification class declaration is independent of the delivery channels configured for the instance. The notification class declaration just specifies the supported delivery protocols. Any delivery channel using one of the supported delivery protocols can be used to deliver notifications belonging to the notification class.

Each <Protocol> declaration specifies a protocol name, which can be the name of a builtin delivery protocol or the name of a custom delivery protocol declared in the ICF. A <Protocol> declaration can also provide protocol-specific data to be passed to the protocol component when the distributor invokes it, and a number of execution settings that control the protocol's runtime behavior. The section "Declaring Support for the SMTP Delivery Protocol in the Notification Class" (p. 369) describes these aspects of protocol declarations in detail.

Note

Although the XML element name, <Protocol>, is used in both the ICF and the ADF, the purposes of the element in each file are quite different. A protocol declaration in the ICF registers a custom delivery protocol and tells SQL-NS how to load it at runtime. In the ADF, a protocol declaration in a notification class specifies that notifications of that class can be delivered with the specified protocol. The protocol declaration may also customize the protocol's behavior for the particular notification class by supplying protocol-specific data fields and execution settings. You need to provide <Protocol> declarations only for custom delivery protocols in the ICF, but in the notification classes declared in the ADF, you need to provide <Protocol> declarations for all supported protocols, built-in or custom.

Notification Batches and Distributor Work Items

Chapter 8, "Event Providers," describes how events are grouped into units called event batches. Similarly, notifications are grouped into notification batches. By default, the generator groups all the notifications generated by a single invocation of a match rule into one notification batch. However, you can control notification batch sizes through settings in the ADF. If you specify a small notification batch size, the generator may divide the notifications generated from a single match rule invocation into several notification batches. Chapter 12, "Performance Tuning," describes the notification batch size settings in detail.

As you saw in Chapter 5, "Designing and Prototyping an Application," the SQL-NS compiler creates a notifications table for each notification class declared in the ADF. It also creates a notification batches table for each notification class, named NS<NotificationClass>NotificationBatches1, where <NotificationClass> is the name of the notification class. For example, the notification batches table for the NewSong notification class is called NSNewSongNotificationBatches1 (note the 1 at the end of the table name). This table tracks information about each notification batch, including the batch ID, the number of notifications it contains, and the times at which generation started and completed. The generator creates a row in the notification batches table for each notification batch it produces.

When the generator finishes generating a notification batch, it marks the batch record with a status code indicating that the batch is ready for distribution. Whenever it has resources to do new work, the distributor looks for new notification batches marked with this status code and begins processing them.

In the first stage of processing a notification batch, the distributor determines the delivery channel for each notification in it by looking up the corresponding subscriber device record (using the device name specified in the notification data). It then divides the batch into smaller groups of notifications based on delivery channel. Each of these smaller groups of notifications is called a distributor work item because it represents an independent unit of work for the distributor. Each distributor work item consists of the subset of notifications in the batch going to one particular delivery channel. Figure 10.4 shows the division of a notification batch into distributor work items.

Figure 10.4. Notification batches are divided into distributor work items.

In Figure 10.4, Device1 and Device3 are configured to Delivery Channel 1, and Device2 and Device4 are configured to Delivery Channel 2. This configuration of subscriber devices to delivery channels would be specified in the subscriber device records, which are not shown in Figure 10.4. The four notifications in the batch illustrated are each targeted to one of the four devices. The batch is divided into two groups of notifications, based on the delivery channels of those target devices. The first distributor work item contains all the notifications in the batch going to Delivery Channel 1, and the second distributor work item contains all the notifications going to Delivery Channel 2.

Each notification class supports a particular set of protocols, as declared in its <Protocols> element. A notification batch is always divided into as many work items as there are delivery channels that use the protocols supported by its notification class.

Distributor work items are considered to be independent from one another, so the distributor attempts to process them in parallel. If an application has multiple distributors, the work items created from a single batch may be processed by different distributors.

Delivery Protocol Operation

On startup, the distributor creates a delivery protocol object for each delivery channel in the SQL-NS instance. The type of delivery protocol object created for a delivery channel depends on the protocol name specified in the delivery channel declaration. For example, the distributor creates an object of the SMTP delivery protocol class for a delivery channel that specifies SMTP as its protocol name. Similarly, if a delivery channel specifies a custom delivery protocol's name in its declaration, the distributor loads and creates an instance of the specified custom delivery protocol class for that delivery channel.

The distributor initializes each delivery protocol object by passing it the arguments specified in the associated delivery channel's declaration. Usually, these arguments provide the delivery protocol with the information it needs to connect to the endpoint that the channel represents.

As the application runs, the generator produces batches of notifications, and the distributor picks these up when they are ready. The distributor divides the batches into work items and begins processing them. During the processing of a work item, the distributor reads the notification data, passes it to the content formatter, and then passes the formatter output to one of the delivery protocol objects it created for the delivery channels in the instance. It chooses the delivery protocol object associated with the target delivery channel of the notifications in the work item. Along with the formatted notification body, the distributor also provides the delivery protocol with information about the intended recipient of each notification, including the subscriber ID and device address.

The delivery protocol may also need additional data to deliver a notification. Depending on the network protocol used, the delivery protocol may have to package the notification body into a larger message structure that includes headers required by the delivery system. For example, SMTP defines a set of message headers that specify information, such as the email subject line and encoding format. The SMTP delivery protocol needs to construct these headers for each notification it delivers. Some of the message header values are determined by the delivery protocol itself, but for others, you may need to specify the value, based on the notification data. A good example is the subject line in SMTP email messages. Because you define the notification content, you probably want to specify the text that the SMTP protocol puts in the subject line header when delivering your notifications.

SQL-NS allows you to pass additional data (beyond the formatted notification body) to a delivery protocol by defining protocol fields. Protocol fields are defined in the <Protocol> element in the notification class declaration (in the ADF) by providing a set of field names and expressions that compute their values. Protocol fields work much like computed fields (described in Chapter 9). Whereas computed fields are passed to the content formatter, protocol fields are passed to the delivery protocol. Protocol field expressions can operate over the notification data and call SQL functions.

Usually, each protocol requires a specific set of protocol fields from which it constructs message headers. The list of fields required by a protocol isn't actually declared anywhere in the ADF or ICF, but it is usually described in the documentation that accompanies the protocol. The File delivery protocol does not require any protocol fields, so none were specified in its <Protocol> declaration. The SMTP delivery protocol requires protocol fields that specify values for the various headers in an email message (including the email subject, priority, body format, and the "to" and "from" lines). When we declare support for the SMTP delivery protocol later in this chapter, you will see the required protocol fields defined.

The distributor evaluates protocol field expressions when it reads the notification data and passes the resulting values to the delivery protocol (along with the formatted notification body and the recipient information). The delivery protocol uses all this data to form the final notification message, including any message headers, and performs the operations needed to deliver the notification. It then reports the delivery status (succeeded or failed) back to the distributor by means of a callback. The distributor records this status in the notifications table.

Digest and Multicast Delivery

When digest delivery is used, it has no impact on the delivery protocol. Digesting is purely a content formatting function: The content formatter receives multiple sets of notification data and aggregates them into a single message. This single message is then passed to the delivery protocol. The delivery protocol handles it the same way it would a formatted message produced from a single notification.

Multicast delivery, on the other hand, does impact the delivery protocol. When multicast delivery is used, the distributor may pass the delivery protocol multiple sets of recipient information along with a single formatted notification body. The delivery protocol must then deliver the notification to each of the recipients. The mechanism the delivery protocol uses to do the actual delivery is not stipulated by SQL-NS. If the network protocol provides a way to send a single message to multiple recipients, the delivery protocol can use this facility. If the network protocol does not support this kind of delivery, the delivery protocol can just send a separate message to each recipient in the supplied list. Even if the delivery protocol ultimately does send a separate message to each recipient, using multicast still provides worthwhile performance gain because the notification would have been formatted only once.

Note

Multicast delivery is available only on the Enterprise Edition of SQL-NS.

Delivery Failure: Retry and Notification Expiration

Notification delivery can fail for a number of reasons. The network might be down, the delivery protocol might encounter an error, or the target address might be invalid. When a delivery failure occurs, an application may need to attempt the delivery again at a later time. SQL-NS supports retry of failed deliveries, using a configurable retry pattern.

In the protocol declarations in the ADF, you can specify retry schedules for notifications that fail to be delivered. Listing 10.10, later in this chapter, shows an example of a retry schedule declaration. A retry schedule consists of a set of delay intervals. If one or more delivery failures occur during the processing of a work item, after the work item processing completes, the distributor waits the amount of time specified in the first delay interval and then attempts to process the work item again. During the retry attempt, the distributor attempts to deliver the notifications that were not successfully delivered before. If there are still failures during the second attempt, the distributor waits the amount of time specified in the next retry delay interval and then tries to process the work item once more.

Note

All retry scheduling applies to distributor work items, not to individual notifications. The retry delays specified in the ADF govern the time the distributor waits before beginning to reprocess a work item if its previous attempt encountered failures. The delays do not necessarily translate to the exact times between successive attempts on individual notifications.

The distributor continues retrying the notification delivery until the delivery succeeds, the retry schedule is exhausted (meaning no more delay intervals in the specified list), or the notification expires. When you define a notification class, you can optionally specify an expiration age for notifications of that class using the <ExpirationAge> element. Undelivered notifications older than the expiration age are discarded without being delivered. By default, notifications have no expiration age (so they never expire). The <ExpirationAge> element is used in the notification class declaration shown in Listing 10.10, later in this chapter.

Notification expiration provides a convenient way for you to set a time limit on the lifetime of notifications. Often, the value of a notification to a subscriber diminishes over time. Notifications are supposed to provide timely information, and if they get too old, the information may not be useful to the subscriber anymore. The particular expiration ages that make sense in your applications depend on the meaning of the notification content. By setting an appropriate expiration age, you avoid unnecessary delivery attempts after notifications grow too old to be of value.

If the distributor encounters several consecutive delivery failures while trying to deliver the notifications in a work item, it abandons the whole work item, possibly leaving several notifications undelivered. The reasoning behind this behavior is that consecutive failures usually indicate that the network is down, and flooding it with additional delivery attempts may only make the problem worse. When the distributor abandons a work item because of several consecutive delivery failures, it attempts to process the work item again according to the defined retry schedule. As always, during a retry, the distributor attempts to deliver only those notifications that failed on the previous attempt or that were not attempted at all.

By default, 20 consecutive delivery failures must occur before the distributor abandons a work item. You can control this setting on a per-protocol basis by means of the <FailuresBeforeAbort> element in the ADF (described in the SQL-NS Books Online).

The Notification Distribution Views

The SQL-NS compiler creates views in the application schema that you can query for information about the delivery status of notifications. For each notification class, the compiler creates a view called NS<NotificationClass>NotificationDistribution, where <NotificationClass> is the name of the notification class. For example, the distribution view for the NewSong notification class is called NSNewSongNotificationDistribution.

This view contains a row for each delivery attempt made for each notification. The information in the view includes the notification ID, the name of the delivery channel used, the distributor that processed the notification, the delivery status, and the values of the notification fields. The SQL-NS Books Online provides detailed documentation on the columns in the notification distribution views: consult the "NS<NotificationClassName> NotificationDistribution View" topic in the SQL-NS Books Online for more information.

Caution

The writing of the logging information you see in the distribution views can significantly reduce distributor performance. SQL-NS offers a number of settings that enable or disable the logging of some optional information. By default, these settings are configured to enable logging of all available information. By selectively disabling the logging of optional information, you can reduce the logging overhead and thereby allow the distributor to run faster. In high volume applications, you may need to disable all optional distributor logging to realize the required level of performance. For more information on setting the distributor logging options, see the section "Distributor Logging Options" (p. 445) in Chapter 12.

Note

Because the notification distribution view shows one row for each delivery attempt on a notification, there can be multiple rows with the same notification ID.

Encrypting Delivery Channel Arguments

Delivery channel arguments often contain sensitive information such as server addresses and authentication credentials. For this reason, it's highly recommended that you use the argument encryption feature of SQL-NS to encrypt delivery channel arguments.

As described in Chapter 8, argument encryption is enabled in the ICF and applies to all argument values (including delivery channel arguments). See the section "Argument Encryption" (p. 237) in Chapter 8 for information on how to enable argument encryption. Since Chapter 8, the source files we've been using have enabled argument encryption. We continue this practice in this chapter.

Database Roles for the Distributor

Database objects in the instance and application schemas related to notification distribution are set up so that only members of the NSDistributor role can access them. The distributor runs in the SQL-NS engine, under the credentials of the engine's account. For it to access the required parts of the database, the account with which the engine connects to the database needs to be granted membership in the NSDistributor role. If this account is a member of the NSRunService role, it already has the required permissions because NSRunService is a member of NSDistributor.

Note

If you're using Windows Authentication, the distributor connects to the databases using the credentials of the engine's Windows account. If you're using SQL Server Authentication, the distributor connects using the SQL username and password you supplied when registering the instance.