xiaoxinlucky
助理工程师
帖子
603
精华
12
无忧币 2017
积分 1392
阅读权限 40
来自 (保密)
|
发表于:2008-1-7 11:24
标题：SQL Server 2005如何满足面向服务的数据库体系结构
＜上一帖 |
下一帖＞
摘要
数据库是用面向服务的数据库体系结构建造的分布式体系结构的一部分。本文探究SODA背后的一些概念，以及SQL Server 2005如何适合这个体系结构。
目录
简介
面向服务体系结构中的数据
SQL Server 2005 SODA 特性
SODA 计算的拓扑结构
小节
简介
20世纪90年代的CS架构和n层应用程序体系结构，随着在许多大型的Internet电子商务站点的应用，遇到了很多可伸缩性和可用性的问题。其中一个主要的问题就是，希望将数据存储在一个大型的集中式数据库中，用来让所有客户端组件直接访问。实际上，所有关于数据库的通信，都是以SQL语句或存储过程中的批量语句的形式完成的，这样客户端对于特定的工作接收数据。
当试图将遗留下来的系统合并到新的应用程序中时，还会引发其它的一些问题。在用各种不同的技术和平台部署各种各样的系统之后，这些系统能够很好的完成它们的工作，但是随着各种环境的互连的日益增多，它们并没有一个清晰的方法来与其它的应用程序进行交互。要实现今天的应用程序所需要的灵活性是一件非常困难的工作。企业对企业(B2B)交互使事情更加的复杂化，并且需要完成电子商务的标准和可靠的方法。很明显，进展中的系统符合当今全球商业环境的需求，它需要一个体系结构，来有效的使用遗留下来的系统，并提供一个灵敏的商业基础架构。
作为这些需求的回应，在过去的三到五年中，可以看到一些大规模的，松耦合的分布式系统架构已经慢慢浮现出来，特别是Internet电子商务站点已经成长为主要的商业运作方式。面向服务的体系结构(SOA)已经成为主要的松耦合的，以服务为中心的体系结构。基于SOA的应用程序更加的坚固，而且对于使用各种方法添加资源以扩大功能来说更加的简单，并且它允许将遗留下来的系统集成到B2B和其它系统中。
在一个SOA应用程序中，SOA服务的提供者，消费者，和其它的组成部分把数据当成他们的角色中的自然属性来处理。一个SOA应用程序典型的使用中心数据库来存储和保护数据，但是可能会有许多这样的大型的数据库来存储数据，比如将销售和制造等数据以及它们的子集分开存储。每个服务提供者和消费者可能对缓存数据由一个特定的需求，或它们自己专门的数据存储。并且，应用程序中不同部分之间传递的信息，通常是一些值得存储的数据。
数据基于它们的性质，通常可以按照四种方式在系统中被划分：
• 参考数据用来创建服务请求，比如产品目录。它必须以一个其它服务都能用的格式保存，并且以一个不会随着时间变化的方式来标识，比如目录日期。
• 活动数据是一个瞬间的数据，用来执行一个特定的工作，比如一个用来从商品目录中检索已购买的商品的挑选列表。因为它对于服务来说是私有的，所以它所用的格式没有必要被其它的服务所理解。
• 资源数据是长期存在的数据，并在服务的内部使用，比如SKU，客户数据，以及账目数据。
• 服务交互数据用来在服务之间通信。它的格式必须被所有的服务理解，并且随着时间的改变它必须保持不变。例如，一个订单在服务之间传递。如果订单丢失，那么它必须能够以相同的格式重新生成一个订单，并重新传输。
图1 显示了一些终端，组成了一个松耦合的应用程序，它通过SOA的原理创建。服务消费者—可能是一个客户端应用程序，一个服务器端应用程序比如一个Web服务器，或其它类型的应用程序—发送一个消息给服务提供者。在复杂的系统中，一个消息路由器首先受到消息并应用一些逻辑，使请求路由到适当的服务提供者。然后，该服务提供者收到消息，可能解开并重新格式化，做一些必要的工作，然后可能会给服务消费者发送一个相应。
图1：面向服务体系结构应用程序的一小部分
图1中重要的是在事务中的每个节点都是以不同的格式接收、存储和发送数据。有时，数据是瞬时的，有时每个节点可能将数据保存在缓存或本地的数据库中。（关于那些数据值得存储的讨论，请参考Microsoft Corporation的Jim Gray所写的“Queues Are Databases”。这篇白皮书的最后附有参考列表。）
按照这些在应用程序中处理数据的新方法，数据库作为SOA应用程序的核心，正面临着比单层的，n层的应用程序更多的挑战。数据的集成仍然重要，但是现在还有更多的需求：
• 数据库的操作操作环境，要求用基于XML的消息发送请求，而不是用专用连接
• 缓存数据的存储需要知道什么时候应当更有效的刷新数据，而不是以固定的计划来刷新
• 数据库必须参加到以固定顺序发生的对话中
• 在数据库上必须有复杂的逻辑
XML为广泛的分布式系统提供了非常好的消息格式。它能够很方便的被几乎任意一个系统解析，并拥有一个架构模型来为数据定义适当的结构。交换消息的系统可以向一个XML消息中附加信息，当它从系统中经过时，数据就被累积在消息中。系统解析并处理它们理解的内容，并忽视其它的部分。XML被设计为一种适合支持分布式系统的格式。
Microsoft的架构师观察到了这些架构上的趋势，并建造了Microsoft® SQL Server™ 2005来迎接新的挑战，同时还要继续支持许多已经存在的非SOA应用程序。这篇白皮书讨论了在一个SOA应用程序中使用SQL Server 2005时，需要用到的Native Web Service访问，数据库变化通知，Service Broker，和SQLXML。本文不会向您介绍SOA ，也不会介绍SQL Server 2005的新功能，本文假设您已经熟悉这些内容。关于这些主题的更多信息，请查阅文章末尾处的参考。
面向服务体系结构中的数据
当对SOA概念进行探索时，我们很快就意识到，整个系统中的每个组件都在接受、处理、和发送数据，并把它们作为主要工作。即使服务提供者对来自一个服务消费者的消息的回复，只是一个简单的翻转一个bit，来打开或关闭什么东西，而且并不需要与数据库交互，这个服务提供者也必须在消息中处理数据，来决定即将完成的工作。但是现代的商业应用程序广泛的处理数据，所以通常一个SOA组件会访问一个本地的数据库，或一个集中的数据库，或经常是都访问。
SQL Server 2005中的许多新功能是一个完整的体系结构设计的一部分，并支持使用数据库作为一个SOA服务提供者。Microsoft的SQL Server小组称其为面向服务的数据库体系结构，或SODA。
在数据库引擎中实现SOA功能，有一些值得注意的原因，包括：
• 划分到哪一层。即使在最大的企业SOA应用程序中，一个单独的服务可能有不同的划分尺度。一个不经常使用的服务可能比一个典型的小部门的数据库有更少的活动。与SQL Server集成，意味着一个服务程序可以利用所有的本地对于从嵌入的设备到最基本的企业数据库服务器的支持，同时不会增加管理上的复杂度。服务的逻辑代码可以在不同的划分尺度上执行，并且在部署时，每个实现都可以提出来到一个单独的中间层。使用SQL Server 2005，服务逻辑可以在数据层上运行，或部署到中间层上。如果您谨慎的设计一个应用程序，那么怎样划分是部署时决定的，而不是在设计或开发时决定的。
• 怎样划分开来。您可以将以数据为中心的计算以多种方式划分开，通常可以划分数据库或使用面向服务体系结构分布处理。将数据库划分开来会导致一个相对紧耦合的数据库，而面向服务的解决方案更加的松耦合。直接在数据库中建立SOA的支持，将减少一个网格解决方案中的组件的处理。
• 消息就是数据。各种各样的请求和相应的消息可能会值得存储到数据库中。保留这些消息可用提供了一个历史，使得您可以审计和分析事物。因为消息是被存储在表中并有可用的系统目录视图，所以您可以简单的使用T-SQL来查看系统的任一个状态。
在SQL Server中实现SOA功能，会获得巨大的收益，因此它可以在一个SOA应用程序中担当一个独立的服务提供者。但这样的话，它必须能够作为一个服务提供者，并至少要提供一些基本的功能。
SOA服务提供者的要求
对于SQL Server 2005或其它的数据库引擎要承担一个单独的SOA服务程序的角色，除了它本身所具有的处理数据的功能以外，它必须还要实现许多功能：
• 终端支持。SODA提供者必须提供对接收和发送消息的通信的支持，典型的比如TCP socket，HTTP GET or PUT，SOAP终端，或其它类型的终端。
• 处理服务请求。SOA中的大多数消息是用XML来格式化的，所以服务提供者必须能够处理数据，并在必要时通过服务中的一些组件，将附加的数据转化为其它的格式。它必须能够参与到复杂的对话和会话中，并能够接收相互依赖的消息并发送给其它组件。
• 服务逻辑宿主。服务提供者必须能够执行复杂的逻辑以处理消息，并做出必要的响应。它将需要完成一些通常的应用程序服务器的工作，比如池资源，激活，和划分逻辑处理。
除了对数据管理的基础架构的支持，SQL Server 2005的各种新的特性提供了对这些功能的支持。例如，一个服务提供者必须安全的参与到一个SOA系统中，并能够验证用户的身份，并相应的向其它组件提供它自己的凭证，而且要参加到会话和事务中。
SQL Server 2005建立在SQL Server 2000关系型数据库引擎的基础之上，同样还建立在一些中间的新技术的发布的基础之上，比如SQLXML 3.0，Notification Services和其它的一些工具。所有的这些实现了面向服务数据库体系结构。
SQL Server 2005 SODA 特性
SQL Server 2005包含了实现SODA的一些特性，因此在一个分布式，松耦合的应用程序中，一个单独的SQL Server处理可以作为一个全面的服务提供者。Microsoft期望这些特性将最终在企业数据库系统中，像网络通信，线程池，和存储过程等一样的普遍。这些SQL Server 2005的新特性如下：
• Native Web Service访问，允许在SOAP和其它协议之上的基于消息的通信，并利用Windows Server 2003 HTTP kernel-mode驱动，Http.sys。
• Service Broker，一种新型的事务中间件，以服务为中心，而不是以消息为中心，支持可伸缩的服务。
• 查询通知允许数据相关的缓存被通知，数据需要刷新，因为底层的数据库已经改变。该通知是基于原有的用来创建缓存的查询而生成的。
• SQLCLR将复杂的逻辑处理深度整合到数据库中，减少远程数据访问带来的延迟。
Native Web Service访问：HTTP和其它终端
多年以来，从客户端到SQL Server服务器上的通信的唯一方式，是使用专用的表列数据流（TDS）的协议。TDS依然是最快最有效的数据访问方法，但是要和服务器通信，客户端必须安装相应的库。如果SQL Server 2005想作为一个全面的SOA服务提供者，那么它必须支持基于标准化的协议，来为不同种类的用户接收和处理请求。SQL Server 2000的SQLXML扩展，通过包含一个ISAPI filter为这个功能打下了基础，它使用IIS并允许通过HTTP Web Service的方式访问SQL Server。
SQL Server 2005支持一种正式的终端抽象，您可以用来支持不同的终端类型，包括TDS，数据库镜像，Web Service，和Service Broker。在一个SOA方案中，HTTP终端类型，允许SQL Server实例在任何支持Web Service over HTTP和WS-Security协议的设备上，为任何类型的应用程序，作为一个服务提供者出现。
完全的native Web Service访问需要SQL Server 2005安装在Windows Server 2003上，并利用Windows Server kernel-mode HTTP监听器。图2中显示了紧密的集成，以及驱动和数据库之间的直接连接。当HTTP监听器通过80端口（默认）接收到一个HTTP请求，它会直接将消息路由到您在SQL Server中指定的终端。然后SQL Server处理请求，并通过Windows返回一个消息。
图 2: SQL Server 2005集成Windows Server 2003 Http.sys驱动
因为安装不需要IIS，并且请求从kernel-mode Http.sys驱动被直接发送到SQL Server，所以这样的请求对于管理员来说非常有效和简单。Http.sys在不同的应用程序间提供了kernel-based进程隔离，因此在相同的和其它SQL Server实例中的不同的终端不会互相影响。
当HTTP监视器在Windows中被配置为向SQL Server发送请求，DBA可以定义终端并将存储过程和标量值函数以Web方法绑定到终端。通过CREATE ENDPOINT来制定一个唯一的URL，它将被用来监听HTTP请求。通常，它们将会是“http://myServer.com/myEndpoint”的形式，DNS系统可以将请求发送到正确的服务器。服务器将请求路由到所定义的终端，然后到SQL Server的SOAP处理层。每个SQL Server实例可以有很多个终端，并且每个终端也可以绑定多个Web方法。
绑定到一个HTTP终端的Web方法可以使一个存储过程或是一个标量值的用户定义函数。在SQL Server中定义的方法名不能和公用应以的Web方法名重复。SQL Server将为Web方法执行正确的代码。Web方法的实现并不需要任何代码来解析请求或格式化结果，因为SQL Server 2005会为您管理这些功能。对于一个终端，您可以执行成批的SQL语句，但是，出于安全的原因，在一个SOA应用程序中这可能不会起作用，除非是在一个高度控制的环境中。
一个终端可以被配置为自动生成和提供Web Service Definition Language（WSDL）数据，用来指定提供者的Web方法的接口。如果您需要手动调节提供的信息，您也可以配置服务器来提供自定义的WSDL，或者可能根本不提供WSDL。
终端支持基本，摘要，集成（NTLM或Kerberos），和SQL Server身份验证，但是不支持匿名的请求。这种身份验证方法的选择，支持在一个混合平台上的SOA应用程序的几乎任意的客户端，例如，您可以在Windows消费者中使用集成身份验证，在其它消费者中使用SQL Server身份验证。SQL Server支持WS-Security规范，所以您可以使用用户名的token来传递凭证给SQL Server身份验证。您能进一步限制或允许基于消费者的IP地址的查询。
HTTP终端默认是关闭的，因此一个新安装的SQL Server实例默认的安全的。这意味着不可能对其进行攻击，除非HTTP终端被管理员显示打开。只有sysadmin角色的成员或终端的创建者，才可以连接到该终端，直到他们使用GRANT CONNECT语句，显示的为其它用户的连接授权，其它用户才可以访问。和其它的HTTP连接一样，您也可以用SSL对传输管道进行加密，用来保护一些身份验证方法中以明文传输的凭证。
可靠的通信：Service Broker
一个SOA服务程序的主要的要求就是它必须能够和应用程序中其它的组件进行通信。一个健壮的通信基础结构必须是安全的，异步的，可靠的，并且是可伸缩的。因为SOA建立在消息的基础之上，所以如果SQL Server 2005要成为一个服务提供者的话，它必须支持通信。
SQL Server 2005 Service Broker是一个通信特性，它可以接收，处理，并发送消息。它和数据库引擎紧密的整合。Service Broker方便了SOA服务程序之间的消息交换。Service Broker为依靠有序消息发送的应用程序提供了多种功能：
• 异步。通过排队信息，服务程序能够有效的处理工作量，而不会在最大负荷时出现严重的阻塞。
• 有序。在一个服务消费者和提供者的会话中，消息的顺序通常很重要。系统必须考虑到发送消息的顺序，并保证消息的处理应按正确的顺序进行。
• 可靠性。通过和数据库引擎的紧密集成，Service Broker充分利用了消息和对话事务来保证关键消息的正确性。
• 持久性。无论一个消息和它的处理是否成功，这个消息或结构必须不受系统故障的影响。如果处理失败，那么消息应当被放回接收队列中。
Service Broker 对象和处理过程
Service Broker引入了许多新的数据库对象，比如message types，service contracts，queues，services，dialogs，conversation groups，和service programs。建立一个服务提供者包括多个步骤来创建和配置其中的一些对象，这时会利用各种新格式的T-SQL CREATE语句。一旦这些对象在适当的位置，您可以使用T-SQL SEND语句发送XML格式的消息，并且一个服务程序能够使用RECEIVE语句将他们放在接受队列中。
消息被发送到您定义的服务中，在那里将消息放到一个队列中等待服务程序的处理，如图 3。通常一个服务程序是一个存储过程，它的作用很像是一个Windows Message Pump，接收消息，处理它们，并且发送恢复。Service Broker使用在pull和event模型之间的一种模型，必要时激活绑定在队列上的服务程序，来处理接收到的消息。
Figure 3: Service Broker结构和单一对话
Service Broker队列是支持可靠的异步消息处理的主要方法。因为这个队列是一个数据库表，所以队列中的消息和其它关系表一样，包括可以利用数据库的灾难恢复，以及像其它数据一样用ACID（原子性，一致性，隔离性，耐久性）特性的事务来保证消息的传输。
但是，Service Broker不止能够管理队列。它还提供了一个完全的框架，用以支持需要可靠通信的应用程序。除了节省了开发人员创建复杂的通信基础结构（一项使人畏缩的工作）以外，Service Broker管理消息，保证它们以正确的顺序被传递。它还管理会话，契约，路由，和远程服务绑定。
当一个传统的面向消息的应用程序超越了一种简单的请求/响应的通信模式时，它必须能够在消息到达队列时处理相关和并发的控制问题。当有多个服务程序同时从一个队列中处理消息时，这将会成为一个十分重要的问题。Service Broker用会话组锁定机制来处理并发问题。一个会话组是用于指定工作的所有对话的集合。一个对话是服务程序之间的消息交换，其中每个服务程序都作为一个服务消费者和提供者。
会话组
图 4显示了一个典型的会话组，它在一个简单Order Processing Service中响应收到的Process Order消息。当收到Process Order消息时，Order Processing Service发送一个消息到Credit and Inventory Check Services。当等待正在进行的会话的响应时，数据库会变成一种悬而未决的状态。然后当两个服务的响应分别或几乎同时到达时，会话组将会被激活。
图 4: 有多个对话组成的会话组
会话组的激活，而不是队列中消息的到达，将促使服务程序处理消息。一个活动的会话组在一个事务中被处理，这个事务可能只被一个服务程序处理。这里对于不同的场景，有许多含义：
• 当一个服务程序正在处理Inventory Check 时，又收到Credit Check的响应。在这种情况下，Credit Check响应不会被处理，直到会话组被其它的服务程序重新激活。
• 在任意服务程序消费活动的会话组之前，两个响应到达。服务程序通过两个消息一起来表达。另外，活动的服务程序可以在队列中检查附加的消息，并在完成它的工作前处理它们。
在第二种情况下，批处理可以获得可伸缩的解决方案，并且与会话组相关的工作可以累积以响应服务程序的处理延迟。当状态信息被保存并与表示该组的GUID关联时，会话组也可以优化状态检索。一个处理会话组相关的消息的服务程序，可以一次检索会话组的状态，而不是检索每一个消息。
整个会话组需要完全用于它的工作，或完全不工作。如果一切正常，那么会话组状态能够被持久的提交给数据库，有效的处理定单，这样会引起发送更多的消息，比如发送给一个处理运输的服务。如果一切不正常的话，原来的消息会被放回原来的Order Processing Service的队列中，并且数据库的状态会被恢复到接收这个消息之前的状态。
当一个服务程序从一个会话组的队列中得到一个消息，这个组将被锁定，这样保证会话的消息是以服务消费者指定的顺序被处理。Service Broker用这种机制来保证消息以正确的顺序被处理。
与数据库集成
Service Broker被建在SQL Server 2005数据库引擎中。它不是用一个单独的事务中间件或消息队列基础结构（像Microsoft Message Queue）。这样会带来许多优势（其中一些在服务消费者和提供者在一个数据库中时更为明显）：
• Service Broder应用程序用T-SQL和SQLCLR部署。您创建一个Service Broker应用程序时将使用存储过程，用户定义函数，和.NET Framework代码，所有这些都被Service Broker对T-SQL的扩展所支持。当时用SQL Server创建一个服务提供者时，您可以权衡您现有的技术来使用。
• 会话组锁定机制支持多个队列读取者。Service Broker用一个特殊的数据库锁，它允许多个服务程序在一个队列中处理消息。
• 管理更加简单。因为消息和数据都位于同一个数据库中，所以数据库的恢复会同时恢复消息和数据。如果它们是分开的，那么它们很可能不同步，并且很难指出哪个消息已经被处理过。如果数据库使用镜像，群集，或者其他的SQL Server数据保护功能，那么消息将和其他数据一样被保护。另外，您只需要在一个位置设定安全选项，即使您必须设定Service Broker和数据对象的权限。
• 处理更加有效。Service Broker支持与其它的Service Broker服务交换消息，如果消费者和提供者服务在一个数据库中，那么消息可以直接发送到接收队列中，因而绕过了发送队列并节省了大量的处理时间。因为Service Broker对数据库实例中的所有的队列有一个全局的视图，所以它能够有效的管理消息，队列和基础结构。
• 支持通用工具和语言。您可以使用相同的工具和语言―比如T-SQL，Microsoft Visual Basic® .NET，Microsoft Visual C#®―来控制数据库中的数据，管理Service Broker。开发人员和管理员可以使用他们熟悉的工具来开发恶化管理应用程序。
Service Broker与其它的事务中间件在其他的重要的方面还有一些不同：它是以服务为中心的而不是以消息为中心的。这使得SQL Server能够对于来自多个并发的服务程序的消息处理复杂的并发控制，并允许事务处理优化。
查询通知
要提供分布式，松耦合的应用程序的性能的最好的方法是缓存数据。通过缓存少量的更改并为一个远程服务提供者或消费者简单的刷新数据，消息可以更小并利用更少的带宽。
这样的系统需要一种在数据源更改时刷新数据的方法。当然，有很多实现方法。从编程角度来开，最简单的方法是设定缓存定时的失效，无论是一分钟还是几个星期，这决定于数据的类型。但是这种架构只是近似，并可能会很频繁的刷新数据以至于数据没有必要的在网络上传送，也可能刷新不够频繁以至于数据变得陈旧。在很多情况下，最有效的方法是通知每个缓存的维护者，数据已经改变，并从源数据库或服务程序中取出数据。一个服务程序可以使用它的逻辑并选择忽略通知，例如，如果它决定数据不需要刷新或刷新在非高峰的事端进行。
下面是一个查询通知的常规的工作流：
1. 一个服务员用程序提交一个SQL查询到数据库服务器中，并包含一个特别的注释，指明当数据查询改变时服务将请求通知。
2. SQL Server生成一个预约请求，并为该查询记录。然后它创建一个最优的查询计划并执行。
3. 查询结果返回给客户端，并发送给客户端管理的缓存。
4. 数据库监视任何可能对数据做出的改变。当它发现了这样的一个改变，它会生成一个改变通知并发送这个通知到一个队列中。
5. 通知被处理并发送到客户端服务应用程序。
图 5：查询通知的工作流
无论对底层的数据做出多少更改，客户端的应用程序都会接到一个查询通知。为了能够接收其它改变数据的通知，客户端应用程序必须再次查询数据库，并再次包含通知请求的注释。这将在执行刷新数据缓存的查询时完成。
服务逻辑宿主：SQLCLR
到目前为止所讨论过的功能为SQL Server 2005提供了重要的基础结构，并在SOA应用程序中成为一个参与者。剩下的重要的成分是逻辑―运行高级别的代码的能力，并控制系统的所有方面，处理输入，并在环境中对不断变化的条件做出响应。SQL Server长期地包含T-SQL，一种基于集的结构化查询语言的扩展，同样还包含其它扩展，如扩展的存储过程和调用外部应用程序的能力，比如用sp_OA系统存储过程调用COM组件。
但是作为一个可用的服务提供者，它必须可以运行集成的，高级的，性能优良的代码，并有能力将复杂的抽象的业务逻辑具体化。T-SQL对于操控数据来说很方便，但是它不适合完成业务逻辑。Microsoft .NET和.NET兼容的语言提供了所需要的编程平台和语法。.NET Framework 2.0拥有一个寄宿在CLR中的 API，使开发人员可以在宿主进程中执行CLR应用程序，比如在SQL Server 2005种。您可以用SQL Server的这种SQLCLR的特性来写.NET Framework代码，使它在SQL Server进程中运行，接近数据和其它SODA的特性，并且与数据库的安全集成。代码的程序集存储在数据库中，并从中直接加载，而不是存储在文件系统中。这提高了性能并减少了管理复杂度。
您可以使用SQLCLR写函数来代替扩展的存储过程，以及用户定义函数。对于很多传统的应用程序，它在数据库中还有很多其它的用处（虽然它没有代替所有的T-SQL应用程序）。在一个基于SODA的应用程序中，寄宿CLR提供了一个代码的执行环境，它支持多种编程语言，垃圾回收，内存管理，资源池，系统资源管理和代码访问安全。
图 6 显示了SQLCLR怎样在一个普通的操作系统进程中，集成现有的系统和扩展存储过程。主SQL Server进程和CLR一起工作，控制全局的进程资源，比如内存和线程等。
图 6: SQLCLR宿主层
SQLCLR的集成从根本上改变和扩展了SQL Server中的编程模型。它允许自定义类型，自定义聚合，触发器，用户定义函数，逻辑密集型存储过程，和其它代码对象的开发，它克服了基于SQL的语言和执行引擎的限制。在一个面向服务体系结构中，服务程序需要这种技巧。您可以将部分或所有的逻辑代码都放到数据库中，而不是开发和部署一个单独的应用程序组件在数据库外面处理逻辑。对于传统的3层或n层应用程序，数据处理的代码和业务逻辑代码之间的界限变得更加的模糊。
SQLCLR的功能集合可以用来扩展SQL语言可用的SQL函数和聚合库。存在可用的接口，可以实现用户定义函数，标志函数，和用户定义聚合。只要安装后，这些函数就对任意一个用户查询都可用。因为CLR函数被编译为中间语言（IL）最终编译为本机指令，所以这种函数可以比用T-SQL写的同样的函数执行更快，因为那种T-SQL函数是在运行时解释执行的，而没有提前编译。在许多现实场景中，如果用SQLCLR来写T-SQL函数和表值函数，应用程序的速度会增加10倍或更多。
SQLCLR也提供了一个SQLClient数据访问库，它可以在关系型引擎中运行。当SQLCLR数据访问代码在SQL Server进程中执行时，如图 6所示，延迟以及连接远程数据库并获得数据所需要的事务开销得到了巨大的节省。处理来自外部服务器的服务请求所需的数据，不需要经过网络或从服务器架上的旁边一台服务器传递。另一方面，SQLCLR代码和数据库中的其它函数争用服务器进程资源。在为特定的应用程序设计架构时，要充分的仔细。
SODA 计算的拓扑结构
在一个数据库中绑定SOA将呈现出很有趣的拓扑结构，因为SQL Server通过SQL Server进程中寄宿的逻辑或其它网络资源，把一个简单的膝上型电脑划分为企业级别的服务器。例如，SQL Server 2005支持非连接场景，其中数据被缓存到一台笔记本中用来在离线时使用，并在连线时刷新数据。最好的，划分一个SOA应用程序不需要改变服务契约，一个松耦合的SOA应用程序并不关心一个特定的组件怎么或在哪里实现的它的逻辑。
例如，图7显示了一个服务程序，它完全包含在一个SQL Server进程中，并通过一个native Web Service来接收和发送消息。这个场景会减少应用程序逻辑和数据之间的延迟，但会耗费服务器的资源，而这些资源可能会用最其它的数据库工作中。
图 7： 典型的SODA服务进程
在这里不需要服务程序寄宿在SQL Server进程中。取而代之的是，它可以在同一台机器的另一个进程中执行，或完全在另一台机器中执行，如图 8。这样就支持将服务逻辑划分开来，同时数据库引擎控制消息处理，进而控制服务请求和响应，以及日常的数据库引擎功能。
图 8： 划分服务进程
当应用于高度划分的应用程序时，Service Broker体系结构允许复杂的服务路由器监管分散的服务之间的对话。这会利用SOA应用程序的路由功能，如图 9。
图 9： 用Service Router来划分服务
SOA支持非常灵活的拓扑结构，并且SODA建立与这些功能之上。即使在SQL Server 2005中只有一个单独的服务程序，也同样允许适当的划分和拓扑结构。
小节
面向服务数据库体系结构允许SQL Server在基于松耦合的面向服务体系结构的应用程序的开发中扮演重要的角色。SQL Server 2005包括Web Service访问，数据库更改提示，事务中间件，和继承SQLCLR特性，因为这些特性在一个SOA应用程序中是实现服务程序的一个有效的方法。其它的数据库集成了这些特性。但是，直接在数据库引擎中包含它们，利用了SQL Server固有的能力，来管理数据并支持多种划分方法和计算拓扑结构。所有文中提到的特性都可以独立的使用。但是，当在一个服务程序中一起使用时，它们会形成一个协作的平台，能够用来创建独立的自治的服务组件。
SODA为传统应用程序服务器和新型的以服务为中心的应用程序提供了选择。
版权说明
这是一份初版文件，可能会于本软件产品正式发行之前依实况进行必要的修订。
本文件中所包含的信息代表 Microsoft Corporation 于发行日前针对该问题的观点。由于 Microsoft 必须反应市场条件的变更，因此不应解释为 Microsoft 的承诺。在发行日之后，Microsoft 不保证文件中任何信息的正确性。
此白皮书仅供参考使用。MICROSOFT 对于本文件中各项信息，不作任何明示、暗示或法定的保证。
使用者必须遵守所有适用的版权法律规定。在不影响版权各项权利的情况下，若无 Microsoft Corporation 的明确书面许可，本文件中的任何部份均不得因任何目的，以各种可能的形式或方式 (电子、机械、影印、录制或其它方式) 进行复制、储存或导入至检索系统或传送。
本文件中可能述及 Microsoft 的专利、专利应用程序、商标、版权或其它智能财产权。除非取得 Microsoft 明确书面授权声明，否则本文件并未授予这些专利、商标、版权或其它智能财产的授权。
除非另有说明，本文档中用作示例的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件均是虚构的，并不是有意或者不应推断为与任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件有关联。
2005 Microsoft Corporation。保留所有权利。
Microsoft、Visual Basic、Visual C#、Windows、和 Windows Server是 Microsoft Corporation 在美国和/或其它国家/地区的注册商标或商标。
本文档中提到的真实公司和产品的名称均是各自所有者的商标。
|
最全面的资料《SQL Server数据管理》 |
|
| 诚征版主 | 版主堂 | 意见建议 | 大史记 | 论坛地图