|
<p>本文的原始连接：<a href="http://www.agilelabs.cn/blogs/linkin/archive/2006/04/22/1029.aspx" target="_blank">http://www.agilelabs.cn/blogs/linkin/archive/2006/04/22/1029.aspx...04/22/1029.aspx</a></p><p>作为医院来说，要搞信息化一般有这两种选择：</p><ul><li>找一家做一体化HIS产品的软件公司。把医院的所有需要信息化的东西全部都做了。</li></ul><p>这种选择的好处是每个功能模块都是一家公司做，所以互相之间的配合可以做得很好。医院也比较省事省心，项目的实施速度也快，质量也好。目前大部分医院都采用的是这样的模式。</p><p>但是这种最大的缺点就是，医院一旦和这样的公司合作，未来的信息化就几乎完全被绑死在这家公司上。万一这家公司不思进取，产品研发停滞，或者遭遇天灾人祸导致公司倒闭关门，那医院也只有跟着一起遭殃，因为全面更换系统的代价太高了。以前的投资几乎全部浪费不说，同时还意味着所有的人员要重新培训，甚至有可能多年积累的数据资料也全部报销。</p><p>换不换系统？</p><p>换。代价太高，医院承受不起。而且假如又换到一家这样的公司，医院若干年后还是会面临同样的问题。</p><p>不换，该系统已经无法满足医院的发展需要，影响医院的竞争力。这也是影响到医院生死存亡的问题。</p><p>所以目前医院只好小心谨慎，再小心谨慎的挑选一家能靠得住的HIS厂商。但即使是再有经验的CIO，也会有看走眼的时候。更何况天有不测风云，以前叱咤HIS界的众邦、瑞德这样的大哥大级公司，倒闭的倒闭，被收购的被收购。连世界第一大软件公司Microsoft也说：“微软离破产永远只有十八个月”。国内软件行业的风云变幻莫测，谁又敢说他肯定能撑3年？</p><p>所以医院在跟HIS公司签单时候的心情就跟少女出嫁时的一样，既担心又紧张。真是男怕入错行，女怕嫁错郎，医院怕选错HIS商。</p><p>好吧，既然是这样，医院们还有一种选择：</p><ul><li>多找几家HIS公司，每个公司做一个模块，合起来完成整个医院的信息化系统。一家不行了就换一家，反正影响也就只有一个模块。</li></ul><p>这种方式确实避免了跟某一家公司的绑定，最大程度的降低了风险。听起来的确很完美，许多医院最希望的也是这样一种方案。但是可惜的是，由于缺乏一个统一的行业技术标准。HIS厂商们即使想和别的HIS系统互相连接也不知道怎么和别的HIS连接。所以，当医院决定采用这种模式来做信息化的时候，一般是找齐这些软件厂商，然后聚在一起分好工，谁谁谁做什么模块都定好，然后大家坐在一起开发，互相配合。</p><p>我想这个过程中的难度凡是做过企业软件的都能够想象得到。由于大家不是同一个公司的，开发平台，编程语言，设计理念等都相差很大。而且大家各归各的领导管，谁也不服谁。假如A系统和B系统需要互连，但是接口不一样。谁改？A叫B改，B叫A改，最后结果就是谁也不改。即使是接口对上了，以后出了问题，A说是B的问题，B又说是A的问题。最后结果就是谁也不来解决。</p><p>那么好吧，既然A和B都不来解决，把他们俩都踢了。</p><p>慢，踢不得！C、D、E、F、G系统都调用了A或B，把他们踢掉了这些系统也要根据新的系统重新调整和编译，大家又需要坐在一起，重复开发系统时的那个过程。不过人家也不是随喊随到的，各家公司的档期都不一样，除非是这个医院特别有面子，能把这么多公司协调好，否则困难就实在是太大了。</p><p>所以，结果就是：的确没有和某一家公司绑定，却同时和n家公司绑定。任何一家公司挂了，整个系统都挂了。所以和一家公司绑定比起来，风险不是降低为1/n，而是反而增加了n倍。</p><p>一家不行，多家也不行，那到底怎么办？</p><p>这时候有人出来喊了：要建立统一的行业标准！</p><p>的确，统一的标准确实绝对不能少，但是只要标准统一了就没问题了吗？任何一家公司的产品都可以被替换掉了吗？</p><p>答案是：依然不行。具体原因，请看下面这幅图：</p><p><!--attachid::310--><a href='attachment.php?id=310&u=5088&extension=gif&attach=1145647550.gif&filename=arch1.gif&attachpath=5/0/8/8' title='arch1.gif - 文件大小2.8KB' target='_blank'><img src='attachment.php?do=showthumb&u=5088&extension=gif&attach=thumb_1145647550.jpg&attachpath=5/0/8/8' width='200' height='92' alt='arch1.gif - 文件大小2.8KB (点击缩略图放大查看)' /></a> <!--attachid--></p><p></p>图中是ABC三个模块，其中A和C都需要从B中提取数据，A和C都调用模块B。怎么调用？最简单的方式是B提供一个dll动态联接库，A和C模块的程序集引用，然后根据一定的规则调用B的dll中定义的方法。<p></p><p>假设B模块发现了问题，需要被替换，医院需要把B模块替换掉。换了一个公司新做了模块D，这时候能直接把D替换上去吗？没有办法，因为D模块是一个新的dll，不可能做到跟原来的dll完全一样，所以懂编程的人都应该知道，是无法在不修改A和B并重新编译代码的情况下能直接调用D模块的。而且D提供dll动态连接库还是一个比较乐观的假设。假如D系统是用JAVA平台开发的，或者是运行在LINUX或UNIX系统上的，这时候哪怕是重新编译A和B都没有办法了。这种系统之间的集成方式被称之为“紧耦合”。</p><p>这时候，就要提到这篇文章的真正主角SOA了。我们先来看看SOA的介绍（以下蓝色部分为摘录）：</p><p><font color="#0000ff">SOA是英文Service-Oriented Architecture，即面向服务架构的缩写。简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是service)组合构建起来的。本质上说，SOA体现的是一种新的系统架构，SOA的出现，将为整个企业级软件架构设计带来巨大的影响。</font></p><p><font color="#0000ff">SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。</font></p><p><font color="#0000ff">这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。</font></p><p><font color="#0000ff">对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。</font></p><p>再来看看基于SOA架构设计的系统结构图：</p><p> <!--attachid::311--><a href='attachment.php?id=311&u=5088&extension=gif&attach=1145647571.gif&filename=arch2.gif&attachpath=5/0/8/8' title='arch2.gif - 文件大小5.1KB' target='_blank'><img src='attachment.php?do=showthumb&u=5088&extension=gif&attach=thumb_1145647571.jpg&attachpath=5/0/8/8' width='200' height='113' alt='arch2.gif - 文件大小5.1KB (点击缩略图放大查看)' /></a> <!--attachid--> </p><p></p><p>在图中，ABC模块彼此之间完全独立，互相之间并不知道有其它模块存在。那么，A和C所需要的数据从哪里来呢？答案是工作流（注意，ABC也都并不知道工作流系统的存在）。所有系统之间的交互信息全部都通过工作流系统进行流转（信息为XML格式，符合HL7标准）。</p><p>而在刚才讨论的紧耦合架构里，A和C都必须知道B模块的存在，所以导致了B无法被轻易的替换。而在SOA架构中，由于A和C并不知道B模块的存在。因此，B模块可以很容易的被替换成一个其它符合标准的模块。即使是不太符合标准，也可以在工作流层方便的写一个消息转换程序来进行消息格式的转换。同时，B可以由任意平台开发（JAVA，.NET）或者任何操作系统（Windows,Linux,Unit等），当然，也包括了任意的HIS厂商。仅仅只需要他们的软件模块规格和接口符合统一的标准。</p><p><!--attachid::312--><a href='attachment.php?id=312&u=5088&extension=jpg&attach=1145647666.jpg&filename=a.JPG&attachpath=5/0/8/8' title='a.JPG - 文件大小33.3KB' target='_blank'><img src='attachment.php?do=showthumb&u=5088&extension=jpg&attach=thumb_1145647666.jpg&attachpath=5/0/8/8' width='200' height='150' alt='a.JPG - 文件大小33.3KB (点击缩略图放大查看)' /></a> <!--attachid--> </p><p>在我们（敏捷实验室，<a href="http://www.agilelabs.cn" target="_blank">http://www.agilelabs.cn</a>）所开发的HIS系统正是完全按照SOA架构的概念进行设计，任何一个模块，比如挂号、收费处、医生工作站、药房、检验工作站、放射工作站等等全部都是完全独立的，彼此并不知道别的系统存在。比如医生工作站在开出处方后，并不知道该将处方写到哪个数据库表或者是传输给那个系统的接口。而是将收费信息发送给工作流（医生工作站也并不知道工作流系统的存在），当工作流接收到医生工作站事件后，按照预先定义的工作流路径将处方数据传输给收费系统。而收费系统也只负责将传入的数据进行收费后再通过事件发送出去，并不关心收费数据从哪里来，要到哪里去。然后工作流接收到收费完成的事件后，再将数据发送到药房系统。而工作流的定义则采用图形化设计器，也就是说普通的医院信息管理员就可以简单操作来改变流程或者是替换系统。</p><p><!--attachid::314--><a href='attachment.php?id=314&u=5088&extension=jpg&attach=1145647705.jpg&filename=500x298.jpg&attachpath=5/0/8/8' title='500x298.jpg - 文件大小15.6KB' target='_blank'><img src='attachment.php?do=showthumb&u=5088&extension=jpg&attach=thumb_1145647705.jpg&attachpath=5/0/8/8' width='200' height='120' alt='500x298.jpg - 文件大小15.6KB (点击缩略图放大查看)' /></a> <!--attachid--> </p><p>SOA架构是解决企业信息系统集成问题的方向和趋势。</p><!--editpost--><br /><br /><br /><div><font class='editinfo'>此帖由 luyan 在 2006-04-22 17:03 进行编辑...</font></div><!--editpost1--> |
发表于 2006-4-22 03:22:47
luyan @ 2006-04-22 08:53)</div><div class='quotemain'><!--quote1--><p>SOA一定会是今后HIS发展的趋势。未来按照传统方式开发的HIS系统都要慢慢被淘汰掉。</p><p><!--quote2--></div><!--quote3--></p><p>期望着采用SOA开发的系统能够解决目前存在的问题<br /></p>