2.2 通信框架
通信框架提供通信接口,实现消息发送接收等功能。具体的应用利用该通信框架实现应用集成、协同和服务调用。平台中的通信按照通信范围不同分为三个层次(图3所示):①本地通信。位于相同机器上应用程序间的通信,或应用程序与本地服务器之间的通信,消息通过本地服务器中转。②客户端/服务器通信。位于网络内不同机器间本地服务器的通信,或本地服务器与远程服务器的通信,使用了这一层通信方式的消息通过本地服务器和远程服务器两层中转。③服务器/集群服务器通信。远程服务器出于稳定性、性能等方面的考虑,把来自应用程序的消息转交给集群服务器处理。使用这一层通信方式的消息通过了本地服务器/远程服务器/集群服务器三层中转。为了获得相同的性能,一般来说,跨机器通信的代价远大于相同机器上不同进程间的通信的代价。如果不加区分在上述三种层次的通信中统一使用跨机器通信技术,将降低以本地通信为主的应用的执行效率。然而企业目前大部分集成往往在同一台主机上的不同应用程序间进行。因此出于性能、架构灵活性多方面考虑,必须对于不同层次的通信采用不同的通信技术,以满足所有的通信需求,同时得到最大程度的灵活性。
根据对目前可用的分布式通信框架DCOM[4]、CORBA[5]、TCP/IP、.NET、J2EE的分析。前面三类通信框架均以TCP/IP为基础,拥有具体的应用开发规范,屏蔽了底层的通信细节。 但是企业信息化软件系统以在Windows2000上VC、PB开发的应用程序为主,.NET、J2EE框架无法与这些产品很好的集成,不能作为候选的通信技术。DCOM是一种可行的局域网内的分布式通信方式,但是由于其自身实现和在安全方面的限制,在跨局域网和Internet上的应用很受限制,不能穿透防火墙,考虑到网络集成平台向Internet扩展的潜在需求,不能采用DCOM。CORBA是一种较好的分布式通信框架,也是事实上的工业标准,但是对网络集成平台而言并不适用。主要出于以下的考虑:利用CORBA通信必须遵循CORBA规范,使用IDL(接口定义语言)作为主要的通信接口,对于已经定型的软件系统(不是CORBA体系)和基于消息的通信而言,使用不便。CORBA同样在Internet通信方面存在穿越防火墙等限制,同时在传送文件和大数据量二进制数据方面存在缺陷。综合考虑以上因素,本文采用图3所示的混合分布式的通信框架,选择COM和TCP/IP混合通信的方式作为通信架构的实现技术。本地通信采用COM和COM连接点事件的通信方式,客户端/服务器通信采用TCP/IP中的SOCKET通信,服务器/集群服务器通信也采用了SOCKET通信。

图3 通信框架
通信框架实现了消息在本地服务器、远程服务器、集群服务器间的传递,这些服务器接收到消息后,会根据具体的消息类别,通过应用开发接口向上面的应用模块传递,使每个消息都有被相应的应用模块处理的机会。在应用模块内部可以根据逻辑处理的需要,决定是否转发消息,如果需要转发,调用通信框架的通信接口。实现通信框架后,开发应用时不需要考虑消息传输的细节,专注于应用逻辑的开发。
3 消息协议
在集成平台中,各个客户应用,以及集成、协同应用的命令传递和数据交互,都是通过消息的驱动来实现的,因此要求消息的处理具有较高的实时性和可靠性。为了提高消息处理的实时性,根据消息的耦合程度将消息分为模态消息和非模态消息。模态消息要求消息处理完成返回后,发送消息的应用系统才能解除等待状态。对于非模态消息,应用系统在发送消息成功后即可执行其它操作。为了保证消息在发送者和接收者之间的可靠传送,需要进行额外的处理:消息缓存、超时处理、错误处理。对于可能来不及发送的消息进行缓存,并在适当的时候发送该消息。超时处理指消息在其设定时间内如果没有成功发送,则根据用户设置的消息传送策略通知消息发送者或重试一定的次数。错误处理指在消息发送过程中或消息解析中发现错误(如突然中断、解析失败),则进行相应的处理,如通知消息发送者出现错误,并附带相应的错误信息。
由于各种应用集成的场景和要求各异,因此要求消息结构具有较强的扩展性和柔性。消息由消息头和消息主体两部分组成。消息头标志消息的编号、接收者、发送时间、超时时间、应用类别等状态信息,起辅助控制消息传递作用。消息主体包含消息的具体内容、应用数据。按照消息主体的不同,消息(Message)可分为三大类:① 文本消息(TextMessage)。消息主体由纯字符串组成,这是最常用的消息格式。② 结构化消息(面向对象的消息,如IntegrateMessage、CooperateMessage等)。消息主体是一个特定的结构或类,在结构和类中可以包含字符串、整数、浮点数等基本数据类型。③二进制流消息。消息主体由比特流组成。消息主体从内容上分为基础部分和扩展部分。基础部分是各应用消息的共有字段,而扩展部分就是个应用根据各自的特点自行规定的字段。消息中的消息内容(Text)是一个核心字段,它包含了消息的各种集成协同参数。这些参数既可以通过使用AddParam接口逐个传递,也可以使用ParseParam接口,用更灵活的组合字符串的形式或结构化的表达形式(如XML等)。下文列出了消息头、消息、文本消息的数据描述,在它们的基础上还可以继承派生出其它各种更复杂的集成、协同的消息。
(1) 消息头的数据描述
struct HEADER
{
uint16 ver; //版本
uint16 app; //应用号
uint16 cmd; //命令
uint16 reserved2; //保留字段,未使用
};
(2) Message消息格式的数据描述
stuct Message
{
HEADER Head; // 消息头
Int MessageID; // 消息编号
int From; // 来自于那个客户端
int To; // 本地发送/远程发送/自动判断
long Time; // 发送时间
long TimeOut; // 超时时间
};
(3) TextMessage消息格式的数据描述
stuct TextMessage : public Message
{
int MessageType; // 消息应用类型
int AppID; // 那个应用的Message
bool NeedReturn; // 本消息是否需要返回值
int Reserved1; // 保留参数1
int Reserved2; // 保留参数2
char* Text; // 消息内容
};
4 集成平台的运行流程实例
目前3D CAD软件纷纷采用特征造型的新技术,在3D 模型中不仅含有产品几何形状信息, 而且将工艺信息如公差、光洁度、孔、槽等已建在特征模型中。此外,3D模型具有良好的可视性,能有效降低设计与工艺之间的信息流的

图4 基于3D 特征的工艺设计的流程
损失率。因此,对于使用CAPP的工艺人员,这些来自CAD系统的特征参数化的信息可以成为其进行工艺设计的基础。在上述研究的基础上,结合开目公司的KMCAPP、KMCAD系统,说明我们通过信息集成平台实现的基于3D特征的工艺设计流程(如图4所示)。
(1)工艺人员在使用客户端CAPP程序进行工艺设计时(如图4.a所示,设计轴的加工工艺过程),需要从3D CAD文件中提取工艺特征信息,则CAPP通过集成平台的代理,构造"请求基于3D特征的工艺设计"消息(Request对象)并发送此消息,此消息包含应用程序名、函数名或功能代号、函数参数列表、相关文件资源(轴的3D模型文件)等信息。
(2)应用请求Request经过本地服务器转发至远程服务器,如图4.b所示。远程服务器解析消息,根据各个集群服务器向其注册相关应用资源信息,搜寻空闲的目标应用程序资源(即KMCAD应用)所对应的应用适配器,并通过应用适配器的标准服务接口HandleRequest把Request交给应用适配器处理。应用适配器再根据调函数名或功能代号查找匹配具体的处理函数,在处理函数中封装了具体的执行代码,完成读取零件3D模型中(如轴)的工艺特征信息的功能。图4.C显示了在KMCAD中设计人员定义的轴的加工特征。
(3)处理完成后,零件3D模型中的工艺特征信息自动包含在Request对象中,只需调用它的Return接口返回处理结果,处理后的文件(轴的3D模型文件)等辅助资源将和它一起返回。
(4)工艺特征信息经信息集成平台返回给CAPP系统,工艺人员可以在此基础上进行工艺过程设计。此外,如果在第二步中,集成平台定位到CAPP本地客户端安装了相应的CAD应用资源,则直接在本地完成集成,并可以进行界面互动的集成,如图4.d 所示,通过集成平台将两个系统协同起来,在一个应用中通过自身的界面操作能够可视化地与另外一个应用通信、访问另外一个应用的功能,从而实现多个系统间的信息共享与同步。
5 总结
制造业信息化集成平台技术是近年来用于企业信息系统集成的一种先进的计算机软件技术,是一个支持复杂信息环境下CIMS应用开发、应用集成和系统运行的软件平台。本文提出一套面向制造业信息化整体解决方案的集成平台模型与实现体系, 它采用了基于消息驱动的星型(Hub/Spoke)集成模式,支持多级集成部署和混合分布式通信框架,具有架构灵活、快速部署实施、低成本和功能易扩展的特点。基于该集成平台,开目公司在较短的时间内完成了KMCAPP、KMPDM与PRO/E、UG、SolidWorks、 Autocad、KMCAD等各类制造业信息化软件的集成,并在实际的应用中取得了很好的使用效果。
参考文献:
[1] 杨海成,王海龙,敬石开.制造业信息化集成平台技术发展的认识与思考.航空制造技术.2004,1:22-25.
[2] 范玉顺,李建强.制造网络集成平台技术研究.计算机集成制造系统-CIMS.2003,9(3):84-90
[3] 张金,陈艳军,陈卓宁.基于代理的CAx/PDM透明式互动集成的研究.机械科学与技术.2005, 24(8):969-973
[4] C. Szyperski. Component Technology-What,Where,andHow?. Procs. Int. Conf. on Software Engineering (ICSE).May 2003. Portland, IEEE. pp: 684-693.
[5]OMG. Common Object Request Broker:Architecture and Specification V2.0. USA:Object Managemen Group,Inc. 1996.
基金项目:国家高技术研究发展计划资助项目(2005AA4Z3060)。2003年电子发展基金项目:产品数据管理(PDM)。