还是老的方案。我在考虑是不是利用中间件传XML文件（热

arbol

1．底层通讯消息中间件模块（可独立）：建立通信双工长连接链路或者是以后要求的机制，（因为卫生部还没有此方面的规范，所以我们可能必要有单工，双工和长连接、短连接的功能）开发UNIX和WINDOWS两种平台的产品，该产品要具有稳定，独立，消息队列控制等机制，功能上要有对信息格式为符合HL7标准的字符串的传递，可单独成为产品。尽量做成一个简单的消息中间件模式。
2．XML解析树：对信息格式为符合HL7标准的字符串进行XML解析，这一步就是建立解析HL7消息树的引擎。这个模块搭在消息中间件上面，不能单独称为产品。该模块功能主要在于解析，因为HL7V3.0支持XML，可以从此处对应，在通讯消息中间件平台上不需了解HL7的编码构造。此模块的主要意义在于支持对基于XML的应用系统联系。
3．应用程序接口：对解析为HL7V3.0的XML消息交给引用程序来处理，定义一些应用程序接口，此处，还考虑是否把XML的消息存储到数据库中。所以还要定义很多接口来让数据库调用。

arbol

今天我一个朋友告诉我她用CORBA写过传XML字符串的东西，可是我不懂JAVA，所以没有办法去实现。
我想了想用ANSI C写中间件的通讯东西，提供一些接口函数。
我朋友建议我看看IBM的XML4C，它提供了一些C++的语言接口，用它来对XML进行分析。有没有人熟悉XML4C的东东。
然后对数据库的东西，我正在想了。

乖乖兔

原来美国的一位朋友告诉我说它的系统使用ASN.1实现。其实无论是COM+或者CORBA都是一些软件的体系结构。

乖乖兔

如果对于产品，而不是单纯的hl7低层实现。我非常同意你的利用中间件的构思！把具体的通讯层和HL7核心层分开。我建议你找一下TongLinkQ的有关资料看一下。他就是一个独立的通讯中间件。

arbol

是，是软件的体系结构，因为借助于这些东西，才能搭建一个通信平台，才能跑HL7标准，如果这些都没有只谈论HL7是没有现实意义的。
我们要做的就是尽快实现应用，从应用中早讨论改进，空谈是不现实的。
我要先开发简单通讯中间件了，至于到时的XML解析，可以独立，也可以附加在对传递的XML字符串上，统一给上层一个接口。
我可能只做UNIX/LINUX下的开发，因为我只有一个人。时间期限先定到年底了。
可以帮忙吗？乖乖兔

arbol

我知道你说的东方通的东西。不过，建行反应并不好，其实BEA TEXEDO非常好，可惜太贵了。所以，我只好自己来开发一个简单的中间件。
提到简单。因为它只传递建立长连接，传递字符串。而没有按结构来通过连接传文件。
我正在写一个提供FTP功能的接口函数。

arbol

其实，利用中间件还是因为不同的医院有着不同的厂家。那么各个厂家以后基于HL7标准的产品可能根本不一样。这样，即使大家都说基于HL7标准，可是却无法连接。如果我们能开发出传递HL7XML字符串的简单通讯中间件的话，那么互联互通才可能实现，信息交互才可能产生。HL7的很大定义才可能具体化。
但是，我们不要抱有幻想。从我看这和行业了解的情况。医院自己自身对互联互通的概念可能都还有抵触情绪。再是卫生部是否有这个想法都不一定。但大的方向肯定是要朝这个地方走的。所以，我们的研究或者研发都要尽快的进行下去。
为这个社会，我们是要做出贡献的。