[发明专利]一种构件反向调用平台及构件间类组播通信的方法

说明书

技术领域

本发明涉及基于“平台+构件”软件架构技术领域，特别涉及一种构件可以反向调用平台，以及构件间进行“类组播”通信的方法。

背景技术

“平台+构件”的软件架构是基于“平台”的开发和基于“构件”的开发CBD二者的有机结合。在这种系统架构中，“平台”通常将系统的通用基础功能进行集成，并提供统一的集成框架；而“构件”提供某方面特定的或专业性功能。“构件”通过“平台”提供的统一集成框架集成到“平台”上，与“平台”一起构成一个整体的应用系统。这种传统意义上的“平台+构件”系统架构可以用图1来说明。

在这种传统意义上的系统架构中，构件和平台之间功能和数据交互一般存在两种方式：

一种是，领域平台调用构件的功能函数来完成某些特定的任务或计算，而构件一般是不能反向调用平台的计算服务的，即平台的计算功能是很难暴露给构件使用的，如图2所示。这种情形下，平台是一个可执行程序且不具有二次开发功能和接口，而构件是集成到平台上运行的动态链接库。

另一种是，平台具有二次开发功能，即除了上述平台调用构件功能之外，平台还提供一系列开发包(一般为动态链接库DLL)，第三方(即开发用户)可以使用平台开发包提供的基础功能来开发应用系统。此时，虽然调用平台开发包功能的可以是构件也可以是某种程序片段，但用户开发的应用系统最终是一个与平台独立的可执行程序EXE，而不是集成到平台上执行的动态链接库。“平台+构件”的这种模式，是目前最为流行的软件开发方式，如科学计算领域的MATLAB。这种具有二次开发能力的“平台+构件”架构模式的系统结构如图3所示。

上述两种系统结构是“平台+构件”架构模式系统一般的表现形式，即传统意义上的基于平台的开发和基于构件的开发模式。第一种模式中，开发的构件和平台集成在一起构成一个完整的应用系统；而第二种模式中，基于平台开发的应用系统独立于平台运行。

第一种模式中，平台其实不具有二次开发能力，因此只能平台调用构件的功能。这种模式带来的优点是系统具有统一的集成框架、操作界面和使用风格，集成也相对简单。但其缺点是由于平台不提供二次能力，因此构件不能调用平台上的基础功能，对于那些需要类似于平台的基础和通用功能的构件来说，这是很大的缺陷。这种缺陷带来的不仅仅是构件对基础功能和某些算法的重复开发，如果构件对平台的基础功能存在依赖关系(即构件功能的执行需要平台提供上下文环境)，那么此时构件与平台的互动将变得很困难。这种情况下，如果由于依赖关系而构件需要调用或启动平台的某项功能(或服务)，一般是通过数据库、文件或消息机制来完成。如，构件向数据库写一个“平台调用地图”的要求，而平台需要通过某种轮询机制来访问数据库以获得“调用地图”的要求。但这种机制的前提是构件和平台之间必须事先存在某种“契约”，即平台如何解析数据库记录的约定。文件方式和消息机制也同样需要这种“契约”。这种“契约”方式虽然能解决一定的问题，但“契约”的约定往往很难，且效率很低(如数据库访问、文件读取效率都比较低，轮询机制有时对系统资源开销较大)。因此，总体而言，由于平台不提供二次开发功能接口，而带来系统的可扩展性比较差。

第二种模式中，平台提供二次开发功能接口，从某种程度上克服了第一种模式的不足，但带来的问题是由于没有统一的集成框架和系统操作方式，因此开发出来的系统在集成性、可互操作性、可扩展性、使用风格和界面的规范性以及维护性等方面存在严重不足。另外，如果一旦平台开发包依赖于平台的某种服务(即开发包动态库中某些服务其实是由平台来提供的，而不是在开发包来完成的，那些包含许多计算量比较大而相互依赖的基础功能的平台往往会将这些基础功能以服务的形式提供，而不是将其放入开发包中，这样开发包就会“瘦”许多，否则开发包过大就会造成开发困难或运行时开销过大。如系统动力学计算平台Adams就是这样一种开发模式)，那么在运行应用系统的同时也必须运行平台，这样就可能存在不必要的系统开销(因为许多情况下，平台的服务是不需要的。虽然可以通过人工的方式来启动和关闭平台，但由于我们难以确定系统需要平台服务的时机，因此最好将平台一直处于运行状态)。