以最少的精力高效公开您的数据

• 下载源代码 - 101 KB

引言

对于经营了几十年的企业来说，应用程序和数据的孤岛问题是一个常见问题。当企业开始一项新的战略性举措来改造其 IT 组合、推出新的业务模式和探索新的商业机会时，这些问题有时会成为阻碍。

本文将讨论数据孤岛统一的可能选项，以及企业如何通过利用技术的最新进展，以最小的努力高效地公开其数据。

老牌企业中的场景

在经营了几十年的企业中，常见的关键场景有：

• 数据孤岛分布在多个中间 RDBMS 系统和主 mainframe、AS400 等遗留数据源中。
• 数据在多个应用程序/数据源中重复，因此需要大量的同步批处理作业。
• 由于无法实时获取数据，应用程序中会出现业务异常。
• 不同的应用程序采用不同的路径来访问相同的数据，因此在多个地方嵌入了相同的验证逻辑/业务规则——业务规则重复。
• 由于兼并和收购事件而产生的数据存储在专有数据库/目录中。
• 运行在异构平台上的应用程序通过专有协议从不同类型的数据源中消耗数据。

上述场景并非全部，仅为举例。这些场景成为企业为保持竞争力而启动的任何新举措的制约因素。

通常采用的解决方案是统一数据孤岛，并将单体应用程序拆分成服务以消除重复的业务规则和逻辑。在某些情况下，企业将采取迭代式旅程，允许新举措产生的应用程序与现有应用程序并行运行，并进行一些临时安排。即便如此，除非数据孤岛被统一并可供应用程序使用，否则重复数据问题将影响新应用程序的效益。

统一可以在不同级别进行：在数据源级别，或在消费级别。当它发生在数据源级别时，应用程序仍然可以采用自己的方式来消费数据，但所有应用程序都应该连接到同一个源。这种统一方式可能更耗时，并涉及测试、数据迁移等方面的努力。但它将消除同步批处理例程。这应该是任何企业的长期目标。

在消费级别进行统一的情况下，所有应用程序都必须采用相同的数据消费方式。在这种情况下，将不会涉及数据迁移方面的努力。但所有应用程序都必须进行改造，以采用一种通用的消费风格/模式。

根据“抽象”这一良好理念，在消费级别进行统一是一个不错的选择。它可以作为一项战略举措的起点，目标是在源级别和消费级别都实现统一。这种方式的努力量取决于应用程序的数量。但好处是，它不会鼓励应用程序采用不同的数据访问机制。这种统一方式会产生数据外观，称为“数据服务”。

数据服务

数据服务可以被视为企业服务分类法中的一个类别。它们也称为“实体服务”。这些服务的动态会根据其使用时的上下文而变化。在用于插入/删除/更新操作的场景中，数据服务外观负责执行任何验证/业务规则执行。在消费者仅将它们用于“查找”数据或以只读模式使用时，它们除了执行初始安全检查（仅身份验证）外，没有其他职责。

数据服务可以以不同的格式/模式提供：SOAP 服务（操作）、RESTful 服务（资源）。这里，我用“模式”来指代操作和资源。决定格式和模式的因素是上下文 [只读数据访问、用于 IDU（插入、删除和更新操作）的数据访问]，以及客户的类型（我们将在下一节详细介绍）。

在涉及大量 IDU（插入、删除和更新）操作的场景中，由于验证逻辑将作为数据服务的一部分，因此不会像“数据源统一”级别那样出现重复。因此，维护相对容易。当在数据源级别进行统一时，尤其是在数据源同时存在于 MS SQL Server、Oracle 等 RDBMS 和 mainframe 等遗留系统的情况下，应用程序将负责数据/规则验证。应用程序数量越多，重复和维护就越令人头疼。

对于“只读数据访问”情况，暴露数据为 RESTful 服务可能是最佳选择，因为它具有以下主要优点：

• 轻量级 - RESTful 服务生成简单、纯粹的 XML 输出，比 SOAP Web 服务的 XML 输出更轻量。对于 Web 服务，生成的 XML 输出由于包含大量元数据信息而显得笨重。
• 灵活性 - 它提供了生成不同数据格式输出的灵活性：XML 和 JSON。JSON 比纯粹的 XML 更轻量。

此外，REST 还有许多其他优点。在此详细介绍超出了本文的范围。

对于“用于 IDU 操作的数据访问”上下文，SOAP Web 服务将是最佳选择。如果我们采用 REST 风格，则无法利用高级 Web 服务标准（WS-*，即 **WS-Security、WS-ReliableMessaging、WS-Addressing、WS-Coordination** 等）的优势，例如参与事务、可靠消息传递、消息级加密等。

数据服务消费者

数据服务消费者可大致分为：

• 可以消费 SOAP/RPC Web 服务的消费者（典型的 .NET 客户端应用程序）

这包括典型的 Web 应用程序、桌面应用程序和企业应用程序（ERP、CRM 等）。

• 需要依赖 AJAX 实现响应能力的消费者（AJAX 应用程序）

此类应用程序使用 XMLHTTP 发出请求，并完全依赖浏览器的 JavaScript 功能来执行逻辑（如 ASP.NET AJAX）。

• RIA 消费者

这些是基于浏览器插件的应用程序，可提供丰富的用户体验。它们可以消费 SOAP Web 服务以及 REST 风格的服务，但主要限于异步模式。Silverlight 是一个有助于构建 RIA 的浏览器插件。

根据客户端的类型，数据服务需要以特定的格式提供。对于可以消费 XML 和 SOAP 的客户端，可以将其提供为 Web 服务。在这种情况下，客户端应用程序通过针对 Web 服务元数据在相应平台上生成的代理对象与 Web 服务进行通信。这通常是许多企业采用的方式。

但对于需要响应式 UI 的客户端，它们必须依赖 AJAX。在这种情况下，Web 服务不是一个合适的解决方案。对于 AJAX 客户端，合适的解决方案是通过 JavaScript 代理对象从 RESTful URL 消费数据。即使对于 RIA，特别是数据消费，REST 风格的服务也比 SOAP Web 服务更受青睐。

如今，即使是能够消费 Web 服务的应用程序，也因为 RESTful URL 相较于 SOAP-RPC 的优势而转向使用它们。

RESTful 数据

SOAP/RPC 和 RESTful 的根本区别在于，在基于 SOAP 的 Web 服务中，数据被公开为“操作”，而在 REST 的情况下，数据被公开为“资源”。当数据实体被公开为资源时，消费者可以自由地以自己想要的方式查询它们，而不是受限于操作签名。

在 Web 客户端和服务器端服务终结点之间的通信中，需要一种序列化格式来将平台特定的类型转换为 HTTP 网络数据包。对于 RESTful 服务，可用的格式是 XML 和 JSON。几十年来，XML 一直是唯一的选择。在过去的几年里，JSON 因其简单和轻量级而逐渐成为浏览器和服务器之间通信的数据格式选择。

对于一般的 Web 浏览器客户端，当它们向 Web 服务终结点发出请求时，它们将收到 XML 格式的响应。浏览器负责解析和处理 XML 数据。由于浏览器自带默认的 XML 解析器，这里没有问题。但是，在某些 AJAX 应用程序中，实际请求的发起者是 JavaScript。在这种情况下，当 JavaScript 收到 XML 响应时，解析和处理 XML 存在问题，因为没有基于 JavaScript 的 XML 解析器。这也是 JSON 成为序列化格式选择（尤其是在 AJAX 应用程序和基于脚本的请求中）的关键原因之一。如今的浏览器自带默认的 JSON 反序列化器。

使用 RESTful 服务，我们可以选择以 XML 和 JSON 两种格式公开我们的实体，以便覆盖更广泛的客户端。

在了解了 REST 的重要性和优势之后，现在是时候看看如何以最小的努力通过 RESTful URL 公开我们的实体了。下图描绘了 ADO.NET Data Services 在不同消费者场景中的应用。

如何 REST 化？

有多种选项可用于将我们的数据/实体公开为 RESTful URI/服务。通用方法是开发 WCF 服务并进行一些变通使其可作为 RESTful URI 使用。在这里，我们需要开发数据访问层、业务组件层，然后是服务层。随着“WCF REST Starter Kit”的发布，这项工作变得更容易一些。但是，出于安全、抽象、可维护性等原因，我们仍然需要坚持不同的层次。

当我们想要公开业务逻辑或流程时，坚持这些分层原则并将其公开为操作是有说服力的。但是，当我们只需要将数据/实体提供给各种客户端使用，或者当我们只需要允许外部客户端对企业数据进行查找时，更好的选择是采用一个框架，该框架可以让我们毫不费力地将实体/数据公开为 RESTful URL。其中一个这样的框架是微软提供的“ADO.NET Data Services”。

ADO.NET Data Services 允许我们通过网络公开数据，它利用 Microsoft Windows Communication Foundation 创建 REST 风格服务的能力，以及 Microsoft LINQ 查询数据源（如实体对象，如 MS ADO.NET Entity Framework）的能力。

ADO.NET Data Services 允许我们以 RESTful 的方式（即通过 RESTful URI）毫不费力地公开我们的实体/数据。它提供 XML Atom 和 JSON 两种格式来公开数据。它根据请求的“Accept”HTTP 标头将数据序列化为 Atom 或 JSON。

我将引导您完成只需点击几下即可公开数据的步骤。

在此练习中，我在 MS SQL Server Express 2008 中创建了两个表。

1. tblEmp - 存储员工的基本详细信息。
2. tblCompDtls - 存储员工的薪酬详细信息。

[我在上面的下载文件中附带了创建这些表和插入数据的脚本。]

第 1 步：在 MS Visual Studio 2008 中创建一个新的 ASP.NET Web 应用程序 [专业版即可]。

第 2 步：通过 **工具** > **连接到数据库** 菜单选项，向新的 ASP.NET Web 应用程序项目添加数据库连接。此连接应指向您创建这些表的数据库。

第 3 步：现在，在 ASP.NET Web 应用程序项目的 **添加 > 新项** 菜单选项中，添加一个新的“ADO.NET Entity Data Model”项目项。它可以在“数据”部分找到。将其命名为“EmployeeModel”。

点击“添加”将进入下一个屏幕。

选择“从数据库生成”选项，如上图所示。然后，点击“下一步”。您将看到如下屏幕。将实体名称指定为“EmployeeEntity”。

现在点击“下一步”按钮。

下一个屏幕将显示数据库中的对象。选择“tblCompDtls”和“tblEmp”表。将模型名称键入为“EmployeeModel”。这里，tblEmp 代表实体“Employee”。点击“完成”按钮。现在，将生成实体模型。

上图显示了生成的模型。

创建实体模型后，现在就可以以“RESTful”方式公开您的数据了。

第 4 步：现在，在 ASP.NET Web 应用程序项目的 **添加 > 新项** 菜单选项中，添加一个新的“ADO.NET Data Services”项目项。它可以在“Web”部分找到。

将其命名为“EmployeeDataService”。请注意，其扩展名为“.svc”。这是否让您联想到什么？是的，它与表示 WCF 服务的扩展名相同。ADO.NET Data Services 框架完全依赖于 WCF 模型。点击“添加”按钮。

现在，Visual Studio 将为您生成数据服务代码隐藏文件 [EmployeeDataService.svc.cs]。将以下代码部分从

public class EmployeeDataService : 
   DataService< /* TODO: put your data source class name here */ >

to

public class EmployeeDataService : DataService<EmployeeEntity>

另外，请取消注释以下代码部分：

config.SetEntitySetAccessRule("MyEntityset", EntitySetRights.AllRead);
config.SetServiceOperationAccessRule("MyServiceOperation", ServiceOperationRights.All);

别忘了将此代码部分修改为 [将“MyEntityset”和“MyServiceOperation”替换为“*”]

config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
config.SetServiceOperationAccessRule("*", ServiceOperationRights.All);

否则，在运行项目时，您将遇到错误“服务器在处理请求时遇到错误。请参阅服务器日志了解更多详细信息。”

现在按 F5。您将看到浏览器窗口如下：

它显示了所有选定的表（实体）。要仅查看员工实体，请将 URL 更改为 https://:62800/EmployeeDataService.svc/tblEmp。它将列出员工。[请检查您系统中的确切端口号。]

如果您将此服务托管在 IIS 中，则无需担心端口地址，就可以像 https:///DataServicesDemo/EmployeeDataService.svc/tblEmp 一样访问它。

因此，我们现在成功地以 RESTful 方式公开了数据，而无需付出太多努力。ADO.NET Data Services 的默认格式是 XML Atom。我们也可以让它以 JSON 格式输出。

让我们使用一个名为“fiddler2”的小工具来执行此操作，这是一个来自微软的优秀工具，用于检查客户端和服务器之间的 HTTP 流量。有关此工具的下载、安装和使用的更多详细信息，请访问 http://www.fiddler2.com/fiddler2/。

在 Fiddler 中，点击“请求生成器”按钮。在 URL 文本框中键入 URL https:///DataServicesDemo/EmployeeDataService.svc/tblEmp。选择“GET”作为选项。让“HTTP/1.1”作为请求类型。现在，点击“执行”按钮。

从左侧窗格中，点击请求链接。在右上方和下方窗格中分别选择“原始”和“文本视图”选项，您可以看到 HTTP 请求的详细信息以及响应。上图显示了默认响应（XML-Atom）。通过切换回“请求生成器”视图并添加以下行，可以使服务以 JSON 格式输出：

Content-Type: application/json
Accept: application/json

生成的请求头信息将如下所示：

GET /NorthwindDataService/Northwind.svc/ HTTP/1.1
User-Agent: Fiddler
Host: localhost
Content-Type: application/json
Accept: application/json

现在，点击“执行”按钮。现在，服务将返回一个 JSON 输出，如下图所示：

正如我之前提到的，JSON 比 Atom 格式更轻量。我将两个输出分别导出到两个单独的记事本文件中并保存它们 [您可以通过点击“在记事本中查看”按钮来执行此操作]。生成的文件的尺寸是：

• XML - Atom 输出 - 10 KB
• JSON 输出 - 4 KB

如您所见，XML 输出比 JSON 重约 50%！

结论

在每个企业中，都有一个共同的需求，即以服务的方式公开数据/实体。特别是随着 Web 2.0/RIA/AJAX 应用程序的增长，迫切需要以 RESTful URI 和 JSON、Atom 等多种格式公开我们的数据。利用 ADO.NET Data Services 将使我们能够更轻松地以各种格式为更广泛的应用程序公开数据。以 JSON 格式公开数据可以提高性能，因为响应负载减小，从而最大限度地减少对网络带宽和其他资源的影响。