论文部分内容阅读
摘 要：在以Car构件为基础的嵌入式研究领域中，构建面向Web服务的Car构件运行容器一直是研究的热点。文章阐述了面向Web服务的Car构件运行容器的特点，介绍了构件技术以及“和欣”操作系统，讨论了构件化的Web Container的分层设计理念，阐述了在“和欣”操作系统上实现的基于构件的Car Faces系统。该系统充分发挥了构件技术的优势，并具有简单、高效可配置等特点，很好地满足了以Car构件为基础的Web应用程序的需求。
关键词：嵌入式系统；Web容器；构件技术；和欣
0 引言
基于构件的软件工程是实现高生产率、低维护费用和高可靠软件产品的关键技术，在这种工程模式下，按照一定的架构把构件组装起来成为软件开发的核心工作。目前绝大多数传统的嵌入式应用仍然是采用强类型的系统编程语言(比如c和Java等)来完成对构件的组装。对于一个应用程序仅需改变应用的表现层，而不必大量修改构件功能的情况，传统开发模式所要经过的修改一编译一运行的过程就显得效率低下，开发周期长和不能随需求灵活变化的弱点就暴露了出来；另外，采用强类型语言来实现功能构件并将这些构件组装成应用程序，将造成构件之间的强耦合关系，会使得开发维护的难度加大。
为了实现构件问的松散耦合，提高开发维护的效率和适应需求变化的能力，有必要在应用的开发中引入新的开发模式，采用新的构件组装技术来适应新形势的发展。考虑到脚本语言的语法简单、功能强大、易学易用的特点，本文基于CAR构件技术，提出了新的XML+CAR+其他脚本语言(Javascript、Ruby等)的Car Faces编程范式，实现了更为灵活的构件组装机制，为在“和欣”上的应用开发提供了更加快速、灵活的编程范式。另外，手机上网已成为一种潮流，采用原始的模型势必导致服务器高负载运转，所以也需要一种新的架构模式，用来解决手机上网所带来的新问题。
1 构件技术及“和欣”操作系统
构件技术是在面向对象技术的基础上发展起来的。面向对象技术通过类的封装和继承成功实现了代码级的复用。类的封装性，实现数据抽象和信息隐蔽；而类的继承，提高了代码复用性。但是面向对象的复用脱离不了代码复用的本质，对象之间的关系在编译时被固定，模块之间的关系是静态的，无法解决软件动态升级和软件模块动态替换。
构件技术通过二进制的封装以及动态链接技术解决软件的动态升级和软件的动态替换问题。面向构件技术对一组类的组合进行封装，它代表完成一个或多个功能的特定服务，同时为用户提供多个接口。整个构件隐藏了具体的实现，只用接口提供服务。这样，在不同层次上，构件均可以将底层多个逻辑组合成高层次上的粒度更大的新构件。构件之间通过约定的接口进行数据交换和信息传递，构件的位置是相互透明的，可以在同一个用户进程空间，也可以在不同的用户进程空间，甚至在不同的机器上；而且不同的构件可以用不同的语言编写，只要它们符合事先约定的构件规范。
“和欣”操作系统是科泰世纪公司开发的具有自主知识产权、基于微内核和构件技术，支持构件化应用的嵌入式操作系统。“和欣”操作系统对CAR构件技术提供了内置的支持。
CAR构件技术是面向构件编程的编程模型。它规定了一组构件间相互调用的标准，使得二进制构件能够自描述，能够在运行时动态链接，进行系统升级的时候也只需要升级相关的构件即可，具有可靠性、容错性、安全性，代表了软件工厂化生产的方向。
2 构件化Car Faces的设计
为了能满足新的需求，如图1所示，整个系统的服务器端分为四层：呈现层、导行层、验证层和业务处理层。另外，底层采用Car构件支撑各个环节的运行和交互。
图1 Car Faces业务逻辑架构
其中，呈现层实现视图的相互转换：(1)将页面提交的html代码还原成Car Faces树，并以xml树形格式呈现。同时这一层负责将树上的各节点值或组件与后台支撑的Car构件动态绑定。(2)将页面导行系统提交的Car Faces树转换成html代码表示，整个系统通过这一层实现服务器和客户的直接交互。
当呈现层从客户端接收完数据并转化成Car Faces代码后，就将转换结果递交到验证层。验证层从树的根结点遍历整棵树并调用绑定到各结点的相应的验证程序。如果一旦遇到错误信息，验证程序将把所得到的错误信息排队。验证结束后根据决策代码决定是否向下层提交或者直接调用Response．finish()将错误信息呈现给客户端。验证过程中，我们可以调用默认程序EzValidate，也可以调用用户自定义为结点绑定的验证程序。验证程序的实现，也是通过调用各后台支撑Car构件来完成的。
如果验证程序验证结束，将进入业务处理模块。在这一模块中我们定义了许多业务Car构件，通过调用业务Car构件的应用程序，可以完成对用户数据的处理。业务处理模块根据客户端产生的事件调用相应的业务处理程序，最终得到处理结果。处理完成后将处理结果提交业务导行模块。
导行层次是为客户呈现具体页面而设计的。在这一层里，我们通过业务层的运行结果或者错误信息选择适当的页面信息返回给客户。用户根据返回信息可以知道操作的结果。
所以在整个架构的设计过程中，构件容器占据着至关重要的作用。
3 Car Faces生命周期
图2为我们展示了car Faces请求响应的生命周期。
图2 Car Faces生命周期
接到客户端的请求后，首先将请求视图转换为Car Faces树状视图。在转换过程中可能会出现转换异常现象。当发生了异常后，应用程序捕获异常，根据错误类型作相应的处理。
呈现结束后，根据转换的结果树的值动态绑定到相应的构件上，并在此作一些初步处理。
上面两步完成后，生命周期将进入下一个阶段：验证处理阶段。在验证处理阶段将对Car Faces视图的每个结点实行验证处理。一旦出现错误，处理程序立即捕获错误，并根据错误类型实施相应的处理。
以上各阶段工作完成后，将进行的就是核心工作：业务处理。业务处理调用业务处理程序对转换后的数据进行相应的处理，进而达到为客户服务的目的。在这一阶段也可能会有意想不到的异常发生。一旦发生异常，将有异常处理程序做相应的处理。
业务处理完毕后，处理结果树被递交给页面导行。页面导行根据业务处理结果做出抉择，最终确定要向用户返回哪个页面。
上面所有处理完成后，Car Faces生命周期也进入了最后的阶段：页面呈现。在这一阶段，将根据页面导行程序所递交的结果对结果树实施页面呈现。同时，服务器端各种组件给用户呈现可识别代码，最终以html代码的形式返回给客户。
4 Car Faces在“和欣”上的实现
完整的Car Faces架构可以表示为图3
图3 Car Faces系统架构
(1)最外层是Car Faces运行环境(Runtime)，负责初始化和释放Car Faces应用所需资源。
(2)内部顶层是脚本语言及其配套设施。这一层相当于提供了对MVC中View的支持。
XML／JavaScriptt/Other Scripts提供了多种描述Car Faces应用的形式，让开发人员能够灵活利用各种脚本语言的优势。
(3)SCI(script Callable Interface)是脚本语言与CAR构件系统通信的桥梁。这一层相当于提供了对MVC中Controller的支持。
(4)CFSTL(Car Faces Standard Tag Library)是Car Faces提供的标准标签库，其中Car Faces提供了标准的自定义组件。CTL(Custom Tag Library)是用户自定义标签库。页面设计人员能够使用这两个标签库所提供的标签。
(5)CAR构件系统。它是服务的提供者。这一层相当于提供了对MVC中Model的支持。在这一层，实现了各种Car构件。这些构件支持着上层的业务逻辑能够顺畅运行。
本Car Faces架构集成了XML-GIue特点。
通过以上论述，可以看出使用Car Faces具有诸多优点：(1)Car构件直接运行在本地机器上，某些操作甚至可以直接控制硬件，所以其速度相对较快。(2)Car Faces实现了清晰的分层概念，不像AJXA只局限于技术的实现。(3)组件的可扩展性好。在本系统中，提供了许多标准组件，但同时也给用户提供了组件定义接口，使用户开发出自己的组件。(4)采用本体系容易实现瘦客户端。一些简单的逻辑判别可在客户端直接完成，比如采用Script语言提供验证机制。这些特点为在手机上实现快速网络浏览器提供了捷径。
5 结束语
本文采用科泰公司的CAR构件技术在和欣操作系统上实现了一代新的网络开发架构。该体系中的一些简单业务逻辑可以以Script的形式直接嵌套在客户端代码中。另外本架构采用了清晰的分层概念，使得开发和调试更加快捷方便。借助CAR构件的元数据和自描述信息，在“和欣”操作系统上使用JavaScript、Ruby等脚本语言和XML文件动态地编写图形界面成为可能。使用构件化的方法开发图形系统也可以推广到其他支持构件的操作系统上。
下一步的工作是完善系统的构件粒度划分，同时优化各步算法，以提高Car Faces系统的效率。
注：本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。
关键词：嵌入式系统；Web容器；构件技术；和欣
0 引言
基于构件的软件工程是实现高生产率、低维护费用和高可靠软件产品的关键技术，在这种工程模式下，按照一定的架构把构件组装起来成为软件开发的核心工作。目前绝大多数传统的嵌入式应用仍然是采用强类型的系统编程语言(比如c和Java等)来完成对构件的组装。对于一个应用程序仅需改变应用的表现层，而不必大量修改构件功能的情况，传统开发模式所要经过的修改一编译一运行的过程就显得效率低下，开发周期长和不能随需求灵活变化的弱点就暴露了出来；另外，采用强类型语言来实现功能构件并将这些构件组装成应用程序，将造成构件之间的强耦合关系，会使得开发维护的难度加大。
为了实现构件问的松散耦合，提高开发维护的效率和适应需求变化的能力，有必要在应用的开发中引入新的开发模式，采用新的构件组装技术来适应新形势的发展。考虑到脚本语言的语法简单、功能强大、易学易用的特点，本文基于CAR构件技术，提出了新的XML+CAR+其他脚本语言(Javascript、Ruby等)的Car Faces编程范式，实现了更为灵活的构件组装机制，为在“和欣”上的应用开发提供了更加快速、灵活的编程范式。另外，手机上网已成为一种潮流，采用原始的模型势必导致服务器高负载运转，所以也需要一种新的架构模式，用来解决手机上网所带来的新问题。
1 构件技术及“和欣”操作系统
构件技术是在面向对象技术的基础上发展起来的。面向对象技术通过类的封装和继承成功实现了代码级的复用。类的封装性，实现数据抽象和信息隐蔽；而类的继承，提高了代码复用性。但是面向对象的复用脱离不了代码复用的本质，对象之间的关系在编译时被固定，模块之间的关系是静态的，无法解决软件动态升级和软件模块动态替换。
构件技术通过二进制的封装以及动态链接技术解决软件的动态升级和软件的动态替换问题。面向构件技术对一组类的组合进行封装，它代表完成一个或多个功能的特定服务，同时为用户提供多个接口。整个构件隐藏了具体的实现，只用接口提供服务。这样，在不同层次上，构件均可以将底层多个逻辑组合成高层次上的粒度更大的新构件。构件之间通过约定的接口进行数据交换和信息传递，构件的位置是相互透明的，可以在同一个用户进程空间，也可以在不同的用户进程空间，甚至在不同的机器上；而且不同的构件可以用不同的语言编写，只要它们符合事先约定的构件规范。
“和欣”操作系统是科泰世纪公司开发的具有自主知识产权、基于微内核和构件技术，支持构件化应用的嵌入式操作系统。“和欣”操作系统对CAR构件技术提供了内置的支持。
CAR构件技术是面向构件编程的编程模型。它规定了一组构件间相互调用的标准，使得二进制构件能够自描述，能够在运行时动态链接，进行系统升级的时候也只需要升级相关的构件即可，具有可靠性、容错性、安全性，代表了软件工厂化生产的方向。
2 构件化Car Faces的设计
为了能满足新的需求，如图1所示，整个系统的服务器端分为四层：呈现层、导行层、验证层和业务处理层。另外，底层采用Car构件支撑各个环节的运行和交互。
图1 Car Faces业务逻辑架构
其中，呈现层实现视图的相互转换：(1)将页面提交的html代码还原成Car Faces树，并以xml树形格式呈现。同时这一层负责将树上的各节点值或组件与后台支撑的Car构件动态绑定。(2)将页面导行系统提交的Car Faces树转换成html代码表示，整个系统通过这一层实现服务器和客户的直接交互。
当呈现层从客户端接收完数据并转化成Car Faces代码后，就将转换结果递交到验证层。验证层从树的根结点遍历整棵树并调用绑定到各结点的相应的验证程序。如果一旦遇到错误信息，验证程序将把所得到的错误信息排队。验证结束后根据决策代码决定是否向下层提交或者直接调用Response．finish()将错误信息呈现给客户端。验证过程中，我们可以调用默认程序EzValidate，也可以调用用户自定义为结点绑定的验证程序。验证程序的实现，也是通过调用各后台支撑Car构件来完成的。
如果验证程序验证结束，将进入业务处理模块。在这一模块中我们定义了许多业务Car构件，通过调用业务Car构件的应用程序，可以完成对用户数据的处理。业务处理模块根据客户端产生的事件调用相应的业务处理程序，最终得到处理结果。处理完成后将处理结果提交业务导行模块。
导行层次是为客户呈现具体页面而设计的。在这一层里，我们通过业务层的运行结果或者错误信息选择适当的页面信息返回给客户。用户根据返回信息可以知道操作的结果。
所以在整个架构的设计过程中，构件容器占据着至关重要的作用。
3 Car Faces生命周期
图2为我们展示了car Faces请求响应的生命周期。
图2 Car Faces生命周期
接到客户端的请求后，首先将请求视图转换为Car Faces树状视图。在转换过程中可能会出现转换异常现象。当发生了异常后，应用程序捕获异常，根据错误类型作相应的处理。
呈现结束后，根据转换的结果树的值动态绑定到相应的构件上，并在此作一些初步处理。
上面两步完成后，生命周期将进入下一个阶段：验证处理阶段。在验证处理阶段将对Car Faces视图的每个结点实行验证处理。一旦出现错误，处理程序立即捕获错误，并根据错误类型实施相应的处理。
以上各阶段工作完成后，将进行的就是核心工作：业务处理。业务处理调用业务处理程序对转换后的数据进行相应的处理，进而达到为客户服务的目的。在这一阶段也可能会有意想不到的异常发生。一旦发生异常，将有异常处理程序做相应的处理。
业务处理完毕后，处理结果树被递交给页面导行。页面导行根据业务处理结果做出抉择，最终确定要向用户返回哪个页面。
上面所有处理完成后，Car Faces生命周期也进入了最后的阶段：页面呈现。在这一阶段，将根据页面导行程序所递交的结果对结果树实施页面呈现。同时，服务器端各种组件给用户呈现可识别代码，最终以html代码的形式返回给客户。
4 Car Faces在“和欣”上的实现
完整的Car Faces架构可以表示为图3
图3 Car Faces系统架构
(1)最外层是Car Faces运行环境(Runtime)，负责初始化和释放Car Faces应用所需资源。
(2)内部顶层是脚本语言及其配套设施。这一层相当于提供了对MVC中View的支持。
XML／JavaScriptt/Other Scripts提供了多种描述Car Faces应用的形式，让开发人员能够灵活利用各种脚本语言的优势。
(3)SCI(script Callable Interface)是脚本语言与CAR构件系统通信的桥梁。这一层相当于提供了对MVC中Controller的支持。
(4)CFSTL(Car Faces Standard Tag Library)是Car Faces提供的标准标签库，其中Car Faces提供了标准的自定义组件。CTL(Custom Tag Library)是用户自定义标签库。页面设计人员能够使用这两个标签库所提供的标签。
(5)CAR构件系统。它是服务的提供者。这一层相当于提供了对MVC中Model的支持。在这一层，实现了各种Car构件。这些构件支持着上层的业务逻辑能够顺畅运行。
本Car Faces架构集成了XML-GIue特点。
通过以上论述，可以看出使用Car Faces具有诸多优点：(1)Car构件直接运行在本地机器上，某些操作甚至可以直接控制硬件，所以其速度相对较快。(2)Car Faces实现了清晰的分层概念，不像AJXA只局限于技术的实现。(3)组件的可扩展性好。在本系统中，提供了许多标准组件，但同时也给用户提供了组件定义接口，使用户开发出自己的组件。(4)采用本体系容易实现瘦客户端。一些简单的逻辑判别可在客户端直接完成，比如采用Script语言提供验证机制。这些特点为在手机上实现快速网络浏览器提供了捷径。
5 结束语
本文采用科泰公司的CAR构件技术在和欣操作系统上实现了一代新的网络开发架构。该体系中的一些简单业务逻辑可以以Script的形式直接嵌套在客户端代码中。另外本架构采用了清晰的分层概念，使得开发和调试更加快捷方便。借助CAR构件的元数据和自描述信息，在“和欣”操作系统上使用JavaScript、Ruby等脚本语言和XML文件动态地编写图形界面成为可能。使用构件化的方法开发图形系统也可以推广到其他支持构件的操作系统上。
下一步的工作是完善系统的构件粒度划分，同时优化各步算法，以提高Car Faces系统的效率。
注：本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。