利用查询语言询问或处理完整的文件的方法和装置

技术领域

本发明涉及利用查询语言询问或处理完整的文件的方法和装置。

背景技术

通常，查询语言(也称为查问语言、检索语言、搜索语言、搜索查找语言、过滤语言、询问语言)是用于搜索信息的语言。

询问(查询)的结果是基础信息存量的子集。

被算作为用于数据库的典型的查询语言的有经典的语言、如SQL(StructuredQuery Language(结构化查询语言))、来自数据分析的典型语言(Sparql、Gremlin等)、以及网络环境中的现代代理、如GraphQL。在此，针对类型模型或模式设置查询。其例如能是限定一个或理想情况下多个具有确定区域的表格的数据库模式或者用于具有属性(特性)的对象的类型模型。在这两种情况下可以并且通常存在表格或对象之间的关联。

尽管称为“查询(Query)”，这样的语言不仅允许数据的纯询问，还允许数据的操作(生成、修改、删除)。语言环境或者为此实现的功能在此主要跟随CRUD(生成、读、更新、删除)原则。尽管如此，接下来与具体功能无关地始终涉及询问(Request)和所属的回答(Response)。

在此，询问通常被完全传输并且随后由一个或多个“分解器”解析并且转变为回答。

通常，经由在服务器侧执行并且由应用的客户侧呼叫的网络的应用程序接口(API)(例如针对网络服务器，也参见https://en.wikipedia.org/wiki/Web_API)，能够设置生成回答的询问(Request/Response)。在此也经常直接利用数据互动。在此，在接下来的考虑中应当特别考虑这样的数据中心的API，较少考虑跟随传统的REST(RepresentationalState Transfer(表征状态转移))范例的资源中心的API。特别地，其还包括RPC(RemoteProcedure Calls(远程程序调用))，多个询问或图形询问基本上代表了经由RPC的标准化的询问。

在EP 3,438,774 A1中给出用于在工业化的自动化系统中经由网络应用提供功能、特别还有询问信息的方法的实例。

当在查询语言(QL)之后讲话时，其(网络)始终包括具有类似的特性的API。

查询语言和API主要适用于简单到复杂的、针对数据(记录)的询问；然而很少、甚至根本不用于整个文件。以相同的方式和方法像常规数据那样处理文件(即例如将文件内容作为变量的值)在此是有缺点的，其出于以下几个原因：

文件通常不是询问的特性，因为不搜索数据记录，该数据记录取决于具有作为参数传递的文件的一致性。

文件不是回答中的好的组成部分，因为回答在查询语言(以及数据中心的API)中通常跟随能评估的格式并且不表示各个粗略日期。特别地，自身的回答提供多于一个命中物的询问不允许多个“普通文件”的合理的发送，而是必须将其作为负荷量包装到上级的结构中，并且在可能的情况下还特别标记(“躲避”，例如以BASE64编码)。两者在网络运输中还导致更多的通信量。

文件大小通常是预先未知的。回答的传输可能持续无法预料的长度，或者客户端没有足够的资源或兴趣从确定的阈值起完全接收全部的文件。

文件不是变化(生成、更新)的好的组成部分，因为询问由此变得非常大。然而，在主要的查询语言中必须首先传输完整的询问，以便总体上能够以其解析(Resolve)开始。因此会将一个或多个文件作为变化的一部分传输，以便在可能的情况下由此仅确定例如用户的权限不够或询问不符合其他边界条件。因此会将上传作为持续时间非常长的询问进行，但是在服务器侧上不导致存留(在较长时间段期间保留数据)。

进行评估的系统必须具有足够大的工作存储器(或临时缓存)，以便接受并且缓存具有所包含的文件的整个询问。

因为询问必须被视为整体，存放地的文件流同样不能作为询问的组成部分。对此，文件必须能被即时识别/提取为查询的组成部分，并且在可能的情况下直接进一步流至目标地(例如数据载体、文件存放的支持系统等)。同样地，在此尤其不能够实现文件的不同的目标存储(例如在SD(闪存)卡、内部存储器、数据结构上)，因为其仅能通过解析步骤被解析。

在两个方向(读、写)上适用的是：在询问或回答的时间点始终不清楚对方位置是否能够或愿意接收整个数据。同样地，很难根据文件大小预先估测哪种上传/下载策略是最合适的(例如并行下载单个文件，串行加载到公开的连接中，串行加载到个人的单个连接中等)。

出于该原因，文件通常完全不经由查询语言处理，最多间接做为能询问的特性，其例如显示存在的数据的路径而访问客户端(询问发起者)以及服务器(回答处理者)。在此，不考虑实际的文件处理自身。因此，通过查询自身通常不生成、删除或发送新的文件。在该情况下涉及两个能相互独立使用的、在理想情况下同步的系统。

然而询问不导致文件的上传并且同时阻断例如另外的上传或读取访问。因此，互动其实经由两个不相关的系统并且不能被考虑为“原子行为”。

同样地，查询语言本身不能代表动态的文件(例如应当仅在需要时生成并且连载以确定的规则对确定的文件映射的查询，其例如是备份文件、状态映射、输出确定的子系统的轨迹等)。

然而，刚好存在的问题是，查询语言或数据中心的API具有许多优点以便灵活地操作数据，但不考虑文件处理。

然而，许多文件还存在于在工业环境中并且与数据(和模型)(轨迹、日志、固件影像等)连接。因此，目标是获得查询语言的优点并且同时对此能够实现简单和大量的文件处理。

通常能够将问题传递给系统边界处的全部API，即使描述中的焦点在查询语言和网络环境中的API上，API能由浏览器消耗并且因此例如设置在HTTP协议上，该协议能从协议RFC(当前版本为2015年的RFC7540，但不局限于此)获取。

如上所述，数据和文件(资源)如今在查询语言或数据中心的API中被相互分开考虑。

可替换地，应用基于资源的API(参见REST(表述性状态传递)的API)。然而特别地，REST转移了许多复杂性到客户端中并且在进行复杂询问时主要还导致多个单独询问。因此，例如能够经由协议ODATA(http://www.odata.org/)实现询问，在此文件访问同样能够经由相同或另外的端点实现。然而，用于每个单独文件的文件大小必须预先利用协议HTTP的HEAD(头)询问，并且操作(创建、写、删除)不能作为类似原子的行为实现。(在此对每个文件使用单独行为，而不参考ODATA询问日期，日期因此不与文件硬连接)。

发明内容

因此，本发明的目的在于，提出能够在整体上实现应用API并且询问以及操纵文件的可行性方案。

该目的通过本发明的方法实现。

该目的还通过本发明的装置实现。

根据本发明的方法能够利用查询语言经由接口询问或处理完整的文件，其中，文件在信息模型中作为对象被寻址，该方法具有下列步骤：

-检查来自客户端的对文件的询问的可执行性，

-生成包含有关询问和文件的信息的票证(Ticket)，

-将关于进行询问的客户端的票证信息传输至询问的计划的接收者，

-能够由接收者根据被包含在票证中的信息加载或处理完整的文件。

在此，有问题的文件也能仅表示实际实施的询问的一部分。

根据本发明提出一种用于实施用于利用查询语言经由接口询问或处理完整的文件的方法的装置，其中，文件在信息模型中作为对象被寻址，该装置能由客户端以及文件的接收者响应，并且该装置在检查来自客户端的对文件的询问之后生成票证，该票证包含有关询问和文件的信息，并且该装置将具有关于进行询问的客户端的信息的票证传输至询问的计划的接收者，接收者能够根据接收的、被包含在票证中的信息加载或处理完整的文件。

还提出数据接口(API端点)和专用的文件端点与整个票证系统的新的和有利的组合。在此，类似原子(Quasi-atomare)的行为能够通过应用每个(至少一个)新加入的票证实现，票证使这两个端点相互连接。在此，文件作为数据模型的一部分能经由类型特定的文件代理被寻址，其中，相应的文件代理执行类型特定的处理(读、写、修改、删除)。

从网络API的现有技术已知了用于询问/查询或API调用的接口或者专用的API端点以及适用的文件端点，端点能放在相同的物理装置上(但是不是必须的)。然而，这些端点不间接关联，而是相互独立地工作。

信息模型(或者数据模型)允许与数据互动。优选地，模型具有图形结构。通过该图形结构使询问更容易，因此能够例如在树形结构中借助于询问确定相互连接的数据，否则在那里要进行更多次询问(还参见例如OPC UA(统一架构))。

文件作为与另外的对象相关的独立的对象(所谓的文件代理)被包含在该模型中。例如，一个对象代表诊断缓存，并且另一个对象代表作为文件的全部诊断数据的转存。

这些文件代理对象一方面用于在信息模型中显示(以便询问信息或行为)，然而也用于分别执行文件的类型特定的处理(例如写入固件、存留大数据量(二进制大对象)到数据库中、存储单独文件到SD卡或文件系统上等)。

本发明的基本观点在于新型的票证系统，其分别在信息模型上建立用于具有文件参考的行为的票证。

该系统也监视与票证关联的这些行为的寿命周期、如整个行为的最大持续时间。在此，经由API端点的接口来访问信息模型，优选(然而不强制)在网络服务器上提供该信息模型。

经由对象(所谓的“文件代理”)代表文件，文件代理作为另外的元素的子元素被创建、操纵或读取。具有这些代理的互动遮盖实际的文件互动，检查约束条件，提供用于所属的文件的消息等。根据CRUD原则的全体的行为(创建、读、更新、删除/创建、读、写/修改、删除)由此被检查实施可行性(“预览”阶段)，并且立即(删除)或随后(所有其他的)经由文件的API通过相应的代理实施(“解析”阶段)。

经由网络API将代理删除也自动消除其代表的物理对应物。与之相反，通过生成、写和读文件在票证管理器中生成票证，并且将代理转至反映还持续经由文件的API进行的文件互动的状态。

用户作为数据互动的一部分获得状态并且通过传输文件代理的属性获得附加信息以将其作为回答的一部分。其在生成/修改时覆盖约束条件，例如“上传最大20Mb”，或者在期望的读取进程中用于相应文件的元信息(例如“文件的大小为5Mb”)。

在此也包含相应的票证，其至少由单一的ID(标识)表示。此外，能够包含关于票证寿命的信息。

优选地，票证与用户会话关联。仅初始化票证的人能够在文件的API上应用票证。对此，票证管理器除了管理票证和其用于相关的文件代理的参考之外，还管理寿命和与用户会话的关联。

在此，元信息和约束条件必须与用于行为的票证仍开放一样稳定地保持。这表示，文件(或其在固件、文件系统等中的形式)和其在信息模型中的文件代理在用于读取行为的票证还有效期间不能改变。

然而，相同文件的读取行为能够并行地进行。

与之相反，仅当不存在仍开放的、用于文件和其代理的票证时能够实现写或删除行为。

单独的文件端点典型地在网络服务器上组成REST的接口，然而能考虑的还有其他的解决方案，例如RPC的调用。文件端点允许通过HTTP方法的行为(例如用于读的获取(GET)和用于写的公告(POST))并且优选有在HTTP询问的路径中引导票证的ID。

附图说明

图1是根据本发明的方法的流程图。接下来，图1示出优选的实施例。

具体实施方式

在此说明的是，实施例不起限制作用。

票证由端点(API的端点)经由票证管理器(TM)检查有效性。如果票证有效，那么就经由所属的文件代理实施期望的行为(“解析”阶段)，并且在成功实施的情况下最后正面地回复。在负面结果的情况下在头部中返回相应的错误代码。

-HTTP公告(仅)在请求正文(Body)中包含文件(F)并且提供没有正文的回答。公告用于生成和写。

-HTTP获得不包含询问正文，而是(仅)在回答正文中提供文件。获得用于读。

-HTTP删除既不包含询问正文也不包含回应正文。删除用于返回票证(不用于删除文件)。

在此，在之前所谓的“解析”步骤中写或读文件，其中能够将HTTP询问的负荷量直接传递给目标位置(闪存、文件系统、文件库等)，如数据到达文件端点那样。因此不必强制首先完整地接收整个文件，而是按照类型特定地由文件代理来处理缓存或直接的传递。

在成功实施之后，文件代理变成一般的默认状态(例如“可用”)。如果初始化了不应当实施(例如因为文件大于在回答中给定的上传的允许的最大值)的行为(例如写入文件)，则能够经由HTTP方法的删除来删除票证。在此，文件代理又转变到原始状态中(或在应当仅生成对象时删除，以便实施“孤体处理”并且不在信息模型中保存孤体对象)。当经由限定的持续时间针对文件的API绝对不初始化具有票证的行为时，还能自动去除票证。

接下来示出类似原子的行为的示例性的流程：

经由数据端点(API的端点)应当显示文件。在此，以“虚拟代码”的形式描述指令，HTTP代码用斜体说明。

(1)首先客户端利用查询开始询问，该询问最后应导致生成文件。

>生成文件(file(x))

(2)在此，经由信息模型(IM)对对象进行寻址(x)，在该模型处将文件模型化。在此，文件由文件代理(FP)代表，文件代理进行最初的检查以检查在当前的边界条件下是否能够实现行为。

文件代理(FP)首先处于“待完成(pending)”的状态。

>生成文件代理

>检查是否能将文件添加至X

>检查环境(用户、可用空间、系统状态等)

(3)在正面结果的情况下为模型添加代理。

>添加文件代理到IM(信息模型)上，

>设置状态＝“待完成”

(4)生成票证(TMI)，其指向文件代理(FP)并且存储在票证管理器(TM)中。

>生成票证

>将票证链接至文件代理

(5)将票证作为回答的一部分反馈至客户端。在此，文件的代表还包含关于票证有效期多长和考虑哪些约束条件(例如最大的文件大小)的信息。

>返回文件代理的对象，该对象具有票证“AFFEAFFE”和条件(最大尺寸、最大有效时间等)

(6)在另一个步骤中，客户端在应用票证的情况下在文件的端点(EP)处初始化HTTP公告(优选作为URL(统一资源定位器)的组成部分)。

>公告/文件/AFFEAFFE http/1.1

>上传文件

(7)端点检查票证的有效性和与其连接的文件代理的可用性。

>检查票证

>获得文件代理

(8)经由代理最终存留文件，根据代理类型和要求分为一段、多个部分或以流的形式。

>通过分解器存留

(9)如果完成数据转移，那么就将信息模型中的代理处的状态置为“可用”状态。

>设置状态＝“可用”

(10)解析票证(方式：去除)。

>完成票证“AFFEAFFE”

(11)经由相应的HTTP状态代码为客户端信传输成功(OK)完成行为的信号。

>HTTP 200OK

>确认上传

负面结果的情况(在图1中未示出)，

删除-删除票证，

超时-删除票证，

必要时反馈错误代码。

在本发明的另一个有利的实施方式中，票证ID能够编码确定的变量，其允许重建票证的顺序和签发时间点。因此，能够在可能的情况下确定：是否能够至少在概率上预先存在不可用的票证。

这16字节能够获得十六进制的显示序列中的32字符的字符串，例如获得票证：

[4字节＝日期时间][8字节＝随机票证][4字节＝计数器]。

为了获得操纵安全的解决方案，能够有利地随机(Random)选择票证ID的至少一部分。如果采用对称的块密码(BlockCipher)(例如用于可逆的散列法(Hashing)的Feistel密码)，则编码置入的变量不再能被简单识别；即使操纵伴随变量，必须在服务器侧在票证管理器中一直给出整个对应物，并且票证对于相应的用户会话必须是有效的。因此，票证ID中的这样的附加编码允许必要时能够给出更好的误差响应，而不损害安全。

在具体的实施例中，尤其能将提出的解决方案用于具有基于网络的数据接口的可编程逻辑控制器(PLC)。

根据本发明的解决方案针对迄今为止的工作方法提供了多个优点。能够将由询问和所属的文件处理组成的行为作为类似原子的行为执行。

在询问的常规的询问/回应式的通信之外(out-of-bound)，通过经由连接运行的上传和下载，允许更好的平行运行。

尤其当在给出参数时完全不能实现实际的更新/生成时，能够避免作为询问(上传)的一部分的大数据量。参数的顺序有时不总是表现为文件必须从头到尾都存在。

类似地进行整个变化的中断，以便在批量询问无效时阻止上传。纯中断也不提供有关“为什么不能”的具体信息，文件代理相应的串行化对此是更有用的。

本发明的另一个优点在于，能够实现有关并行的数据互动的、必要时根据不同的配额使文件配属于哪个数据对象的灵活配额。固件转移始终仅通过所有用户进行，每用户直到X个数据日志并且完全并行进行等。

因为对于每个票证已知之后进行的行为和确定(例如在闪存中写入固件)，所以能够单独地处理文件的转移。