未启用Service+Broker问题.doc

未启用当前数据库的 SQL Server Service Broker，因此查询通知不受支持。如果希望使用通知，请为此数据库启用 Service Broker。解决办法：在Microsoft SQL Server Management Studio Express新建查询中执行如下语句alter database DotShoppingCart set enable_broker若命令执行成功的话，验证一下，执行下面SQL语句select IS_BROKER_ENABLED from master.sys.databaseswhere name=DotShoppingCart若出现下图所示，则配置成功注：DotShoppingCart是一个数据库扩展阅读Service Broker 端点SQL Server 使用 Service Broker“端点”使 Service Broker 与 SQL Server 实例外部进行通信。端点就是一个 SQL Server 对象，代表 SQL Server 进行网络通信的功能。每个端点支持一种特定的通信类型。例如，HTTP 端点使 SQL Server 可以处理特定的 SOAP 请求。Service Broker 端点将 SQL Server 配置为通过网络发送和接收 Service Broker 消息。Service Broker 端点为传输安全模式和消息转发提供选项。Service Broker 端点侦听特定的 TCP 端口号。默认情况下，SQL Server 的实例不包含 Service Broker 端点。因此，默认情况下 Service Broker 不通过网络发送或接收消息。必须创建 Service Broker 端点才能向 SQL Server 实例外部发送消息或从该实例外部接收消息。有关创建 Service Broker 端点的详细信息，请参阅 CREATE ENDPOINT (Transact-SQL)。一个实例可以只包含一个 Service Broker 端点。安全说明创建 Service Broker 端点后，SQL Server 将接受在该端点中指定的端口上的 TCP/IP 连接。Service Broker 传输安全模式要求授权后才能连接该端口。如果运行 SQL Server 的计算机启用了防火墙，则该计算机上的防火墙配置必须允许该端点中所指定端口的传入和传出连接。有关 Service Broker 传输安全模式的详细信息，请参阅 Service Broker 传输安全性。Service Broker 传输安全性Service Broker 传输安全性使数据库管理员可以对与数据库的网络连接进行限制并且可以加密网络上的消息。Service Broker 端点支持基于证书的身份验证和 Windows 身份验证。传输安全性应用于两个实例间的网络连接。传输安全性控制哪些实例可以通信并提供两个实例间的加密。传输安全性作为一个整体应用于实例。传输安全性不保护各个消息的内容，也不控制对实例中各个服务的访问。Service Broker 对话安全性在各消息离开发送实例至到达目标实例之间，对消息进行加密。实例使用的身份验证类型取决于每个实例的 Service Broker 端点的 AUTHENTICATION 选项。当端点指定多个身份验证方法时，具体使用哪个身份验证方法取决于为发起连接的实例指定这些方法时的顺序。协商期间，每个实例都报告其所支持的所有身份验证类型和算法。发起方按照接受方指定的顺序尝试两个端点都支持的身份验证方法。这意味着，对于长时间运行的会话，消息可能通过多个连接来交换，并且连接的身份验证可能随着发起会话的实例不同而不同。Service Broker 端点支持两种类型的加密。与身份验证一样，具体用于连接的加密方法取决于为发起连接的实例指定这些方法时的顺序。解析SQL Server 2005中的Service Broker来源：682007年08月29日 09:08网友评论：0条点击： 740SQL Server 2005中的新内容Service Broker，可用来建立以异步消息为基础的应用。Service Broker应用是一个或者多个程序的集合，能够完成一套相关的任务。为了更加深入的了解其涵义，让我们来看看组成应用的各个对象。 消息器 消息是Service Broker应用中信息传递的基本单元。在Service Broker内部，消息是按发送顺序进行接收,并且保证每个消息只会发送和接收一次。而且消息保证不会丢失。有时，某个消息已被发送，但是没有马上收到。当发生这种情况时，Service Broker会保存消息并尝试再次发送。消息带有确认信息以确保经他们传递的信息就是他们所等待接收饿。可以传递的消息最大可达2G。 会话 当消息在Service Broker应用中传递使使用会话（或者对话）方法。会话一般针对特别任务生成，当任务完成以后就会被删除。会话才是Service Broker最主要的信息交换结构，而不是消息。会话发生在两个服务端点之间：发起会话的服务(发起方)，以及接受会话需求的服务（目的方）。 队列 在Service Broker应用中，消息以队列方式保存等待接受处理。在内部，Service Broker队列是一种特殊的表格，能够通过指明队列名称的SELECT语句进行查看，不能在队列中执行INSERT, UPDATE, 或者DELETE语句。保存在队列中的消息即使重新启动服务器也不会丢失。 服务 服务程序是读取并处理队列中的消息的程序。这种服务可以是特定的存储程序，或者连接数据库的不同程序。每个服务必须与队列相关。正如先前所提到的，会话发生在服务之间。 会话组 会话组用来接连消息的处理过程并使之相互关联。每个会话是会话组中的一份子。主要的概念是有些消息与其他消息相关，会话组将这些相关的会话按照要求的顺序结合在一起。事实上，所进行的处理具有对会话组里的全部消息的高级连续访问权限，直到处理完成。 Service Broker 应用还有很多其他相关的部分。以上提到的各个部分在Service Broker起主要作用。您对它们越熟悉，您就会更熟练的掌握Service Broker应用的编写。现在，我们来看如何使用Service Broker应用来实现业务交易。 业务处理 业务流程中的任务很少按照同步进行。这些流程经常由彼此独立的任务组成，但是很可能同时发生，可能重叠，可能需要流程中别的步骤的支持。这种情况经常出现在生产产品的过程中，特别是客户订制的生产过程，比如汽车生产。 当有人预订一辆定制的汽车，汽车各个部件的生产过程并不彼此依赖。例如，这些部件可以同时生产。但是在最后阶段，当进行组装时你会遇到下面的问题： 取决于前一步骤的步骤。 如果出现错误会对整个项目的成功起绝对性影响的步骤。 需要购买者补充信息的步骤。 除了这种情况以外，如果潜在购买者取消了订单，那么进行补偿的程序也要符合逻辑。您可能对有类似特征的业务流程比较熟悉。 当数据库执行这样的流程时，经常按一系列数据库交易进行处理，每个交易都有单独的基本任务。当其中一个数据库交易被接受或退回时，这一系列相关的业务交易通常都无法以此方法完成。这些交易必须被设计成失败时，通过逻辑判断退回业务交易。整个业务程序都很难进行，因为这些独立的交易实际上是于彼此相关的，他们都包含同样的总体目标。这是Service Broker这样