如今，大多数医疗保健公司都在努力寻找方法来改善患者护理，降低成本并提供更多更好的服务。他们越来越将技术视为满足这些要求的解决方案。我们公司也不例外。我们在 13 个州和 40 个办事处拥有约 1,300 名员工。我们现有的病患护理系统和财务会计系统是在十多年前开发的，并非旨在处理大型分布式组织的需求。

我们执行团队的许多成员都具有大量索赔处理的背景，在这种处理中，每天必须在高可用性系统上处理数百万份索赔。我们的首席执行官和执行团队为我们的新 IT 应用定义了以下要求

可扩展性是生存的关键。许多供应商都说过，“硬件很便宜，只需投入更多硬件即可。” 在您负责预算并将其交给首席财务官 (CFO) 之前，这都是一个不错的解决方案。在我们的情况下，我们绝不能为了臃肿、低效的应用程序和系统而牺牲一字节内存、一个处理器周期或一个磁盘块。

可移植性和可扩展性是相关的。如果我们的应用程序是在 Intel 平台上编写的，但必须在大型机上运行才能按需执行，则该应用程序必须可移植到在不同硬件上运行的不同操作系统。我们今天的硬件选择可能会根据速度、成本、支持、可靠性和运行系统的人才可用性而在一年后发生变化。我们不能在每次更换硬件时都更换我们的应用程序。

HIPAA 由美国国会通过并于 2000 年签署成为法律，对医疗保健公司产生了巨大的影响。这些法律将于 2002 年生效。HIPAA 的作者旨在标准化索赔的处理方式、公司之间的数据交换方式以及患者信息的访问和存储方式。我们运行的应用程序和系统必须符合 HIPAA 要求，并且必须随着监管环境的变化而变化。据行业分析师称，医疗保健公司在 HIPAA 合规性方面的支出将是 Y2K 成本的两到三倍。

行业分析师还声称，医疗保健是最后一个充分利用信息技术进步的行业之一。许多医疗保健公司的信息系统都在旧的，有时是非常旧的技术上运行，我们的系统必须与之通信。当我们将患者注册到我们的医疗信息系统时，我们必须自动将该患者注册到我们的药房供应商的系统，以便患者可以在美国的任何地方当天填写他们的处方。我们还必须向我们的医疗用品公司发送信息，以便患者可以获得医疗用品而不会过度延迟。

我们公司评估了 50 多个医疗保健应用程序。没有一个能够满足我们的需求。一些公司刚刚投入数百万美元从 DOS 应用程序转向客户端/服务器、32 位 Windows 应用程序。有些公司有 DOS 应用程序，当我们试图解释我们想要什么时，他们只是觉得我们很奇怪。最终，我们发现没有任何东西能满足我们的需求。我们的解决方案是组建一支在大量事务处理方面具有丰富经验的开发人员团队，并构建一个事务骨干网以及在其上运行的应用程序。

我们的首要任务是定义架构的概括轮廓。我们想要一个 N 层架构，但除此之外，我们还想要一个对可能的解决方案没有限制的架构。我们评估了几个事务引擎和应用服务器。所有这些都未能满足我们的要求。商业事务引擎要么购买、维护和开发成本极其昂贵，要么对我们来说过于不灵活或不可靠。

我们需要多少可靠性？如果一家电子零售商停机 0.1% 的时间，即每年约九个小时，最坏的结果可能是损失一些订单。但是，当护士需要访问患者记录以了解患者的药物和剂量时，停机时间就是一个不同的问题。这是完全不可接受的。

构建还是购买的决定很容易，因为没有什么可买的。我们选择构建一个功能强大的事务引擎——eTransMan。eTransMan，电子商务事务管理器，是结果（见图 1）。

图 1. 架构概览

eTransMan 是易于使用的架构的核心，该架构提供了一个环境，开发人员可以在其中轻松地为医疗保健的普适计算环境构建和管理 N 层应用程序。开发人员使用任何计算机语言（C、C++、Java、COBOL、Perl、Visual Basic 甚至汇编语言）将他们的业务流程编写为模块化组件。eTransMan 在高度可扩展、可移植、高性能、安全的事务环境中运行这些组件。

为 eTransMan 开发组件在设计上很简单。我们公司的开发人员用 C++ 和 Java 编写业务组件。其他公司可能没有具备这些技能的开发人员。他们可能只有 COBOL、Visual Basic 或 PowerBuilder 开发人员。借助 eTransMan，公司可以避免花费时间和金钱参加为期一周的课程来学习如何使用事务引擎，然后再参加为期一周的 Java 或 C++ 培训。

事务管理器是 eTransMan 的架构中心。事务管理器提供容错、负载均衡、调度、安全和业务组件定位（路由）。

eTransMan 的架构基于经典的 N 层模型，并进行了一些增强。此模型分离了表示层、业务逻辑层和数据访问层。此架构的主要目标是

事务管理器是用 C/C++ 在 Linux 上编写的，并使用开源 gcc 编译器编译。因此，我们可以轻松移植到任何支持 gcc 的系统，从嵌入式平台到 IBM 390 大型机。由于在此平台上提供的有效工程设计，eTransMan 超出了性能预期。我们目前在两台双 PIII 700 服务器上运行 eTransMan。为 40 个站点服务 450 个在线用户的总生产硬件成本低于 30,000 美元（见图 2）。资源仅在需要时分配，从而可以在我们适度的硬件上实现快速响应。负载平均值永远不会超过 2%。eTransMan 是一个编译后的应用程序，因此它无需解释器即可运行。

图 2. 附加文件服务器

eTransMan 包含许多支持高应用程序可用性的功能：可用性检查处理、超时检查、自动组件重启和恢复程序以及用户可定义的恢复程序。业务组件作为守护进程运行，可从 Apache Web 服务器获得极快的响应。eTransMan 不仅控制应用程序中的活动流程，还确保所有组件平稳高效地运行（见图 3）。

图 3. 管理活动流程

eTransMan 平衡多个相同组件之间的负载，以确保最大应用程序吞吐量。eTransMan 跟踪哪些组件可用于特定事务。它动态创建额外的组件实例以处理增加的事务需求，并在不再需要时销毁它们。此功能使 eTransMan 能够最佳地分配资源以满足当前需求。使用 Linux 的开放架构，eTransMan 可以动态地将请求映射到组件，从而对应用程序的处理流程进行广泛的控制。

通过多路复用和管理客户端与应用程序之间的关系，eTransMan 提供了任务和业务关键型应用程序所需的所有功能，包括集中式或分布式大容量数据的容量、高消息吞吐量、高数据完整性和安全性以及高应用程序可用性，包括 24/7 处理。

资源根据配置文件指定使用，但仅在必要时使用，从而可以在适度的硬件上实现快速响应。我们构建了一个 Web 界面来管理我们的配置文件。eTransMan 架构遵循 N 层模型。工作流程如下：

当事务管理器收到来自组件的响应时，它会将响应转发到发送请求的通信层。然后，通信层将结果转换为数据客户端可识别的格式。然后，数据以其本机格式发送回客户端。

我们需要尽可能轻松地更改用户界面。第一个测试发生在我们想要将现有的基于 PC 的浏览器界面适配到无线 Palm Pilot 和手机时。我们希望允许我们的现场人员使用非常简单的工具（手机）来访问数据库。我们的第一个挑战是在支持浏览器的手机或无线 Palm Pilot 上向患者家中发送行车路线。通过使用我们的转换器技术，我们能够采用现有的基于 Web 的应用程序（在本例中是一个包含 150 列数据的报告），并使用新模板将其适配到无线世界。我们在不到四个小时的时间内移植到了 WML 界面，而无需重新编码业务组件或数据库组件（见图 4）。我们使用 Web 剪报技术在 Palm VIIX 上重现了这一壮举。花了四个小时是因为我们不熟悉 WML 或 Web 剪报。Yankee Group 表示，医疗行业无线技术的潜在用户多达 1200 万。Web 是我们今天的工具，但我们很快将见证无线界面的爆发式增长。如果我们的架构需要重新编码业务组件，那将是目光短浅的（见图 5）。

图 4. 无线行车路线

图 5. 病患表格

接口和转换器是通信层的一部分，它们为业务组件打包数据。接口和转换器还格式化发送回原始客户端源的数据。作为格式化数据的一种技术，解释器可以使用模板；例如，HTML 模板可以表示经典的主从报告。

接口和转换器使开发人员能够专注于业务逻辑，而不会因数据的格式化或表示方式而分心。这些转换器可以使用来自业务组件的公共数据流，并将其移动到几乎任何前端：Web、IVR、无线甚至打印流。

更重要的是，如果数据客户端发生更改，这允许重用组件。将表示和通信逻辑与业务逻辑分离可以加快软件开发速度，并允许更快的应用程序部署和更新。它还使开发人员，特别是 Web 和图形程序员，能够专注于表示，而无需担心业务逻辑或数据库 I/O。

eTransMan 使用组件软件模型。数据客户端和其他请求者调用受管理的业务组件，开发人员通过专注于业务流程来设计业务组件或修改其组件。这种开发策略使开发人员能够利用他们现有的知识和技能快速构建组件。

我们需要能够更改单个业务组件的可用性，而不会影响任何其他组件。我们发现，在我们调查的许多商业和开源事务平台中都缺少此功能。

医疗保健的计算环境需要管理警惕性。性能和安全监控、故障和警报管理以及许多其他操作任务在分布式环境中更加困难。我们还设计了基于 Web 的管理功能，以使电子商务应用程序上线和下线。解决此问题的最简单方法是使用接口和转换层通过 Web 进行管理。我们使用 eTransMan 来管理 eTransMan（见图 6）。

图 6. etransman_manage

eTransMan 的数据库抽象层为数据库交互提供了通用接口。此层使开发人员无需修改业务组件代码即可与任何数据库进行交互。

数据抽象层的优势在于，如果底层数据源发生更改，例如从 IBM 大型机上运行的 DB2 更改为 Linux 上运行的 Oracle，业务组件无需注意。组件程序员的逻辑无需依赖于特定数据库的细节。例如，组件中没有 SQL 或 HLLAPI 操作例程。所有数据源访问都通过特定的组件进行，该组件将通用请求转换为特定数据源的格式。

与某些使用 JDBC 或 ODBC 与数据库交互的事务平台不同，eTransMan 可以利用数据库的本地库进行数据库交互。这种工程设计以最小的开销实现了快速数据库访问。

元数据层由组件在实例化时存储和读取，控制从组件到数据库的数据访问过程的调用。这使每个软件层都能发挥其最佳作用：数据库读取和写入数据，应用程序程序运行业务逻辑。这种分层抽象已经使我们能够将在一个 RDBMS 中开发的应用程序移动到不同的数据层。

数据库连接池是一种最大限度地减少数据库连接数量的技术。数据库连接需要大量使用数据库和系统资源。频繁的连接和断开连接会导致整体性能下降。在高事务环境中，连接池可确保有效利用资源以优化响应时间和数据吞吐量。

如今，许多数据库供应商根据并发用户数、连接数和/或基于数据库运行的每处理器 MHz 的功率单元数量来许可其产品。eTransMan 通过仅使用完成工作绝对必要的系统资源来帮助保持其事务平台的低拥有成本。

如果我们要连接我们典型的每日 200 个在线负载，我们将需要一台装满 RAM 的相当快的机器。但是，我们可以使用五个池化的数据库连接来支持这 200 个用户，从而允许 eTransMan 在需要时预测性地启动更多连接。

我们的系统提供高正常运行时间。通过在冗余的、可重启的小组件中构建所有内容，我们可以为应用程序提供多条路径。如果软件冗余不足，业务组件可以在多台服务器上运行，从而即使在服务器完全故障的情况下也能提供可靠性。eTransMan 将这些组件标记为不可用，并将业务路由到另一台可用服务器。Web 服务器已经以这种方式运行，现在应用程序也可以这样做了。

应用程序需求来来去去。企业会变化、合并、被收购、被出售——没有什么是永恒不变的。我们知道，未来我们将运行与今天使用的业务组件和数据库组件不同的组件。凭借正确的架构，我们也知道我们可以进行从 Web 到无线等迁移，而不会影响业务组件。此过程的主要教训是不要被锁定在供应商、技术、预定义的接口、Web 服务器或数据库中。