CN108415689A - 基于泛在对象三段式装配的软件构成方法 - Google Patents

基于泛在对象三段式装配的软件构成方法 Download PDF

Info

Publication number
CN108415689A
CN108415689A CN201810176975.8A CN201810176975A CN108415689A CN 108415689 A CN108415689 A CN 108415689A CN 201810176975 A CN201810176975 A CN 201810176975A CN 108415689 A CN108415689 A CN 108415689A
Authority
CN
China
Prior art keywords
piece supplying
user
service
data
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201810176975.8A
Other languages
English (en)
Inventor
齐德昱
汪秀敏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to CN201810176975.8A priority Critical patent/CN108415689A/zh
Publication of CN108415689A publication Critical patent/CN108415689A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种计算机系统的构成方法，将软件的构件归纳为供件、求件与挂件三类，支持用户基于这三种构件进行“R‑AAS‑AS”的三段式装配，构成以“中央厨房”模式工作的计算机系统，实现包括软件与服务、仪器设备及数据资源等在内的泛在对象的模型化的动态装配、互操作与聚合式的扩展。供件是物联对象的操作访问代理与业务逻辑装配模型，挂件是描述用户需求逻辑的模块，求件是用户访问供件的支撑环境。该方法也用于实现我们给出的“基于形式领域融合的计算模式”（简称“格件”）中的纵向融合，同时也作为我们给出的EIO框架的一种实现方法。该方法可使“物联网+”的开发模型化，实现系统动态扩展，提高开发效率与系统可靠性。

Description

基于泛在对象三段式装配的软件构成方法
技术领域
本发明属于软件工程领域，涉及软件体系结构、软件开发方法及其支撑环境与工具。
背景技术
软件开发方法属于软件工程领域，因为它是大型计算机应用系统开发所必须使用的方法与支撑技术，所以一直是计算机科学与技术学科的研究重点。
软件开发方法是在算法与数据结构之上的软件构造方法，包括方法学与方法两个层面。在方法层面，具体研究研究开发所需的思维方式、问题解决方式和支撑环境与工具等方面。不同的开发方法，可能导致不同的软件结构，因此，软件结构/框架/体系也与开发方法密切相关。从另一方面考虑，不同结构与体系的软件，需要采用不同的方法去构造，所以，软件结构与开发方法往往是同一个问题。
随着计算机网络技术的发展，应用程序的结构以分布式为主。最早的分布式结构是客户-服务（C-S）模式，将应用程序视为由两个部分组成：处理客户交互的客户端与处理业务逻辑的服务端。随着应用的深入，出现了多层客户-服务模式，进一步将客户端和服务端分成多个部分，各部分之间的交互成线性关系。在客户服务模式中，服务端和客户端的各个部分分担的功能一般没有明确的统一规定，但有瘦客户和肥客户之说，“胖”与“瘦”相应的端分担的功能多少。
随着WEB浏览器的应用，出现了一种新的客户服务模式：浏览器-服务器（B-S）模式。该模式与一般的客户-服务模式的主要区别是客户端是WEB浏览器，而且客户端与服务端之间的通信是HTTM协议，通信的内容是HTML文件。因为客户端只需安装用的WEB浏览器，所以，在用户看来，客户端很“瘦”。相比B-S模式，其他C-S一般没有统一的规范。
在C-S模式中，有一个重要的软件成分：应用服务器。应用服务器是指这样一种计算机软件，它以服务的模式运行，通过规定的协议把用户业务曝露给客户端的程序，供客户端通过该应用服务器访问业务逻辑。这里，以服务模式运行是指该软件启动后处于监听状态，一直监听来自客户的服务消息，并且解释消息与触发消息的执行，回送消息执行的结果。
应用服务器实质上是实现C-S 模式的支撑环境，也称运行时。因此，应用服务器是C-S模式的关键。应用服务器一般定义下列几个方面功能：
客户与服务器的消息通信传输协议；
消息格式；
消息执行机制；
对于B-S模式，应用服务器的功能与协议确定的，符合HTTP规范，称为HTTP应用服务器，或者HTTP Server。目前有多种产品包含HTTP应用服务器的规范，但不限于HTTP规范，常见的产品有Apache的Tomcat、IBM的websphere、Caucho Technology的Resin、Macromedia的JRun、NEC WebOTX Application Server、JBoss Application Server、BEA的WebLogic等。其中许多产品如NEC WebOTX Application Server、WebLogic、WebSphere，不仅仅是Servlet容器，它们也提供对EJB(Enterprise JavaBeans)、JMS(Java Message Service)以及其他Java EE技术的支持。
Java Servlet（Java服务器小程序）是一个基于Java技术的Web组件，运行在服务器端，它由Servlet容器所管理，用于生成动态的内容。 Servlet是平台独立的Java类，编写一个Servlet，实际上就是按照Servlet规范编写一个Java类。Servlet被编译为平台独立的字节码，可以被动态地加载到支持Java技术的Web服务器中运行。
HTTP服务器中，有一个重要的功能，称为Servlet容器或者Servlet引擎，它的功能是执行与管理服务端的Java小程序，称为Servlet小程序。Servlet小程序的实例化与调用、生命周期管理、多线程控制等事务，均由Servlet容器负责。Servlet容器具有预定义的方法供用户扩展，如doGet()和doPost()。
与HTTP相关的另一种客户端编程支撑环境是AJAX（Asynchronous JavaScriptand XML）。AJAX的核心技术是对象XMLHttpRequest。该对象支持用户在客户端使用WEB脚本语言使用HTTP进行通信，亦即AJAX相当于在客户端提供了一个HTTP引擎。AJAX支持回调函数，是HTTP的服务请求功能的返回结果可以通过该回调函数处理。XMLHttpRequest的主要方法有open和send。其中open由于定义HTTP通信的参数，send由于发送HTTP请求到服务器。由于回调函数的使用，客户端程序可以无需等待服务端返回结果而处理其他事务，所以人们称其为异步技术。
AJAX虽然在客户端提供了而一个类似于服务器的AJAX引擎，但它的主要功能是充当HTTP的访问代理，针对的服务端是HTTP服务器，传输的数据也仅限于文本类数据（含超文本）。
应用服务器中，还有一种JavaEE相关的应用服务器，称为JavaEE应用服务器。广义的JavaEE 应用服务器包括四种容器： Web/Servlet容器、客户端小程序 Applet容器、客户端Application Client容器、EJB容器。其中用作服务端的只有Web/ Servlet容器和EJB容器，而Web/ Servlett容器是属于HTTP应用服务器的规范。因此，JavaEE应用服务器中，最重要的是EJB容器。
EJB容器用于支持客户端访问服务端功能，与Servlet容器类似。EJB容器支持的程序模块是EJB（Enterprise Java Beans）组件，是一种Java对象，客户端采用RMI/IIOP访问EIB。访问的模式是RMI/IIOP，就调用方式而言类似于本地对象调用。
目前的这两类应用服务器，存在下列主要问题：
关于HTTP服务器：
--采用无连接的HTTP协议，对许多应用存在效率低下、使用不方便的问题；
-- HTTP是超文本传输协议，传输的内容是文本，不适合二进制数据传输，应用范围受到很大限制；
--ServLet的调用机制不灵活，主要采用doGet()和doPost()触发应用程序，基本没有模型，自由度大，不利用编写规范的代码。
关于JavaEE服务器：
--主要针对EJB组件，缺乏灵活性；
--客户端程序与EJB远程调用捆绑在一起，类似与本地访问组件，使服务端与客户端程序紧耦合；
--客户端的调用EJB的程序复杂读高，所以导致了许多轻量级的JavaEE框架；
另外一方面，目前尚有的应用服务器，都不适合支持“物联网+”（物联网应用系统）开发。在物联网应用中，客户端主要是物联对象，这与在“互联网+”中客户段主要是计算机终端（PC或者移动客户端）不同。物联对象除了物联网互联对象外，还增加了仪器设备。这些仪器设备由于成本、节能与适应使用环境方面的考虑，大多是低计算能力的设备，联网方式也是低成本方式，比如，蓝牙、红外、射频。因此，客户端的这种变化，使得传统的应用服务器不能适用。传统的应用服务器，都是假设客户端具有PC级或者智能终端级的计算能力与联网能力，因此，在通信协议与客户端程序方面，都不能适用与物联网的物联对象，寻求适合物联网的应用服务器成为迫切寻求。
此外，这些物联对象的重点也不像互联网中计算机主机那样提供计算能力与存储能力，而是这些设备或者接口具备基本的网络通信功能，更重要的是，这些对象连入网络的目的与计算机主机有很大不同，重点是对象的远程控制、状态监测与数据交换。面向这类目的的网络应用系统称为“物联网+”系统。从“互联网+”到“物联网+”，应用开发方法需要做及时调整，需要有更适合物联网对象的交互方法与协议支持。本发明的目的之一就是针对该问题的，给出一种可以归纳物联网应用开发的基于通信协议的通用的物联网对象连入方法。
在未来的物联网应用中，物联网对象协同将成为热点。目前的物联网应用，主要是一个个独立物联网对象进行操作访问，例如，集散控制系统，远程控制系统。随着物联网应用的深入与云制造的深化与扩展，物联网对象的协同成为主流。这种协同可以是一个系统内的物联网对象协同，例如，工厂流水线控制；也可以是系统之间的协同，多个不同系统之间的网络制造。这类物联网应用，不仅要求物联网对象的标准化接入，而且要求物联网对象的标准化模型化的协同。本发明的另一个目的就是针对这种问题的，提出一种基于物联网对象（泛在对象）的聚合扩展的物联网对象交互模型，为高级“物联网+”的开发提供高效的方法与支撑环境与工具。
发明内容
一、方法概述
本发明给出一种面向软件开发与运行的支撑方法与体系，用于开发与运行支撑包括“物联网+”在内的“客户-服务”模式的计算机应用系统，同时也是一种基于泛在对象/服务互操作(USI：Ubiquitous Services Interactive)的软件体系与开发方法，支持以“中央厨房”模式构造软件。该方法也用于实现我们提出的“基于形式领域融合的计算模式”（简称“格件”）中的纵向融合，同时也作为我们提出的EIO框架的一种实现方法。
这里，“物联网+”是指基于物联网的应用系统，是对基本物联网的面向具体应用的扩展；泛在对象是包括人、物、仪器设备、计算机软件、软件服务、数据存储等。所给出的方法及其支撑体系，是一种新的软件构造方法，目的是使“物联网+”的开发模型化，提高开发效率与所开发的系统的可靠性。
本发明通过给出一套独特的软件开发与运行的支撑环境体系确定了一种新的软件开发方法。该方法的核心是将一个软件看作由六大部分组成：前端UI组装UIA（UIAssemble）、前端事件处理FEE（Front Event Engine）、前端通信处理FCE(FrontCommunication Engine)、后端通信处理(Back Communication Engine)、后端事件处理BEE（Back Event Engine）、后端服务组装BSA（Back Service Assemble）。该六部分构成新的“客户-服务”模式：C(UIA-FEE/FCE)-S(BCE/BEE-BSA).
所给出的方法与体系，从功能方面看，包括三个方面，一是面向“物联网+”的应用服务器模型USIP（Ubiquitous Services Interactive Platform）；二是包含物联网对象在内的泛在对象的连接与操作访问模型，三是泛在对象的扩展与协同模型。泛在对象的连接与操作访问是物联网构造的基本要求，而泛在对象的扩展与协同，是构造基于物联网的网络协同系统、综合控制系统以及广义的云制造系统的基础。
上述方法与体系的实现，引入软件构造成分“供件”、“挂件”与“求件”。
■供件(OAA)：为运行时软件模块，主要充当对象访问代理，主要功能是收发消息/数据、消息处理调度、事件管理、PIP容器。供件英文简称OAA(Object Access Agent)。OAA的网络通信功能称为OAA通信协议。用于构成FCE、FEE、BCE和BEE
■挂件（PIP）：一种规范化了的软件模块，逻辑上挂接到OAA，供OAA驱动调用。英文简称PIP(Plug-in Processor);用做软件的业务逻辑组件，实现BSA和UIA。
■求件(OAI)：是用户程序访问供件的接口（API），属于供件驱动器，英文简称OAI（Object Access Interfaces），用做UIA的实现。
供件方法支持泛在对象基于这三种构件进行互操作，从而构成应用系统。
USIP的使用，有三类模式：直接交互C-C，基于数据交互C-S-D和基于服务器交互C-S-C.
C-C模式：客户之间直接交互，此时，需要客户在自己的应用程序中使用OAI。称使用OAI的程序为“OAI程序”；
C-S-D模式：此时，S为OAA，C 为OAI程序，D是数据库与其他数据资源。C之间不直接通信与交互，只通过操作D建立通信与交互；
C-S-C模式：客户之间的通信与交互通过服务器S进行，此时S兼做消息传递服务器，这里，C是OAI程序，S是OAA。
这里，C-S-C与C-S-D的主要区别是C-S-D中，各个客户C只通过共享D实现交互，不发生基于名字的交互，而在C-S-C，各个客户C也可以进行基于名字的交互。
一个泛在对象要基于供件连入网络，有两种方式：代理方式和直接方式。直接方式要求泛在对象支持网络通信，并且可以将OAA或者 OAI嵌入运行；代理方式是设置一个支持网络通信和OAA或者OAI运行的设备，称为代理设备，该设备一方面负责通过OAA或者OAI连入网络，一方面负责与泛在对象交互。代理方式的典型例子是指通过智能遥控器控制家电，此时遥控器作为代理设备。这里，智能遥控器是指支持网络通信并且可以运行OAA或者OAI的遥控器。代理方式针对无或者弱计算与联网能力的泛在对象。
供件以消息服务与事件驱动模式工作。消息服务是指供件负责收发供件规范的消息（供件消息）；事件驱动是指，供件自动检测用户和系统预定义的事件处理子程序挂件的触发条件，当满足时自动执行相应的事件处理子程序挂件。触发条件是系统状态变量与用户自定义状态变量的逻辑表达式。系统状态变量包括消息到达、消息发出、时间到达等。
挂件的执行空间，可以是与供件相同的进程空间，也可以是远程进程。供件消息中包含了调用挂件的所需的消息定位与执行参数。供件收发的消息，可以是任意对象，当然也包括供件自己的挂件。
供件客户端程序基于OAI实现。供件的客户有两种：OAI和OAA，即OAI访问 OAA或者OAA访问其他OAA(含USIP服务器)。相应地，一个客户端程序的结构为“OAI-绑定OAA-外部OAA”。绑定OAA是与OAI驻留在同一个进程空间内的OAA，而外部OAA是独立于OAI所在进程的OAA。这种模式称为“C-ES-S”模式，即“客户-绑定服务-远程访问”模式。
OAA客户与OAA的交互的方式有两种：注入与抽取。注入是由客户端向其他泛在对象发送消息或者数据，抽取是客户端从其他泛在对象获取消息或者数据。客户端响应消息处理结果的机制包括两个方面的配合：A)消息发送方：编写消息响应子程序，作为挂件挂接到供件；B）消息处理方：处理消息后，发送响应消息给供件，供件收到后会自动启动相应的消息处理子程序。
供件的客户端对供件的服务请求，都需要封装为指定格式的消息，然后通过OAA协议发送到供件。服务请求消息中包含回信模板，定义了返回结果的应该包含的对象及其组织格式、结果返回方式（自动返回、通知返回）以及返回时限。其中，返回时限实现实时通信，自动返回是服务请求结果生成后即自动回送结果，而通知返回是客户需求获取结果时通过取信指令通知供件自动返回。
每种供件都是一种模型，用户在模型上填充自己的业务逻辑后形成供件实体。只有供件实体才能工作。
求件充当供件的客户端，一般为应用系统编程环境下的一套API，实现API调用到消息传递的转化，支持使用者通过本地调用API实现对供件的服务请求。
由于泛在对象代表了可通过数据通信端口接入到供件的所有对象，因此，该方法实质上是一种基于泛在对象交互的软件体系，可以实现数据、仪器设备、计算机、软件服务、软件代码库、数据库等对象的交互、协同与扩展。
一个典型OAA称为USIP服务器（US）。US作为一种应用服务器，主要负责客户管理、消息传输、消息处理调度、PIP容器等功能，概述如下：
■客户管理：管理可以访问自己的客户，包括账户、访问控制策略等
■消息传输：采用我们自己提出的抽注传输协议EITP，兼顾大块数据与多种信息机制传输，基于电报模式，收发双方都可以随意监听与发送；
■消息定义：定义消息（指令的语法与语义）。消息用于描述用户调用或者驱动服务端程序模块PIP的逻辑，无其他语义，具体的消息所完成的语义是有消息调用的程序模块决定的。
■容器机制：USIP的容器是对PIP的运行进行管理的机构，基于事件驱动工作，主要职责是根据消息的要求产生PIP的实例，并且控制PIP的生命周期。
二、供件网模型
供件网是一种逻辑网，基于OAA、OAI和PIP将多个泛在对象互联起来，支持泛在对象互操作。供件网的主要目的是提供一种创建分布式泛在对象互联方式，以支持泛在对象的分布自治、分布管理与分布交互。参见图1.
一个供件网是一个二部多重图G=(V,E)，它满足下列条件：G是一个无向图，如果顶点V可分割为n个互不相交的子集序列V1,V2, …,Vn, 并且,对u∈Vi, v∈Vi, 则不存在(u,v)∈E,且如果(u,k)∈E, u∈Vi，则或者k∈Vi+1，或者k∈Vi-1,这里i=1,2,…n。每个Vi主体是OAA或者OAI，也包括相关的PIP及其关联的泛在对象UO，OAA、OAI和PIP的运行环境统称泛在供件“容器”。
二部多重图实质上是多个“相邻”的二部图（Bipartite Graph）。每个二部图中的每条边所关联的两个顶点分别属于这两个不同的顶点集。
二部图描述能力介于无限制的网络与树之间。之所以选择二部多重图为供件网体系，是我们理论分析获知，将共享关系限制在二部图关系下，大多数共享关系描述不受影响，但资源共享引起的死锁的概率可大幅度降低。
供件的主要功能是作为物联对象的操作访问代理，并实现泛在对象的分布式互操作。此外，供件还支持泛在对象的扩展。当一个供件网节点下联了其他几个供件网节点时，在逻辑上该供件网节点“扩展”了它所下联的节点，实现泛在对象聚合式的扩展，形成新的对象。
供件网的应用模式参见图3和图4。
三、供件模型访问界面
供件模型是一个可由用户配置与扩充的计算机软件框架。用户通过参数设置或者将自己编写的软件代码（挂件）挂接在框架上（也称填充模型），形成一个具体的供件，作为用户自己的对象的服务与控制代理。
供件模型分固定部分与活动部分。固定部分是模型的框架，由系统给定，包括运行时和代码库两种。活动部分是填充到框架中的用户代码与配置数据。供件模型的规范，定义了模型的框架的体系、框架的功能接口、填充与挂接方式以及配置参数等方面。
一个供件从用户功能角度分为面板与供体两部分。面板为用户接口，求件是通过面板来操作使用供件的。供体负责实现面板，是计算机软件或者硬件系统。供件的运行环境称为供件的容器。
供件的面板包括控制板和端口。控制板面向物联网设备的控制，由电子命令按钮组成，使用者通过网络连接触发这些按钮，来控制物联对象。控制板的按钮代表的命令是一些不需要参数的命令，包括标准按钮与用户扩展按钮两类。标准按钮由系统预定义，主要包括启动、停止、暂停、恢复，均针对物联对象的控制。用户扩展按钮由用户自定义，使用方式同标准按钮,包括命令与状态两种，其中，命令按钮用于向物联对象发送非标准的控制命令，而状态按钮用于读取物联对象的状态。
面板的端口以服务的模式工作，求件通过向端口发送服务请求指令获得服务。端口有四种，分别称为管理端口、广播端口、指令端口、状态端口与回信端口，其中指令端口是每个供件都必须提供的，其他端口可以根据需求选择提供。
供件的指令端口，用于求件向供件以消息方式发送参数化的控制指令与服务请求指令。指令的执行的状态与结果，根据指令的不同可以返回到回信端口，由专门的读取指令获取，也可以由供件直接回送给消息请求者。指令端口的服务请求指令包含标准服务请求指令与用户自定义服务请求指令。标准服务请求指令由系统预定义，每种供件必须实现。用户定义服务请求指令是供件提供者根据供件自身的特点与服务需求确定的服务指令，格式是标准化的，但内容是有用户自定义的挂件确定。
标准服务请求指令包括各种标准数据结构的数据读、数据写、数据更新、数据删除等。支持的数据结构有关系数据库、GriDoc文档、OS文件等。
管理端口用于供件的提供者通过改变节点参数定义和配置节点的行为与功能。主要的配置参数有用户账户、访问控制参数、连接控制参数、服务质量控制参数、实时参数、远程时间配置以及节点功能选择参数等。
广播端口用于节点主动发布关于节点与节点关联的对象的工作状态信息、公共服务数据与信息等。工作状态信息包括服务范围与限制、公告信息、运行状态以及用户访问受理与处理状态。每种广播消息属于一个系统定义的频道。用户通过收听指定频道的信息获取广播消息。用户端的OAA通过订阅功能获取广播。
回信端口用于传输客户端所请求的数据。用户通过向该端口发送取信指令实现服务请求结果的获取。
状态端口供用户读取供件的工作状态、服务范围等信息。
四、供件功能分层分级
为适合不同的应用场合，供件功能分为三个层次级别：事件驱动级(OAA-1)、网络通信级(OAA-2)和管理级(OAA-3)。
OAA-1:事件驱动级，支持事件驱动的软件模块执行。主体功能是事件驱动。该级OAA启动后监听用户与系统定义的事件，发现事件发生后，驱动相应的挂件。事件定义由用户在事件映射文件中定义。
OAA-2：网络通信级，在OAA-1上增加网络通信（消息与数据收发）功能，包括两个方面的通信功能：A)接收网络消息：不断监听网络通信，发现合法的OAA消息后，接收消息，并且形成一条消息达到事件；B）发送网络消息：支持用户构造自己的网络发送事件，供系统的事件驱动机构处理该事件，驱动网络发送线程，以完成网络发送。该级OAA具有网络通信必须的名字服务、用户账户与访问控制等功能。
OAA-3：管理级。在OAA-2基础上增加供件管理功能，即供件的远程管理：端口功能。
OAA-1级是供件的最轻量级，一般用在编写无网络通信的或者网络通信不依赖OAA的事件驱动模式的软件。例如，采用OAA-1的JS版编写B-S程序，客户端程序的通信采用HTTP，而客户端的处理采用OAA-1的事件驱动机制。
五、供件指令模型
供件以服务的模式工作，供件的用户通过向供件发送供件指令获取供件服务。网络上的任何对象，只要与供件的通信端口具有相同的通信协议，都可以向供件发送供件的服务请求指令以获得服务。但这种通信规程比较复杂，所以一般都采用OAI实现OAA的服务请求，因为OAI将服务请求的实现过程已经包装在内部了。
这里定义指令的消息模型，具体的指令则由供件的提供者在该指令模型框架下确定。这里以BNF语言定义指令。
（1）消息传输模式
供件消息/指令传输为“电报”模式采用OAA协议。OAA协议是一种电报模式的通信协议，会话的一方将服务请求信息或者传输信息送达会话的另一方，而不等待回复即完成会话。这种模式要求会话双方都可以收发电报，即都可以作为客户或者服务器。
（2）通信对象命名
一个供件在网络上有一个唯一的标识，用于在指令中指称该供件。这里采用URI命名方法：
agentLocater::= [scheme:] <schemeSpecificPart>
<schemeSpecificPart>:= <chemeSpecificPart1>"#"<agentID>
agentID::=字母打头的字母数字串
chemeSpecificPart1::=URI定义中的符号“#”的前面部分
说明：同一个schemeSpecificPart1下不容许有相同的agentID。
(3)访问控制与账户
每个供件都设有一个访问规则表以及一个账户表。
访问规则表是供件的第一层保护规则。对于每个收到的访问消息或者其他访问连接，供件首先检查该规则，符合的才接收消息，并加入账户验证。账户验证基于账户表。
每个访问供件的对象，都必须先在该供件上创建一个访问账户。账户包括账户名称、口令以及访问权限。供件默认有一个过客账户，无口令，但权限受限。
如果供件没有访问规则表，则供件不对输入的消息进行检查；如果没有账户表，则不对消息进行身份认证。
每个访问供件的消息，都必须提供自己的账户与口令。
（3）端口指令模式
供件的端口指令的一般形式定义为：
供件端口指令::= <operation> [operationAdditional] < messageNo>
< agentLocatorFrom> < agentLocatorTo> < permit > [parameters] [resRequs]
operation::= <operationID> | <operationID> "-S"
operationID ::= <端口指令标识符>
端口指令标识符 ::= "Extract" | "Inject" | "Inject-Respond " | "EI" | "IE"
operationAdditional::=<附加命令标识符>
agentLocatorFrom::=<指令发送者标识符>
agentLocatorTo::=<所操作访问的供件的标识符>
permit::= <accountID> "," <passwordID>
accountID::=<用户账号>
passwordID::=<加密的用户口令>
parameters::= < parameter> {", " parameters}
parameter::=<指令参数>
resRequs::= <resRequ> ", " { resRequs }
messageNo::=<消息序号,整数>
若干说明：
指令操作符后接"-S"时表示加密消息传输。此时，系统在输出消息前，自动与消息接收方协商一个会话秘钥，并用该秘钥加密消息和解密消息。
accountID是用户在相应的供件上开设的账户的账户名称，passwordID是对应的口令
agentLocatorFrom是消息发送者的对象标识；agentLocatorTo是消息接收者的对象标识。它们都满足供件标识规范。
parameters是指令参数。参数如果有多个，则用逗号分隔。对不同的指令，参数形式与含义可以有所不同。指令参数也可以是服务请求所需的数据。
resRequs是描述指令响应需求的。每个resRequ是一个键值对“关键字:值”。键值对由系统预定义和用户自定义两种。在1.0版本中，系统预定义的有下列几种：
TimeLimit:毫秒数—指出供件的响应时限；在规定的时间内完成处理
ResMode:Timely/ Inform–值为“Timely”表示及时响应，即完成请求处理后即自动发响应消息；值为“Inform”表示通知响应，即收到回送响应消息后回送响应消息。
operationAdditional用于进一步说明命令的种类，与operation一起起到命令分类的作用。
通行卡permit由用户账号ID与账户口令组成。每个访问供件的消息，都必须持有一个通行卡。通行卡由消息发送者提供，由消息接收者验证使用。消息接收者收到消息后，检查所提供的通信卡上的身份与权限是否符合该消息执行的要求。通行卡上的信息包括账户和账户口令。其中口令是在消息发出前由系统加时间戳后的散列值。
messageNo是消息序号，为整数值，用64位二进制数描述，是自2017年1月1日零时起的到发信息时的毫秒数。供件的每个消息，都有一个相应的消息序号标识。消息序号由消息请求者生成，如果同一时间有多个消息生成，则按生成先后次序，后面的每个消息都是在前一个基础上加1.
指令中各个成分用空格作为分隔符；当一个成分里需要出现空格时，需要用单引号或者双引号括起来，亦即，最外层引号可以作为成分分隔符，但内层引号不做成分分隔符
六、指令语义定义
这里给出指令的语义的定义。指令的语法同前所述。
(1)抽取指令
基本功能：用于向指定供件传达用户（指令发送者）的服务与资源请求消息。
格式：Extract [operationAdditional] < messageNo>
< agentLocatorFrom> < agentLocatorTo> < permit > [parameters] [resRequs]
说明：
< agentLocatorFrom> < agentLocatorTo>分别指出请求者与被请求者的标识；
Parameters是参数序列，其中第一个参数是“抽取描述符”，用于描述抽取逻辑，包括抽取方式与源。
(2)注入指令
基本功能：用于向指定供件注入数据。
格式：Inject [operationAdditional] < messageNo>
< agentLocatorFrom> < agentLocatorTo> < permit > [parameters] [resRequs]
说明：
< agentLocatorFrom> < agentLocatorTo>分别指出注入的执行者与被注入者的标识；
Parameters是参数序列，其中第一个参数是“注入描述符”，描述了注入方式与对象，其他参数是欲注入的数据。
(3)响应注入指令
基本功能：用于向指定供件注入回应数据。
格式：Inject-Respond [operationAdditional] < messageNo>
< agentLocatorFrom> < agentLocatorTo> < permit > [parameters] [resRequs]
说明：
< agentLocatorFrom> < agentLocatorTo>分别指出注入的执行者与被注入者的标识；
该指令实现“反向注入”，即向此前发送指令的供件agentLocatorTo回送抽取结果或者执行状态。供件agentLocatorTo收到该指令后，将触发一个响应到达事件，以通知供件获取响应信息。
Parameters是参数序列，其中第一个参数是“注入描述符”，描述了注入方式与对象，其他参数是欲注入的数据。
(4)抽注指令
基本功能：用于向指定供件传达用户（指令发送者）的服务与资源请求消息，并且在完成请求后，执行数据注入。
格式：EI [operationAdditional] < messageNo>
< agentLocatorFrom> < agentLocatorTo> < permit > [parameters] [resRequs]
说明：
< agentLocatorFrom> < agentLocatorTo>分别指出请求者与被请求者的标识；
Parameters是参数序列，其中第一个参数是“抽取描述符”，用于描述抽取逻辑，包括抽取方式与源。第二个参数是“注入描述符”，描述了注入方式与对象以及注入数据起点（在该参数中的相对位置），其他参数，从第三个起依次分别为抽取参数与注入数据，分界点用“注入描述符”中的数据起点指示。
(5)注抽指令
基本功能：用于向指定供件注入数据，并且在完成注入后，执行数据抽取。
格式：IE [operationAdditional] < messageNo>
< agentLocatorFrom> < agentLocatorTo> < permit > [parameters] [resRequs]
说明：
< agentLocatorFrom> < agentLocatorTo>分别指出请求者与被请求者的标识；
Parameters是参数序列，其中第一个参数是“抽取描述符”，用于描述抽取逻辑，包括抽取方式与源。第二个参数是“注入描述符”，描述了注入方式与对象以及注入数据起点（在该参数中的相对位置），其他参数，从第三个起依次分别为抽取参数与注入数据，分界点用“注入描述符”中的数据起点指示。
七、控制面板指令
控制板指令主要功能是，启动或者停止供件对应（连接）的对象的工作；注意，一个供件可以连接多个不同的对象。
模型定义：
控制面板指令 ::= "Start" | "Stop" | "OperationExp" <operID> |
"Mode" <modeID> <objectID> | <modeInstruct>
<objectID>::=对象标识符；//供件所绑定的对象（称为“供件对象”）的标识符，字母打头的字母数字串，形式定义略
<operID> ::=整数
<modeID>::=整数
说明：
objectID：供件所连接的对象的标识符。一个供件可以连接多个对象，不同的对象定义不同的对象标识符。
Start/Stop：分别用于启动供件对象与关闭供件对象。
Mode <modeID>：使供件切换到指定的模式。模式以整数标识。对于无效的模式或者当前不可用的模式，返回状态为模式无效。
OperationExp <operID>：支持用户自定义控制命令，即扩展命令。命令名称为整数<operID>
八、求件模型
求件是访问供件的工具，对于计算机软件而言，是API，充当供件的驱动器。
从结构与体系看，每个求件都是一个供件的一个附加成分，与该供件属于同一进程空间。称该求件捆绑在该供件。
求件与其他供件的消息通信，都是通过它所捆绑的供件实现的。
供件的事件驱动的设置，也是通过捆绑到它上面的求件实现。
求件在应用程序中形式为对象：求件对象。应用程序通过求件使用供件前，先必须通过求件与供件建立逻辑连接，获取一个供件对象，此后按照面向对象的方式访问该供件。使用完毕后，则需要断开连接，释放资源。
设服务端（外部OAA）程序已经编写完成，则基于求件的客户端程序的一般构造模式为：
[1]在程序外部安装部署OAI程序模块；下面的步骤都在用户程序中编码进行。
[2]（创建OAI实例）：创建OAI对象，返回一个OAI对象实例，即OAI句柄；
[3]（绑定OAA）:通过 OAI句柄绑定与启动的OAA，并配置OAI对象绑定的OAA的属性，包括OAA级别及其他可配置参数；
[4]（连接外部OAA）:如果需要访问外部OAA对象（含USIP服务器，下同），通过OAI句柄调用连接远程OAA对象的方法，同时指定此后使用的访问账户与密码；
[5]（管理外部OAA）：如果需要并且具有外部OAA的管理权限，则根据业务逻辑的需求管理与配置远程OAA对象；
[6]（实现物联对象控制面板）：如果该客户端为物联对象控制端，则为绑定OAA编写相应的PIP实现网络对象控制，并且进行PIP映射。
[7]（动态设置本地事件处理）：如果在本地程序在采用事件驱动机制，根据业务逻辑的需要动态绑定本地事件处理，将预先编写的本地事件处理的PIP，通过所获得的OAI句柄调用求件方法，映射到绑定OAA；如果需要，可以持久化该动态绑定（即将动态事件映射写入事件映射表文件）
[8]（OAA交互）：在需要与外部OAA交互的地方，调用OAI的方法，与外部OAA进行交互，主要包括服务请求、服务结果取回、数据发送、数据获取以及其他一些操作。
[9]（断开外部OAA）:如果与外部OAA的交互完成，则断开外部OAA的连接；
[10](断开绑定OAA)：如果不需要采用OAI，则断开绑定的OAA。如果后续需要，则可按照上面的对应步骤重新连接；
[11]如果不再需要供件功能，释放OAI对象；
九、求件API模型
这里阐述“求件模型”中指出的求件API的框架与语义。具体的程序语言级的定义，依赖与所针对的编程语言，但基本框架与语义不变。
求件模型中的操作对应OAA的三级分为三类：事件操作、通信操作和管理操作。
9.1事件操作
连接操作是为后续的其他操作做程序级的准备。
（1）创建求件实例
格式：createOAI(OAI类型信息)
功能：创建一个OAI对象实例，返回对象实例句柄，以供后续的操作使用。
说明：该步骤是面向对象程序设计应用所需，创建一个OAI对象的引用变量，可使用对象工厂模式。
（2）绑定OAA
格式：bindOAA(OAI句柄，OAA设置参数)
功能：为OAI绑定一个OAA,并设置特性。设置的主要内容是绑定OAA的级别。
说明：可以将绑定OAA设置为OAA-1、OAA-2或者OAA-3；绑定的OAA与OAI代码在同一安装包。
（3）设置绑定OAA事件映射
格式：setEventEOAA(OAI句柄，事件映射表，是否持久化)
功能：为绑定OAA动态设置事件映射表。
说明：“事件映射表”是程序中的表数据结构，描述了事件的发生条件以及事件发生后需要调用的PIP。“是否持久化”指出该映射表是否写入该OAA的映射表文件。写入是采用更新与添加方式。
（3）加载绑定OAA事件映射
格式：loadEventEOAA(OAI句柄，事件映射表文件)
功能：将存于指定文件文件的事件映射表，加载到指定的绑定OAA。
说明：“事件映射表文件”是OAI约定位置的文件，描述了事件的发生条件以及事件发生后需要调用的PIP。
（4）开关绑定OAA通信
格式：setCommEOAA(OAI句柄，ON/OFF)
功能：打开/关闭指定的绑定OAA的通信功能。
说明：OAA通信功能被打开后，才可以监听网络通信，实现网络通信。OAA被绑定后，如果是OAA-2或者OAA-3，则隐含执行了打开功能。通信被关闭后，OAA不再进行网络通信，以节能或者满足特定的应用需求。关闭后可以重新被打开。
9.2操作
这类操作是求件操作的主题，实现对对关联的外部OAA服务请求。
（5）注入数据
格式：injectData(OAI句柄，数据或者数据位置，注入描述符，状态处理PIP)
功能：向OAI关联的外部OAA注入数据，并指定注入状态处理PIP。
说明：该方法向OAI关联的外部OAA注入数据。欲注入的数据的来源是“数据或者数据位置”，注入位置与方式等，由“注入描述符”确定。该方法执行后不等待执行结果即返回，具体的数据传输由绑定OAA进行。当绑定OAA获得数据传输状态后，调用指定的“状态处理PIP”。数据传输状态包括数据传输失败与成功两类。失败后还指出失败原因。指定的“状态处理PIP”只一次有效，一旦执行就取消在绑定OAA的映射。
（6）抽取数据
格式：extractData(OAI句柄，数据描述符，数据对象缓冲区，状态处理PIP)
功能：根据欲获取的数据的“数据描述符”,从OAI关联的外部OAA获取数据，并指定接收数据的缓冲区与送状态处理PIP。
说明：该方法执行后等待欲获取的数据的到达，直到数据到达或者出现异常才返回。欲获取的数据用“数据描述符”描述。数据到达后存入指定的“数据对象缓冲区”。该缓冲区的首部是传输状态标志。“状态处理PIP”用于为取数状态指定状态处理PIP，可以省缺，此时，程序员通过数据缓冲区中的状态判断取数状态并进行处理。“数据描述符”由程序员自定义，需要程序员与服务端编程配合确定含义。
（7）通知抽取数据
格式：extractDataNote(OAI句柄，数据描述符，状态处理PIP)
功能：根据欲获取的数据的“数据描述符”,通知OAI关联的外部OAA抽取数据，并指定状态处理PIP。
说明：该方法向关联的外部OAA发送抽取通知，通知送达后即返回。欲获取的数据用“数据描述符”描述。“状态处理PIP”用于为取数状态指定状态处理PIP，当正常完成或者发生异常，都触发相应的状态处理PIP，特别是，当正常完成时，系统自动返回所获得的数据缓冲到客户端缓冲区，由OAI句柄指引，并触发“完成”状态对应的PIP，该PIP可通过OAI句柄获取返回的数据。该PIP可以省缺，此时，程序员通过OAI句柄指引的数据缓冲区中的状态判断取数状态并进行处理。“数据描述符”由程序员自定义，需要程序员与服务端编程配合确定含义。
（8）请求服务
格式：requestService(OAI句柄，服务描述符，数据缓冲区，状态处理PIP)
功能：根据欲请求的服务的“服务描述符”,从OAI关联的外部OAA请求服务，并回带服务处理的结果到“数据缓冲区”，同时触发状态处理PIP。
说明：该方法用于向OAI关联的外部OAA提交服务请求，并等待服务处理结果，获得服务处理结果后返回。欲请求的服务用“服务描述符”描述。服务处理的结果到达后存入指定的“数据缓冲区”。该缓冲区的首部是传输状态标志。“状态处理PIP”用于为服务请求状态指定状态处理PIP，可以省缺，此时，程序员通过数据缓冲区中的状态判断请求状态并进行处理。“服务描述符”由程序员自定义，需要程序员与服务端编程配合确定含义。
（9）通知请求服务
格式：requestServiceNote(OAI句柄，消息描述符，状态处理PIP)
功能：根据欲请求的服务的“服务描述符”,通知OAI关联的外部OAA提供服务，并指定状态处理PIP。
说明：该方法向关联的外部OAA发送服务请求通知，通知送达后即返回。欲请求的服务用“服务描述符”描述。当正常完成或者发生异常，都触发相应的状态处理PIP，特别是，当正常完成时，系统自动返回所获得的服务请求结果数据缓冲到客户端缓冲区，由OAI句柄指引，并触发“完成”状态对应的PIP，该PIP可通过OAI句柄获取返回的数据。该PIP可以省缺，此时，程序员通过OAI句柄指引的数据缓冲区中的状态判断取数状态并进行处理。
9.3管理
管理操作支持对所关联的外部OAA的管理，包括OAA参数配置以及OAA的PIP设置等方面。
（10）配置参数
格式：setOAA(OAI句柄，参数描述符，异常处理PIP)
功能：根据给定的“参数描述符”设置OAI关联的外部OAA，并返回设置状态（成果以及其他），同时指定异常处理PIP。
说明：“参数描述符”是键值对，其中键是顺序设置的参数的ID。“异常处理PIP”用于用户捕获操作异常并进行处理。
（11）设置PIP
格式：setOAAPIP(OAI句柄，PIP映射表，异常处理PIP)
功能：根据给定的“PIP映射表”为设置OAI关联的外部OAA设置PIP，并返回设置状态（成果以及其他），同时指定异常处理PIP。
说明：“PIP映射表”是系统规范的PIP映射表的内存形式。“异常处理PIP”用于用户捕获操作异常并进行处理。
十、有益效果
本发明给出的软件开发支撑方法与环境，旨在简化软件开发工作、增强软件质量和提高软件开发效率，主要表现在下列几个方面：
■模型化：物联网对象接入以及操作访问模型化，用户所需编程量大幅度减少，并且易于将业务逻辑描述为软件，易于软件扩展。
■支持新的建模方法：基于OAA的二部图模式扩展与聚合的软件构造
■将操控对象有机纳入软件成分：将任意的需要计算机应用系统操控的对象（泛在对象），作为应用软件的一种构件。相比之下，在传统方法中，软件构件是语言级的对象、组件等，没有将泛在对象有机地纳入构件。组态方法的组态虽然可以代表硬件对象，但只是一种映射方法。
■基于供件的“中央厨房”模式：使软件开发/运行以“预制+装配”方式进行。通过设置分布式的多供件，进行原料预备与半成品（公共构件）预制；通过设置装配器，动态装配半成品，形成用户功能。这种方式，将软件开发看作是用户功能的动态生成，也就是说，软件不一定是一个静态制作好的东西，实现了一种动态程序与程序的动态扩展机制。
“中央厨房”最早是美国的新闻媒体界提出的“融媒体”制作方法，思想是基于菜品的集成化配制式技术制作媒体。应用到软件开发上，相当于变软件开发为“构件预制+动态装配”。目前的软件开发技术，“供件预制”很普遍，但支撑平台的缺陷，使得“动态装配”一直未能推广使用。我们这里给出的是基于供件的“中央厨房”软件功能生成技术。由于供件天然具备预制性与装配性，所以是对“中央厨房”模式的自然实现。
■软件即平台SaaP：所给出的供件是一种运行时，本身就是一种平台软件，在用户代码中使用供件与求件，相当于将用户程序代码看作是平台的组成部分，将将软件平台化了。
相比之下，在IssS、SaaS和PaaS中，强调的是服务(Service)，因此PaaS是将平台也作为服务。我们这里的SaaP，就是为PaaS生成可以做为服务的平台的一种便捷软件开发方法。
附图说明：
图1是USIP体系示意图；
图2是供件体系结构示意图；
图3是供件网的应用模式（服务端）意图；
图4 是供件网的应用模式（客户端）意图；
具体实施方式
本发明给出的方法的实施方式，主要是支撑该方法的计算机系统即方法的支撑环境与工具的实现方法。这里重点给出本发明给出的方法的支撑环境与工具的实现体系，但并不排除其他的实现技术与实施方式。
一、供件实现体系
供件OAA是本发明的核心，是一种运行时支撑环境，主要组成成分是运行时模块、代码库和数据结构。运行时模块主要包括网络通信接收器、消息调度器，代码库主要包括网络通信发送器、线程管理器，数据结构主要包括消息输入队列、消息输出队列、管理配置文件、消息配置文件等组成。参见图2.
（1）供件框架的主要数据结构
■消息队列：存放系统的各种待处理的消息，供消息调度器从消息队列中取出消息执行相应的消息处理模块。消息包括网络数据达到消息，网络数据发送消息，用户数据到达（生成）消息，事件发生消息，等等。
■输入队列：存储从网络接收到的服务请求消息，由“接收器”通过输入队列接口访问。
■输出队列：存储消息处理需要回送的服务请求结果（消息），由“发送器”通过队列的接口取出消息，发送出去。
■消息映射：用于描述各类消息与对应的“消息处理器PIP”的对应关系。消息是指已经发生的事件，消息处理器是一种PIP，用于处理对应的消息。
■事件映射：事件是基于系统状态变量的逻辑表达式，该表达式为真时，表示该事件已发生，产生一条事件。事件映射表用于定义事件的发生条件与事件的处理所需的子程序—消息处理器，即事件映射。
■状态变量定义表：定义状态变量与维护它的值的PIP的对应关系。状态变量定义表中基本数据项格式是“变量名，当前值，PIP”，定义了名称为“变量名”的状态变量所对应PIP，并指出当前值为“当前值”。状态变量的值由对应的PIP的执行所确定。
■管理配置：定义供件的行为与访问控制信息，也包括状态采集策略。
■数据队列：用于暂存各个为处理的消息的大块数据，包括消息接收到的数据、待发送的数据，等等。
所有的数据结构，都设置专门的访问接口，供应用程序透明访问。
（2）供件的主要运行时模块
供件的运行时模块是在在供件启动时自动启动，作为独立线程运行的模块。
■接收器：负责接收来自网络的数据信息，为线程，平时一直监听网络上的服务请求消息，对于新到达的合法消息经过格式转换后存入输入队列，并生成一条网络数据到达事件，存入事件队列。这里，合法消息是指不在“黑名单”的消息，黑名单是系统定义的数据结构，可以有用户编辑，也可以通过专门的机器学习模块自动生成。
■消息调度器：为线程，主要功能是监测消息队列，按照优先级取出消息，分析消息，并按照消息映射表，调用/启动“线程工厂”为PIP生成一个线程并启动，然后调用事件检测器，以检测新事件的发生，最后调用/启动系统垃圾回收器处理PIP线程异常以及其他异常。
■状态采集器：为线程，按照系统定义的策略扫描“状态变量定义表”，执行需要更新变量值的PIP。
（3）供件的主要代码库
■发送器：基本功能是具体实现网络数据发送，为API，被调用时，从网络输出队列取出当前输出数据，通过网络发送出去。
■事件检测器：基于状态表检测事件的发生，一旦发生，则生成一条事件发生消息，存入消息队列。
■线程工厂：主要职能是为指定的PIP创建一个线程并启动执行。对性能要求较高的场合可以是以线程方式运行。
■垃圾回收器：主要职能是处理线程执行异常（超时、超存储和线程其他异常）以及其他资源占用异常的情况。对性能要求较高的场合可以是以线程方式运行。
■数据结构操作：各个还要数据结构的访问与操作代码模块，形式为对象。
二、供件主要模块实现方法
（1）供件主程序
该程序在OS下启动后，一直运行。
OAA()
{
init();//初始化各种数据结构
startReceiver(); //启动接收器线程
startMessageDispatch() ;//启动消息调度器线程
startStatusDetecting() ;//状态采集器线程
}
（2）接收器
receiverOAA()
{
while()
{
msgBus= recervMsg(); //接收数据到msgBus指示的消息缓冲区；
msg=parserOAAMsg(msgBus)；//解析消息，存放在msg指示的区域；
flag = firewallOAA(msg);//验证消息是否在“黑名单”中
if (!flag)
{ //消息不在“黑名单”中
msgQueue.pushMsg(msg); //将消息存入消息队列msgQueue
}
}//while
}// receiverOAA()
（3）消息调度器
messageDispatch()
{
while()
{
msgBus= msgQueue.getItem(调度策略); //按照指定的调度策略从消息队列中选择一条消息；
flag=startPIP(msgBus, msgDef)；//基于当前消息msgBus和消息映射表msgDef，确定消息对应的消息处理器PIP，然后生成一个新线程执行该PIP；
flag = eventDef.eventDetect(msgDef);//基于事件映射表eventDef检测是否有新事件发生，如有发生，则处理之,以生成事件消息，加入消息队列。
PIPThreadMng(); //检测PIP线程，发现异常后启动相应的处理线程进行处理；
}//while
}// messageDispatch()
三、求件主要模块实现方法
（1）实现方法总则
求件OAI是一个对象，它的方法是对象的方法或者接口。不同的实现语言，具有不同的表述方式。
求件方法/接口的实现，基于OAA的消息，即通过调用OAA的服务请求指令实现。
（2）OAI接口与类的体系
这里以Java为背景给出OAI的接口与类的java伪代码定义。
public interface OAI
{//定义一个OAI的公共接口，使不同的OAI接口都继承该接口
}
public interface OAIEvent extends OAI
{//定义OAA-1接口
bindOAA(OAI句柄，OAA设置参数);
setEventEOAA(OAI句柄，事件映射表，是否持久化);
loadEventEOAA(OAI句柄，事件映射表文件);
setCommEOAA(OAI句柄，ON/OFF);
}
public interface OAICommunication extends OAIEven
{//定义OAA服务类接口
injectData(OAI句柄，数据或者数据位置，注入描述符，状态处理PIP);
extractData(OAI句柄，数据描述符，数据对象缓冲区，状态处理PIP);
extractDataNote(OAI句柄，数据描述符，状态处理PIP;
requestService(OAI句柄，服务描述符，数据缓冲区，状态处理PIP);
requestServiceNote(OAI句柄，消息描述符，状态处理PIP);
}
public interface OAIManament extends OAICommunication
{//定义OAA管理类接口
setOAA(OAI句柄，参数描述符，异常处理PIP);
setOAAPIP(OAI句柄，PIP映射表，异常处理PIP);
}
abstract class OAI
{//定义一个抽象类OAI，支持各种OAI都从的继承
public OAI();
}
class OAI-1 extends OAI implements OAIEvent
{//实现支持OAA-1的OAI
}
class OAI-2 extends OAI-1 implements OAICommunication
{////实现支持OAA-2的OAI
}
class OAI-3 extends OAI-2 implements OAIManagement
{//实现支持OAA-3的OAI
}
public class OAIFactory
{//OAI工厂类 ，实现createOAI(OAI定位信息)
public OAI createOAI(int type)
{
switch (type)
{
case 1:
return new OAI-1();
case 2:
return new OAI-2();
default:
return new OAI-();
}
return null;
}
} 。

Claims (11)

1.一种用于计算机应用系统特别是“物联网+”系统的构成方法；该体系的核心内容是，将软件的构件归纳为供件、求件与挂件三类，支持用户基于这三种构件进行“R-AAS-AS”的三段式装配，构成以“中央厨房”模式工作的计算机系统，实现包括软件与服务、仪器设备及数据资源等在内的泛在对象的模型化的动态装配、互操作以及聚合式的自相似联合、扩展与衍生。
2.权利要求1所述的供件，一方面是用户业务逻辑装配模型，支持用户通过装配的方式定义自己的业务逻辑并驱动运行；一方面是泛在对象的操作访问对象代理，支持用户通过它连接并操作访问泛在对象；另一方面是泛在对象的互联与衍生引擎，支持泛在对象按照二部多重图模式互联形成供件网，并衍生新的虚拟泛在对象。
3.权利要求1所述的求件，用做应用程序访问供件的桥接与代理；应用程序在程序空间通过将一个供件在绑定到求件实现对外地供件的桥接与访问代理。
4.权利要求1所述的“R-AAS-AS”三段式装配是指，一个基于供件的计算机应用系统由三段组成；第一段是装配请求R，实现基于求件的UI构造或者泛在对象监控；第二段是本地装配与外地装配代理引擎AAS，实现本地服务动态装配与提供以及外部供件访问代理；第三段是外地装配服务引擎AS，实现外部服务动态装配与提供以及供件组网与衍生。
5.权利要求1所述的支持构造“中央厨房”模式工作的计算机系统，是支持用户在三段式装配体系“R-AAS-AS”中，在AAS和AS中分别定义面向业务需求的本地装配逻辑和外地装配逻辑，并通过AAS和AS驱动执行，将现代菜品制作的“外地半成品制作-厨房基于半成品的出品”的模式应用到软件开发。
6.权利要求1所述的泛在对象的聚合式的自相似联合、扩展与衍生，是一种泛在对象的扩展、协同与新生方法，即供件网，支持泛在对象分布自治、分布管理与分布交互；用户可以通过设置一个供件模型，使模型的活动部分的全部或者若干连接通道基于求件连接其他已有的供件；供件网结构定义为G=(V,E)，满足下列条件：G是一个无向图，如果顶点V可分割为n个互不相交的子集序列V1,V2, …,Vn, 并且,对u∈Vi, v∈Vi, 则不存在(u,v)∈E,且如果(u,k)∈E, u∈Vi，则或者k∈Vi+1，或者k∈Vi-1,这里i=1,2,…n；每个Vi主体是OAA或者OAI，也包括相关的PIP及其关联的泛在对象UO，OAA、OAI和PIP的运行环境统称泛在供件“容器”。
7.权利要求2所述的供件是一种模型；供件模型分固定部分与活动部分；固定部分是模型的框架，由系统给定，包括运行时和代码库两种；活动部分是填充到框架中的用户代码与配置数据；供件模型的规范，定义了模型的框架的体系、框架的功能接口、填充与挂接方式以及配置参数等方面。
8.权利要求7所述的供件模型，从用户功能角度分为面板与供体两部分；面板为用户接口，求件是通过面板来操作使用供件的；供体负责实现面板，是计算机软件或者硬件系统；供件的运行环境称为供件的容器。
9.权利要求8所述的供件的面板包括控制板和端口；控制板面向物联网设备的控制，由电子命令按钮组成，使用者通过网络连接触发这些按钮，来控制物联对象；控制板的按钮代表的命令是一些不需要参数的命令，包括标准按钮与用户扩展按钮两类；标准按钮由系统预定义，主要包括启动、停止、暂停、恢复，均针对物联对象的控制；用户扩展按钮由用户自定义，使用方式同标准按钮,包括命令与状态两种，其中，命令按钮用于向物联对象发送非标准的控制命令，而状态按钮用于读取物联对象的状态。
10.权利要求9所述的供件的面板的端口以服务的模式工作，求件通过向端口发送服务请求指令获得服务；端口有四种，分别称为管理端口、广播端口、指令端口、状态端口与回信端口，其中指令端口是每个供件都必须提供的，其他端口可以根据需求选择提供。
11.权利要求10供件的端口，其中的指令端口用于求件向供件以消息方式发送参数化的控制指令与服务请求指令；指令的执行的状态与结果，根据指令的不同可以返回到回信端口，由专门的读取指令获取，也可以由供件直接回送给消息请求者；指令端口的服务请求指令包含标准服务请求指令与用户自定义服务请求指令；标准服务请求指令由系统预定义，每种供件必须实现；用户定义服务请求指令是供件提供者根据供件自身的特点与服务需求确定的服务指令，格式是标准化的，但内容是有用户自定义的挂件确定；标准服务请求指令包括各种标准数据结构的数据读、数据写、数据更新、数据删除等；支持的数据结构有关系数据库、GriDoc文档、OS文件等；管理端口用于供件的提供者通过改变节点参数定义和配置节点的行为与功能；主要的配置参数有用户账户、访问控制参数、连接控制参数、服务质量控制参数、实时参数、远程时间配置以及节点功能选择参数等；广播端口用于节点主动发布关于节点与节点关联的对象的工作状态信息、公共服务数据与信息等；工作状态信息包括服务范围与限制、公告信息、运行状态以及用户访问受理与处理状态；每种广播消息属于一个系统定义的频道；用户通过收听指定频道的信息获取广播消息；用户端的OAA通过订阅功能获取广播；回信端口用于传输客户端所请求的数据；用户通过向该端口发送取信指令实现服务请求结果的获取；状态端口供用户读取供件的工作状态、服务范围等信息。
CN201810176975.8A 2018-03-04 2018-03-04 基于泛在对象三段式装配的软件构成方法 Pending CN108415689A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810176975.8A CN108415689A (zh) 2018-03-04 2018-03-04 基于泛在对象三段式装配的软件构成方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810176975.8A CN108415689A (zh) 2018-03-04 2018-03-04 基于泛在对象三段式装配的软件构成方法

Publications (1)

Publication Number Publication Date
CN108415689A true CN108415689A (zh) 2018-08-17

Family

ID=63129710

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810176975.8A Pending CN108415689A (zh) 2018-03-04 2018-03-04 基于泛在对象三段式装配的软件构成方法

Country Status (1)

Country Link
CN (1) CN108415689A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109302454A (zh) * 2018-09-06 2019-02-01 重庆云力网通科技有限公司 一种泛在网软件定义服务的装置和方法
CN110554644A (zh) * 2019-08-20 2019-12-10 华南理工大学 一种泛在对象即插即用的统一接入系统及第三方接入方法
CN115857915A (zh) * 2022-12-28 2023-03-28 广东外语外贸大学南国商学院 面向元宇宙系统开发的物对象数字化方法
US20230199444A1 (en) * 2021-12-21 2023-06-22 Continental Automotive Systems, Inc. System and method for operating vehicle in multiple vehicle-to-everything (v2x) regions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103336813A (zh) * 2013-06-27 2013-10-02 南京邮电大学 一种基于中间件架构的物联网数据集成管理方案
CN106254558A (zh) * 2016-10-12 2016-12-21 齐德昱 物联网的基于两层覆盖网的支撑体系与实现方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103336813A (zh) * 2013-06-27 2013-10-02 南京邮电大学 一种基于中间件架构的物联网数据集成管理方案
CN106254558A (zh) * 2016-10-12 2016-12-21 齐德昱 物联网的基于两层覆盖网的支撑体系与实现方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
张倩: "《云制造若干关键技术及其应用研究》", 《中国博士学位论文全文数据库信息科技辑》 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109302454A (zh) * 2018-09-06 2019-02-01 重庆云力网通科技有限公司 一种泛在网软件定义服务的装置和方法
CN110554644A (zh) * 2019-08-20 2019-12-10 华南理工大学 一种泛在对象即插即用的统一接入系统及第三方接入方法
CN110554644B (zh) * 2019-08-20 2022-04-22 华南理工大学 一种泛在对象即插即用的统一接入系统及第三方接入方法
US20230199444A1 (en) * 2021-12-21 2023-06-22 Continental Automotive Systems, Inc. System and method for operating vehicle in multiple vehicle-to-everything (v2x) regions
US11985575B2 (en) * 2021-12-21 2024-05-14 Continental Automotive Systems, Inc. System and method for operating vehicle in multiple vehicle-to-everything (V2X) regions
CN115857915A (zh) * 2022-12-28 2023-03-28 广东外语外贸大学南国商学院 面向元宇宙系统开发的物对象数字化方法
CN115857915B (zh) * 2022-12-28 2024-03-15 广东外语外贸大学南国商学院 面向元宇宙系统开发的物对象数字化方法

Similar Documents

Publication Publication Date Title
US11909604B2 (en) Automatic provisioning of monitoring for containerized microservices
US9479400B2 (en) Servlet API and method for XMPP protocol
CN108880887B (zh) 基于微服务的陪护机器人云服务系统及方法
CN111309374B (zh) 一种微服务系统和微服务系统中的服务调用方法
CN108415689A (zh) 基于泛在对象三段式装配的软件构成方法
CN102291464B (zh) BPM中业务流程动态生成Web Service的系统及方法
US20060031497A1 (en) Systems and methods for collaborative content storage
US8463852B2 (en) Groupware portlets for integrating a portal with groupware systems
NZ518575A (en) Distributed application server using a peer configuration
US10505750B2 (en) Box for communication and management of devices
CN101860564A (zh) 基于协议的服务组合系统和方法
US20180191858A1 (en) System for managing data of user devices
Celesti et al. Integration of clever clouds with third party software systems through a rest web service interface
Viola et al. The M3 architecture for smart spaces: Overview of semantic information broker implementations
CN114422542A (zh) 一种终端域管系统
CN101924815A (zh) 3g moa 手机中间件嵌入式系统
Al-Zoubi et al. Performing distributed simulation with RESTful Web-services
US11438191B2 (en) Interconnection box for user devices
EP2785019B1 (en) Managing mobile telecommunication devices with a general purpose messaging transport protocol in digital cellular telecommunication networks
Camarinha-Matos et al. TeleCARE: Collaborative virtual elderly support communities.
Du et al. Research on service bus for distributed real-time control systems
Horng et al. An agent-based smart home system and its service-scheduling mechanism: Design and implementation
RU2361366C1 (ru) Способ гарантированного доведения информации в неоднородной вычислительной сети
US11329841B2 (en) Method of communication between a remote action manager and a communication box
CN115857915B (zh) 面向元宇宙系统开发的物对象数字化方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20180817