794
社区成员
发帖
与我相关
我的任务
分享应用 PbnTierBuilder 实现医院信息系统的三层迁移
我国医院信息系统经过二十多年的发展，目前 40%以上的大中型医院正在建设全院的数 字化管理信息系统，应用系统多样、涉及面广、模块数多、访问频繁，大多采用客户/服务 器模式，维护复杂，而流行多年并已经成熟的分布式
技术、应用服务器技术以及 Web 技术的 应用却很少，如在本院运行的信息系统，应用模块（子系统）已超过一百个，HIS主数据库 服务器连接数数高峰已突破 1000 个。由此可见，一般大型医院在系统应用上必然同样会遇 到：数据库
连接数大，数据访问频繁，系统压力集中；系统间耦合度高，系统扩展困难等各 种问题，而系统若从现在的 C/S 两层架构向分布式多层架构进行迁移升级，则可以解决系统 面临的一系列问题。
1 当前系统面临问题
1.1 系统性能瓶颈突出 本院开发的 HIS 系统，采用传统的 C/S 架构，客户端系统应用直接 连接到数据库系统，一个客户端至少需要占用一个数据库连接，一些大数据量查询被限制在 特定的时段才能使用。这样的状况不仅造成了极大的资
源浪费，而且在大并发下造成数据库 压力过重而不能快速响应和处理业务请求，导致系统系统性能低下。在实际应用中，每天应 用高峰时段系统连接主服务器的用户会话数可超过 1000 个，特别是在周一超大的系统规模 和巨大的访问量
更显系统性能低下，不仅令业务部门不满意，也让计算机中心人员更为紧张 和繁忙。
1.2 业务规则急需重整 目前系统开发中业务规则重用采用如下两种方法：一是数据库的存 储过程或函数，二是在客户端通过 PBL 共享或对象共享。但这两种方法都不是太理想，前者 不仅编写难度比较大，而且会增加数据库的压力，后者
通常不太好控制版本的一致性，而且 造成较大的分发和维护工作量。解决这些问题需要采用中间服务器和分布式应用等多层架构 思想，以降低开发和维护的难度及工作量。
1.3 系统偶合性强，集成难度高 目前大中型医院的医院信息化建设已从面向管理服务到面 向临床服务转变，开始了建设全面的数字化医院。系统应用面广、深入，模块日益增多，迫 切需要解决系统的大集成。由于医院信息系统的主体系
统自行开发，在与其他系统（包括引 进系统）集成时直接采用点对点的集成结构，系统间的偶合性很强，同时随着系统的发展， 不仅需要流程管理、营销渠道、外部服务等角度进行整合[1]，而且可能需要从数据、应用接 口、界面三个层
面上去实现集成，直接导致了集成的难度和复杂性，需要寻求适合自己的更 为先进的集成方式，如基于 SOA 和柔性流程的医院信息系统集成，来构造/升级整个医院的
[5] 信息系统 。
1.4 C/S 架构制约系统应用发展 传统 C/S 两层架构的应用系统，适合中小规模的局域网大 数据量的业务系统，技术成熟、稳定，目前仍在大量使用，然而，两层系统架构在大并发、 互连网部署、系统部署和维护等方面的局限必然会制约
系统横向更广，纵向更深的发展。
目前，我院 HIS 系统主体是采用 PB+Oracle 开发的传统 C/S 架构，随着同济医院的发展， 信息系统应用规模将越发庞大，按目前的访问方式预计高峰时间连接数将来有可能突破 2000 个，系统应用需求将进入跨区域的互连互通，
并且需要对外提供 Internet 信息发布及 服务等多样化应用的阶段，因此，目前的系统架构已经制约了系统进一步发展,有必要进行 系统架构的迁移升级。
2 PB C/S 系统迁移方案比较分析
多层架构的提出正是为解决了两层架构面临的各种问题，通常所指的“多层”主要为分 布式系统和 B/S（Browse/Server）系统。在同济医院信息系统的进行迁移升级的三层架构 是指多层分布式系统架构，同时基于目前医院 HIS 系
统开发的工具和具体应用情况，有如下 几种迁移方案可共选择。
2.1 用 J2EE/.NET 重新开发成 B/S 架构 放弃 PB，采用 Java/.NET 重写系统模块，改写 成 B/S 架构WebForm。虽然此迁移方案可按照最新的架构设计、可采用最新的技术实现；B/S 架构 WebForm 可让客户端维护工作降到最少等
优点，但也存在几个关键的问题：迁移周期长、 成本高昂。按目前医院系统应用规模，重新采用 J2EE 或.NET 开发、完善，不仅耗时，而且由于采用新的技术架构，旧有的技术投资和人员结构也得不到有效的保护和延续；响应速度 较低
、用户体验差、接受度低。B/S系统虽然可以减轻很多实施和维护的工作量，但并非都 适合 OLTP 业务系统。到目前为止，B/S系统的 Web Form 界面还很难达到传统的 Windows Form 界面的友好性和易操作性，而且响应速度相对要
低。
2.2 用 Appeon 迁移成 B/S 架构 采用Appeon 来迁移PB 系统，虽然自动化程度较高，大 部分简单的程序可自动转换等优点，但 Appeon 迁移系统，同样存在几个关键的问题：产品 发行成本高。Appeon 迁移的成本并不太高，但由
于迁移后的产品严重依耐 Appeon的运行环 境，这大大增加了产品的发行成本和发行难度，因此，Appeon适合迁移项目型系统（专案）， 而不太适合迁移商业产品；存在安全性隐患。Appeon 采用的是 OCX 方式来实现本地资源的 调
用和界面显示,一方面很多情况下 OCX 常会被浏览器阻止，另外，也存在被利用和攻击的 可能；Appeon 只是简单的把 C/S 程序“翻译”成 B/S 程序，并未进行组件化封装和业务逻 辑重组等工作，要进行这些工作，您需要自行进行规
划和开发。
2.3 用 PBnTierBuilder 迁移成多层架构[2] 采用 PbnTierBuilder 迁移 PB 系统，优点很 明显：与 PB 完美搭档，可持续发展。充分利用了现有技术人员资源，实现平稳技术升级， 保证了系统的平稳迁移；迁移升级简单。只需要在对
原来的系统进行简单的“翻译”（对 Datawindow、嵌入式 SQ进行改写），即可实现一次代码迁移改写，满足多种技术架构（分布 式多层 IIOP和 HTTP、.NET SmartClientWinForm、ASP.NET WebForm 等）的发布，而且可以 支持
多种数据库系统；基于 SOA 的参数化构件设计思想，便于系统间集成和管理维护；采用 高效数据压缩(最高 20 倍压缩比)等技术，互联网环境运行速度快。采用 PbnTierBuilder 迁移后的系统，在互联网上运行具有很好的性能、而且系统
发行成本低。这种方案和 Appeon 比较自动化程度略低。
从上面几个方案的技术特点，结合医院系统具体情况，我们认为用 PBnTierBuilder 迁 移升级 PB C/S 系统最为合适。
3 PBnTierBuilder 迁移方案
3.1 基于 Sybase EAServer 的多层架构关键技术[3-4] Sybase EAServer 是用来提供高可靠性、 高性能与可管理性的企业级分布式、客户/服务器、Web 应用的解决方案，使现有的应用集 成到 J2EE 环境与面向服务的架构（SOA）中。
其中 Jaguar CTS（组件事务服务器），是 Sybase 新的适应性组件体系结构的中间层的核心产品，它面向的应用类型是多层结构下的企业级客 户/服务器应用和 Web OLTP 应用。
Sybase EAServer 的多层架构有如下几个关键技术：分布式及组件技术，对业务处理层 和界面层进行了分离，业务处理层被抽象成组件，部署在应用服务器上，这样不仅可实现把 数据库、业务处理层、界面层部署到多台电脑上，而
且实现分布式处理，充分利用应用服务 器的强大功能，实现资源共享、负载均衡；数据库连接缓冲池，应用服务器提供数据库连接 缓冲池（Connection Cache）的技术来实现数据库连接的共享，即组件中的数据库连接为逻 辑连接，组
件在需要的时候动态从池中获取一个数据库连接，用完后又释放到池中，大大降 低实际的数据库连接数量，减轻了数据库的压力，提升了系统性能；组件实例缓冲池，客户 端连接到应用服务器，应用服务器采用组件实例缓冲池的技术
（Instance Pooling）实现只在需要执行具体的方法时才从实例缓冲池中取一个组件实例进行绑定，执行完方法后又释放 到缓冲池中；应用服务器集群。通过应用服务器集群来解决并发数和提升性能，和数据库的 集群（如 Oracle 的
RAC 集群）比较起来，具有更好的伸缩性和综合成本。
3.2 PBnTierBuilder 功能构成[2] PBnTierBuilder 是基于 Sybase EAserver 结构，服务于 Sybase 技术和应用开发者之间的桥梁，集服务端组件、客户端扩展(接口)组件、辅助开发 工具的于一体的开发工具。主要有如下几个部分组成：
服务端组件，包括标准数据服务组件、 常用功能组件以及用户自行扩展的组件，可以部署到 Sybase EAServer(5.x/6.x) 或 IIS(5/6/7)+.NET Framework2.0 之上；客户端扩展（接口），包括客户端接口集合，为不同 部署架构提供不同
的适配器集；辅助工具，包括系统数据配置工具、服务端配置工具和辅助 开发工具，实现对系统参数的管理和服务端数据对象的维护。图 1 是 PBnTierBuilder 技术 架构。
3.3 PBnTierBuilder 迁移步骤
3.3.1 搭建 nTier 应用迁移（开发）环境 这包括需安装一台 EAServer5.0 以上版本的应用 服务器，并且按照 PbnTierBuilder 要求进行组件部署，Connection Cache设置等配置。
3.3.2 在客户端程序应用 Target 中包含 PbnTierBuilder 客户端扩展 PBL 基于老的 C/S 程 序上建立一个新的 Target，除需要包含原来的全部 PBL 外，还要包含 PbnTierBuilder的客 户端扩展 PBL(PBD)，这样就可以直接调用
PbnTierBuilder 提供的易于使用、功能强大的数 据操作功能。
3.3.3 构造基本的nTier应用运行环境 nTier不在象传统的C/S程序那样直接访问数据库， 而是透过应用服务器来间接进行访问数据库的，因此需要在迁移的客户端程序中增加连接 Jaguar 服务器，创建远程对象代理等一序列 nTier 运行环
境代码。
3.3.4 迁移标准数据访问代码 针对 Datawindow 和 Datastore 的 Retrieve 和 Update、各 种嵌入式SQL以及DW和SQL混合更新的事务等都可使用PbnTierBuilder提供的标准数据访 问接口实现迁移转换。
3.3.5 编写扩展业务组件及调用 对于少量的特殊数据访问（如：SelectBlob/UpdateBLob） 以及需要进行封装、需要进行共享或需要向外提供服务的业务逻辑或功能，可基于 Pbntierbuilder 提供的扩展模板，自行编写业务组件以及客户
端调用接口。
3.3.6 根据实际需要发布成不同架构 代码迁移完成后，可根据最终系统使用的环境和要求， 发布成不同的技术架构：分布式多层 IIOP 和 HTTP、.NET SmartClientWinForm、ASP.NET WebForm 等。
4 迁移后应用与讨论
本院医院信息系统没进行三层系统的迁移升级前，使用护士站、计价录入系统工作站约 300 台，数据库连接数近 400 个。经过迁移升级后，三层系统目前仅使用 1 台应用服务器 (Sybase EAServer 5.3，单机多实例集群)，IIOP连接峰值不超过 100 个，数据库的连接数仅 10 个左右，系统性能整体得到提升，效果明显。2007 年开始迁移工作，首先完成计价录 入模块的迁移升级，然后完成开始护士站的迁移升级工作。目前迁移重点完成最基本的内容， 而一些共用的业务规则方面还需统一规划后再完成扩展功能服务类组件的对象编写、封装和 调用等迁移工作。同时我们认为在具体实施迁移升级的工作上要注意考虑：代码优化，首先 要从程序结构和运行背景上进行分析，找出合理、高效的执行流程，然后再进行相关的组件 或代码编写，这样才能从根本上解决性能低下的问题；业务功能详细测试并进行错误修正。 由于同济医院业务系统非常关键，nTier 改造后正式上线是不能容许大的问题发生，所以， 在正式上线前，必须在模拟环境进行详细的测试后才能投入正式环境运行。
目前我国军队医院及地方多数医院的医院信息系统是采用PB+Oracle开发的C/S结构的 系统，必然会遇到类似问题。我们相信同济医院目前的迁移升级工作无疑是一种有益尝试， 对其他医院的系统迁移升级工作必然会起到借鉴作用。
3.3 PBnTierBuilder 迁移步骤
3.3.1 搭建 nTier 应用迁移（开发）环境 这包括需安装一台 EAServer5.0 以上版本的应用 服务器，并且按PbnTierBuilder 要求进行组件部署，Connection Cache设置等配置。
3.3.2 在客户端程序应用 Target 中包含 PbnTierBuilder 客户端扩展 PBL 基于老的 C/S 程 序上建立一个新的 Target，除需要包含原来的全部 PBL 外，还要包含 PbnTierBuilder的客 户端扩展 PBL(PBD)，这样就可以直接调用 PbnTierBuilder 提供的易于使用、功能强大的数 据操作功能。
3.3.3 构造基本的nTier应用运行环境 nTier不在象传统的C/S程序那样直接访问数据库， 而是透过应用服务器来间接进行访问数据库的，因此需要在迁移的客户端程序中增加连接 Jaguar 服务器，创建远程对象代理等一序列 nTier 运行环境代码。
3.3.4 迁移标准数据访问代码 针对 Datawindow 和 Datastore 的 Retrieve 和 Update、各 种嵌入式SQL以及DW和SQL混合更新的事务等都可使用PbnTierBuilder提供的标准数据访 问接口实现迁移转换。
3.3.5 编写扩展业务组件及调用 对于少量的特殊数据访问（如：SelectBlob/UpdateBLob）
以及需要进行封装、需要进行共享或需要向外提供服务的业务逻辑或功能，可基于 Pbntierbuilder 提供的扩展模板，自行编写业务组件以及客户端调用接口。
3.3.6 根据实际需要发布成不同架构 代码迁移完成后，可根据最终系统使用的环境和要求， 发布成不同的技术架构：分布式多层 IIOP 和 HTTP、.NET SmartClientWinForm、ASP.NET WebForm 等。
4 迁移后应用与讨论
本院医院信息系统没进行三层系统的迁移升级前，使用护士站、计价录入系统工作站约 300 台，数据库连接数近 400 个。经过迁移升级后，三层系统目前仅使用 1 台应用服务器 Sybase EAServer 5.3，单机多实例集群)，IIOP连接峰值不超过 100 个，数据库的连接数 仅 10 个左右，系统性能整体得到提升，效果明显。2007 年开始迁移工作，首先完成计价录 入模块的迁移升级，然后完成开始护士站的迁移升级工作。目前迁移重点完成最基本的内容， 而一些共用的业务规则方面还需统一规划后再完成扩展功能服务类组件的对象编写、封装和 调用等迁移工作。同时我们认为在具体实施迁移升级的工作上要注意考虑：代码优化，首先 要从程序结构和运行背景上进行分析，找出合理、高效的执行流程，然后再进行相关的组件或代码编写，这样才能从根本上解决性能低下的问题；业务功能详细测试并进行错误修正。 由于同济医院业务系统非常关键nTier 改造后正式上线是不能容许大的问题发生，所以， 在正式上线前，必须在模拟环境进行详细的测试后才能投入正式环境运行。
目前我国军队医院及地方多数医院的医院信息系统是采用PB+Oracle开发的C/S结构的 系统，必然会遇到类似问题。我们相信同济医院目前的迁移升级工作无疑是一种有益尝试,对其他医院的系统迁移升级工作必然会起到借鉴作用。
http://www.csdclub.net/?234
技术、应用服务器技术以及 Web 技术的 应用却很少，如在本院运行的信息系统，应用模块（子系统）已超过一百个，HIS主数据库 服务器连接数数高峰已突破 1000 个。由此可见，一般大型医院在系统应用上必然同样会遇 到：数据库
连接数大，数据访问频繁，系统压力集中；系统间耦合度高，系统扩展困难等各 种问题，而系统若从现在的 C/S 两层架构向分布式多层架构进行迁移升级，则可以解决系统 面临的一系列问题。
1 当前系统面临问题
1.1 系统性能瓶颈突出 本院开发的 HIS 系统，采用传统的 C/S 架构，客户端系统应用直接 连接到数据库系统，一个客户端至少需要占用一个数据库连接，一些大数据量查询被限制在 特定的时段才能使用。这样的状况不仅造成了极大的资
源浪费，而且在大并发下造成数据库 压力过重而不能快速响应和处理业务请求，导致系统系统性能低下。在实际应用中，每天应 用高峰时段系统连接主服务器的用户会话数可超过 1000 个，特别是在周一超大的系统规模 和巨大的访问量
更显系统性能低下，不仅令业务部门不满意，也让计算机中心人员更为紧张 和繁忙。
1.2 业务规则急需重整 目前系统开发中业务规则重用采用如下两种方法：一是数据库的存 储过程或函数，二是在客户端通过 PBL 共享或对象共享。但这两种方法都不是太理想，前者 不仅编写难度比较大，而且会增加数据库的压力，后者
通常不太好控制版本的一致性，而且 造成较大的分发和维护工作量。解决这些问题需要采用中间服务器和分布式应用等多层架构 思想，以降低开发和维护的难度及工作量。
1.3 系统偶合性强，集成难度高 目前大中型医院的医院信息化建设已从面向管理服务到面 向临床服务转变，开始了建设全面的数字化医院。系统应用面广、深入，模块日益增多，迫 切需要解决系统的大集成。由于医院信息系统的主体系
统自行开发，在与其他系统（包括引 进系统）集成时直接采用点对点的集成结构，系统间的偶合性很强，同时随着系统的发展， 不仅需要流程管理、营销渠道、外部服务等角度进行整合[1]，而且可能需要从数据、应用接 口、界面三个层
面上去实现集成，直接导致了集成的难度和复杂性，需要寻求适合自己的更 为先进的集成方式，如基于 SOA 和柔性流程的医院信息系统集成，来构造/升级整个医院的
[5] 信息系统 。
1.4 C/S 架构制约系统应用发展 传统 C/S 两层架构的应用系统，适合中小规模的局域网大 数据量的业务系统，技术成熟、稳定，目前仍在大量使用，然而，两层系统架构在大并发、 互连网部署、系统部署和维护等方面的局限必然会制约
系统横向更广，纵向更深的发展。
目前，我院 HIS 系统主体是采用 PB+Oracle 开发的传统 C/S 架构，随着同济医院的发展， 信息系统应用规模将越发庞大，按目前的访问方式预计高峰时间连接数将来有可能突破 2000 个，系统应用需求将进入跨区域的互连互通，
并且需要对外提供 Internet 信息发布及 服务等多样化应用的阶段，因此，目前的系统架构已经制约了系统进一步发展,有必要进行 系统架构的迁移升级。
2 PB C/S 系统迁移方案比较分析
多层架构的提出正是为解决了两层架构面临的各种问题，通常所指的“多层”主要为分 布式系统和 B/S（Browse/Server）系统。在同济医院信息系统的进行迁移升级的三层架构 是指多层分布式系统架构，同时基于目前医院 HIS 系
统开发的工具和具体应用情况，有如下 几种迁移方案可共选择。
2.1 用 J2EE/.NET 重新开发成 B/S 架构 放弃 PB，采用 Java/.NET 重写系统模块，改写 成 B/S 架构WebForm。虽然此迁移方案可按照最新的架构设计、可采用最新的技术实现；B/S 架构 WebForm 可让客户端维护工作降到最少等
优点，但也存在几个关键的问题：迁移周期长、 成本高昂。按目前医院系统应用规模，重新采用 J2EE 或.NET 开发、完善，不仅耗时，而且由于采用新的技术架构，旧有的技术投资和人员结构也得不到有效的保护和延续；响应速度 较低
、用户体验差、接受度低。B/S系统虽然可以减轻很多实施和维护的工作量，但并非都 适合 OLTP 业务系统。到目前为止，B/S系统的 Web Form 界面还很难达到传统的 Windows Form 界面的友好性和易操作性，而且响应速度相对要
低。
2.2 用 Appeon 迁移成 B/S 架构 采用Appeon 来迁移PB 系统，虽然自动化程度较高，大 部分简单的程序可自动转换等优点，但 Appeon 迁移系统，同样存在几个关键的问题：产品 发行成本高。Appeon 迁移的成本并不太高，但由
于迁移后的产品严重依耐 Appeon的运行环 境，这大大增加了产品的发行成本和发行难度，因此，Appeon适合迁移项目型系统（专案）， 而不太适合迁移商业产品；存在安全性隐患。Appeon 采用的是 OCX 方式来实现本地资源的 调
用和界面显示,一方面很多情况下 OCX 常会被浏览器阻止，另外，也存在被利用和攻击的 可能；Appeon 只是简单的把 C/S 程序“翻译”成 B/S 程序，并未进行组件化封装和业务逻 辑重组等工作，要进行这些工作，您需要自行进行规
划和开发。
2.3 用 PBnTierBuilder 迁移成多层架构[2] 采用 PbnTierBuilder 迁移 PB 系统，优点很 明显：与 PB 完美搭档，可持续发展。充分利用了现有技术人员资源，实现平稳技术升级， 保证了系统的平稳迁移；迁移升级简单。只需要在对
原来的系统进行简单的“翻译”（对 Datawindow、嵌入式 SQ进行改写），即可实现一次代码迁移改写，满足多种技术架构（分布 式多层 IIOP和 HTTP、.NET SmartClientWinForm、ASP.NET WebForm 等）的发布，而且可以 支持
多种数据库系统；基于 SOA 的参数化构件设计思想，便于系统间集成和管理维护；采用 高效数据压缩(最高 20 倍压缩比)等技术，互联网环境运行速度快。采用 PbnTierBuilder 迁移后的系统，在互联网上运行具有很好的性能、而且系统
发行成本低。这种方案和 Appeon 比较自动化程度略低。
从上面几个方案的技术特点，结合医院系统具体情况，我们认为用 PBnTierBuilder 迁 移升级 PB C/S 系统最为合适。
3 PBnTierBuilder 迁移方案
3.1 基于 Sybase EAServer 的多层架构关键技术[3-4] Sybase EAServer 是用来提供高可靠性、 高性能与可管理性的企业级分布式、客户/服务器、Web 应用的解决方案，使现有的应用集 成到 J2EE 环境与面向服务的架构（SOA）中。
其中 Jaguar CTS（组件事务服务器），是 Sybase 新的适应性组件体系结构的中间层的核心产品，它面向的应用类型是多层结构下的企业级客 户/服务器应用和 Web OLTP 应用。
Sybase EAServer 的多层架构有如下几个关键技术：分布式及组件技术，对业务处理层 和界面层进行了分离，业务处理层被抽象成组件，部署在应用服务器上，这样不仅可实现把 数据库、业务处理层、界面层部署到多台电脑上，而
且实现分布式处理，充分利用应用服务 器的强大功能，实现资源共享、负载均衡；数据库连接缓冲池，应用服务器提供数据库连接 缓冲池（Connection Cache）的技术来实现数据库连接的共享，即组件中的数据库连接为逻 辑连接，组
件在需要的时候动态从池中获取一个数据库连接，用完后又释放到池中，大大降 低实际的数据库连接数量，减轻了数据库的压力，提升了系统性能；组件实例缓冲池，客户 端连接到应用服务器，应用服务器采用组件实例缓冲池的技术
（Instance Pooling）实现只在需要执行具体的方法时才从实例缓冲池中取一个组件实例进行绑定，执行完方法后又释放 到缓冲池中；应用服务器集群。通过应用服务器集群来解决并发数和提升性能，和数据库的 集群（如 Oracle 的
RAC 集群）比较起来，具有更好的伸缩性和综合成本。
3.2 PBnTierBuilder 功能构成[2] PBnTierBuilder 是基于 Sybase EAserver 结构，服务于 Sybase 技术和应用开发者之间的桥梁，集服务端组件、客户端扩展(接口)组件、辅助开发 工具的于一体的开发工具。主要有如下几个部分组成：
服务端组件，包括标准数据服务组件、 常用功能组件以及用户自行扩展的组件，可以部署到 Sybase EAServer(5.x/6.x) 或 IIS(5/6/7)+.NET Framework2.0 之上；客户端扩展（接口），包括客户端接口集合，为不同 部署架构提供不同
的适配器集；辅助工具，包括系统数据配置工具、服务端配置工具和辅助 开发工具，实现对系统参数的管理和服务端数据对象的维护。图 1 是 PBnTierBuilder 技术 架构。
3.3 PBnTierBuilder 迁移步骤
3.3.1 搭建 nTier 应用迁移（开发）环境 这包括需安装一台 EAServer5.0 以上版本的应用 服务器，并且按照 PbnTierBuilder 要求进行组件部署，Connection Cache设置等配置。
3.3.2 在客户端程序应用 Target 中包含 PbnTierBuilder 客户端扩展 PBL 基于老的 C/S 程 序上建立一个新的 Target，除需要包含原来的全部 PBL 外，还要包含 PbnTierBuilder的客 户端扩展 PBL(PBD)，这样就可以直接调用
PbnTierBuilder 提供的易于使用、功能强大的数 据操作功能。
3.3.3 构造基本的nTier应用运行环境 nTier不在象传统的C/S程序那样直接访问数据库， 而是透过应用服务器来间接进行访问数据库的，因此需要在迁移的客户端程序中增加连接 Jaguar 服务器，创建远程对象代理等一序列 nTier 运行环
境代码。
3.3.4 迁移标准数据访问代码 针对 Datawindow 和 Datastore 的 Retrieve 和 Update、各 种嵌入式SQL以及DW和SQL混合更新的事务等都可使用PbnTierBuilder提供的标准数据访 问接口实现迁移转换。
3.3.5 编写扩展业务组件及调用 对于少量的特殊数据访问（如：SelectBlob/UpdateBLob） 以及需要进行封装、需要进行共享或需要向外提供服务的业务逻辑或功能，可基于 Pbntierbuilder 提供的扩展模板，自行编写业务组件以及客户
端调用接口。
3.3.6 根据实际需要发布成不同架构 代码迁移完成后，可根据最终系统使用的环境和要求， 发布成不同的技术架构：分布式多层 IIOP 和 HTTP、.NET SmartClientWinForm、ASP.NET WebForm 等。
4 迁移后应用与讨论
本院医院信息系统没进行三层系统的迁移升级前，使用护士站、计价录入系统工作站约 300 台，数据库连接数近 400 个。经过迁移升级后，三层系统目前仅使用 1 台应用服务器 (Sybase EAServer 5.3，单机多实例集群)，IIOP连接峰值不超过 100 个，数据库的连接数仅 10 个左右，系统性能整体得到提升，效果明显。2007 年开始迁移工作，首先完成计价录 入模块的迁移升级，然后完成开始护士站的迁移升级工作。目前迁移重点完成最基本的内容， 而一些共用的业务规则方面还需统一规划后再完成扩展功能服务类组件的对象编写、封装和 调用等迁移工作。同时我们认为在具体实施迁移升级的工作上要注意考虑：代码优化，首先 要从程序结构和运行背景上进行分析，找出合理、高效的执行流程，然后再进行相关的组件 或代码编写，这样才能从根本上解决性能低下的问题；业务功能详细测试并进行错误修正。 由于同济医院业务系统非常关键，nTier 改造后正式上线是不能容许大的问题发生，所以， 在正式上线前，必须在模拟环境进行详细的测试后才能投入正式环境运行。
目前我国军队医院及地方多数医院的医院信息系统是采用PB+Oracle开发的C/S结构的 系统，必然会遇到类似问题。我们相信同济医院目前的迁移升级工作无疑是一种有益尝试， 对其他医院的系统迁移升级工作必然会起到借鉴作用。
3.3 PBnTierBuilder 迁移步骤
3.3.1 搭建 nTier 应用迁移（开发）环境 这包括需安装一台 EAServer5.0 以上版本的应用 服务器，并且按PbnTierBuilder 要求进行组件部署，Connection Cache设置等配置。
3.3.2 在客户端程序应用 Target 中包含 PbnTierBuilder 客户端扩展 PBL 基于老的 C/S 程 序上建立一个新的 Target，除需要包含原来的全部 PBL 外，还要包含 PbnTierBuilder的客 户端扩展 PBL(PBD)，这样就可以直接调用 PbnTierBuilder 提供的易于使用、功能强大的数 据操作功能。
3.3.3 构造基本的nTier应用运行环境 nTier不在象传统的C/S程序那样直接访问数据库， 而是透过应用服务器来间接进行访问数据库的，因此需要在迁移的客户端程序中增加连接 Jaguar 服务器，创建远程对象代理等一序列 nTier 运行环境代码。
3.3.4 迁移标准数据访问代码 针对 Datawindow 和 Datastore 的 Retrieve 和 Update、各 种嵌入式SQL以及DW和SQL混合更新的事务等都可使用PbnTierBuilder提供的标准数据访 问接口实现迁移转换。
3.3.5 编写扩展业务组件及调用 对于少量的特殊数据访问（如：SelectBlob/UpdateBLob）
以及需要进行封装、需要进行共享或需要向外提供服务的业务逻辑或功能，可基于 Pbntierbuilder 提供的扩展模板，自行编写业务组件以及客户端调用接口。
3.3.6 根据实际需要发布成不同架构 代码迁移完成后，可根据最终系统使用的环境和要求， 发布成不同的技术架构：分布式多层 IIOP 和 HTTP、.NET SmartClientWinForm、ASP.NET WebForm 等。
4 迁移后应用与讨论
本院医院信息系统没进行三层系统的迁移升级前，使用护士站、计价录入系统工作站约 300 台，数据库连接数近 400 个。经过迁移升级后，三层系统目前仅使用 1 台应用服务器 Sybase EAServer 5.3，单机多实例集群)，IIOP连接峰值不超过 100 个，数据库的连接数 仅 10 个左右，系统性能整体得到提升，效果明显。2007 年开始迁移工作，首先完成计价录 入模块的迁移升级，然后完成开始护士站的迁移升级工作。目前迁移重点完成最基本的内容， 而一些共用的业务规则方面还需统一规划后再完成扩展功能服务类组件的对象编写、封装和 调用等迁移工作。同时我们认为在具体实施迁移升级的工作上要注意考虑：代码优化，首先 要从程序结构和运行背景上进行分析，找出合理、高效的执行流程，然后再进行相关的组件或代码编写，这样才能从根本上解决性能低下的问题；业务功能详细测试并进行错误修正。 由于同济医院业务系统非常关键nTier 改造后正式上线是不能容许大的问题发生，所以， 在正式上线前，必须在模拟环境进行详细的测试后才能投入正式环境运行。
目前我国军队医院及地方多数医院的医院信息系统是采用PB+Oracle开发的C/S结构的 系统，必然会遇到类似问题。我们相信同济医院目前的迁移升级工作无疑是一种有益尝试,对其他医院的系统迁移升级工作必然会起到借鉴作用。
http://www.csdclub.net/?234
...全文
请发表友善的回复…
发表回复
whuangqi 2013-01-18
- 打赏
- 举报
嗯，介绍的不错，有前景，虽说现在的HIS行业不太好做，其实关键还是技术+售后服务，而以后者更为重要，在技术同等情况下，要想赢得客户的口碑，只有靠服务，我们的服务态度好了，自然客户很夸赞，对于HIS公司而言增加了项目收益，对于我们医院客户来说，真正方便了我们的操作，简化了流程，提高了效率！
sbks 2011-06-02
- 打赏
- 举报
最最最关键的地方是：没有EA Server拿来玩，学习成本高
zeng_yan_cheng 2011-05-31
- 打赏
- 举报
貌似成功案例没几个哈
7710606 2011-05-27
- 打赏
- 举报
学习了
灰色轨迹 2011-02-27
- 打赏
- 举报
分析的很透彻，强顶~
shishangai 2011-01-19
- 打赏
- 举报
我们用的appeon
凡爸 2010-06-10
- 打赏
- 举报
广告贴，呵
永生天地 2010-06-08
- 打赏
- 举报
顶11
dahaidao 2010-06-08
- 打赏
- 举报
支持啊。
DYFDWX 2010-06-08
- 打赏
- 举报
顶顶顶顶顶顶
xueying0000 2010-06-07
- 打赏
- 举报
太牛了
