Hecp
| 请阅读免责声明。删除百科只是中文维基百科被删除条目的存档。 |  建议删除本条目
| |
Hecp（Hyper Entity Control Protocol）是超实体控制协议，是一个概念框架。Hecp给出一套词汇标识一套概念并将给出一个实现样例。Hecp是Api设计规范，是体系结构模式，是架构模式，是最佳实践。Hecp不绑定到任何传输层。
对于设计良好的api来说sdk不是必须的。类似淘宝的那个有六七十个参数的api来说，提供sdk也于事无补。大厂商之所以提供sdk是因为其api所面向的程序员众多，水平参差不齐。大厂商提供sdk是惯性思维。但sdk在Hecp时代过时了。Hecp有上下文和分类法概念。比如一个发手机短信的应用，它所关注的就只是教师本体所有元素的一个子集，而这个子集到底包括那些元素在Hecp世界中是由相应的领域专家组织的。对于发手机短信这件事在行的专家基于分类法从教师的七八十个属性中提取出一个子集，这个子集的上下文就是发手机短信这个“话题”。
命令（Command）
命令是Hecp的核心概念之一。
Hecp接受CQRS的思想。面向对象的行为仅有两种：命令和查询，不存在第三种情况。Hecp将命令进一步分三种：Action（行动）、Command（命令）、Event（事件）。三者在[[数据传输对象的结构上不做进一步区分，三者结构完全相同。
时间戳：三者均具有时间戳属性，不同的是“行动”的时间戳来自当前的宇宙上下文；命令的时间戳由客户端填入，但命令的具体执行时间由服务端决定；事件的时间戳往往是过去的也由客户端填入。
执行性质：服务端立即执行请求类型为Action的命令，周期执行请求类型为Command的命令（执行周期由服务端自定），如何处理请求类型为Event的命令由服务端自主决定（面向EventSourceType、EventSubjectCode和StateCode编程）。
从广义的角度说：命令属于操作，是操作实例。即，命令是对“什么”进行“怎样的”操作。如“把身份证件号码为4114251988035465的教师的性别修改为男”就是一条命令，但“修改教师”却不是命令因为它没有指定被修改的实体对象实例。为了便于理解，可以将命令与关系数据库的数据操作语句相对应，对于师生数据库数据交换平台来说可以将命令简单的理解为对关系数据库数据操作语句的对象级封装，这个说法仅仅是为帮助理解命令概念，两者并非同一概念。这种广义的描述非常抽象，下面我们换个视角从数据交换领域的角度形式化的描述一下。
命令是对操作的描述，是在节点间传递的数据和结构，通过一个命令实例可清楚的描述一次操作的具体内容。如果读取一条命令的内容并链接成方便阅读的话的话，则可以表述为：哪一个节点在什么时间对哪一个教师或学生进行了什么操作，若该次操作是修改操作，还可以进一步读取到具体被修改的字段以及修改后的新值。
Hecp的Command是对命令的高度抽象，是“神”，当命令的“神”遇到具体领域的时候可以化为“形”。比如当Command“神”来到数据库领域的时候它就化作了sql“形”。
使用下面的表格表述Command的数据结构：
|
Name |
Parameter |
Data Type |
Required |
Description |
|
Version |
path |
string |
Yes |
版本标识。取值：v1 |
|
Credential |
path |
CredentialData |
Yes |
证书。 |
|
RequestType |
path |
string |
Yes |
请求类型。必须是Action或Command或Event。Action接收立即执行，Command接收后周期执行， 如何处理Event由服务端自定。面向EventSourceType、EventSubjectCode、EventStateCode/EventReasonPhrase编程。 |
|
OntologyCode |
path |
string |
Yes |
本体码。教师对应JS，学生对应XS，测试对应JSTest。 |
|
ActionCode |
path |
string |
Yes |
动作码。教师、学生两个本体的动作码巧合相同。目前均是Create、Update、Delete、Get、Head五个取值。 |
|
EventSourceType |
path |
string |
No |
事件源类型。必须是Command或Entity。Command事件源类型的事件用以告诉远端节点它发送过来的命令在我端的处理状态。 Entity事件源类型的事件用以告诉远端节点我端的实体发生了某个事件，我端的实体在远端有对应的实体。 |
|
EventSubjectCode |
path |
string |
No |
事件主题码。主题码为点号分割的层级结构。 编码为“StateCodeChanged”的主题基本包括命令的所有事件，而“StateCodeChanged.Audit”编码的是审核事件。 |
|
RequestID |
path |
string |
Yes |
请求标识。 |
|
LocalTicks |
path |
string |
Yes |
本地时间戳。对于Event该时间是事件在客户端发生的时间而对于Action和Command该时间戳的意义由客户端自由定义。 |
|
EventStateCode |
path |
int |
No |
状态码。状态码参见《数据交换协议状态码表》。 |
|
EventReasonPhrase |
path |
string |
No |
原因短语。状态码参见《数据交换协议状态码表》。 |
|
InfoID |
path |
KeyValue[] |
Yes |
信息标识。Key、Value键值对数组，键为本体元素码。 |
|
InfoValue |
path |
KeyValue[] |
No |
信息值。Key、Value键值对数组，键为本体元素码。 |
Command请求的响应：
|
Name |
Data Type |
Description |
|
ClientRequestID |
string |
请求标识。 |
|
StateCode |
int |
状态码。状态码参见《数据交换协议状态码表》。 |
|
ReasonPhrase |
string |
原因短语。状态码参见《数据交换协议状态码表》。 |
|
Description |
string |
描述。如“没有删除教师的权限” |
|
ActionInfoResult |
KeyValue[] |
信息值。当ActionCode取值Get时有值。只包含请求节点有Get权限的本体元素。 |
|
ServerID |
String |
服务器标识。 |
|
ServerTicks |
Int64 |
服务器时间戳。 |
本体（Ontology）
本体_(信息科学)是指一种“形式化的，对于共享概念体系的明确而又详细的说明”。进一步的了解可查询维基百科或百度百科，本协议中使用“本体”这个词汇时使用的是百科上的内涵。本体（Ontology）是一个概念框架，给出一套词汇标识一套概念，这些词汇就是术语。本体本身也需要标识，比如我们说”物理学“，物理学这三个字就标识了本体。对于本体这个形而上学的东西读者没必要纠结，只需知道在数据交换平台中计算机是使用编码来标识本体的就可以了。如”JS（教师）”标识一个本体，“XS（学生）”标识一个本体，在教师本体概念框架下“性别”指的是教师的性别，而在学生本体概念框架下“性别”指的是学生的性别，再比如：在教师本体框架下有“所教学科”这样的概念但在学生本体下没有，而在学生本体下会有“家长联系电话”这样的概念但在教师本体下没有。
Ontology与Table：
在Hecp看来并非每一个本体都需要存储（比如Hecp中间代理就可能根本不设计数据库），这也是之所以使用Ontology而不使用Table来表述本概念的原因之一。本体非常抽象，非常形而上学，从而才能允许Hecp附加上新的解释也是原因之一。由于Ontology概念的极度抽象容易造成理解上的偏差，这里需要再给出一个对比：对于Http（超文本传输协议）来说，Http的本体是“资源/超文本”和“转移”；对于Hecp（超实体控制协议）来说，Hecp的本体是“实体”和“控制”。
本体元素（Element）
“教师”二字标识了一个本体，当A告诉B“张老师去年是教语文的今年教数学了”，B说“我跟他是大学同学，他是数学系的”，A说“原来如此”。这两个沟通中的人能够互相明白对方的意思首先是因为“老师”二字界定了本体，“张老师”三字定位了“实体”。而“教语文的”“教数学的”“数学系”是张老师的“属性值”，而“属性”在此命名为“本体元素”，如教师本体有“所教学科”、“学历”、“专业”、“从教年月”等本体元素。
实体（Entity）
实体是具体本体下的一个具体事物，这个事物可能存在物理世界的真实映射也可以是完全虚构的事物。实体有一个重要属性是必须可以“标识”，也就是说必定可以区分出两个实体的不同。在师生基础数据库中每一个教师是一个教师实体，每一个学生是一个学生实体。师生基础中心库为每一个教师和学生实体分配唯一的编号，这个编号就是实体的唯一标识，各业务系统通过该标识与中心系统交换信息。
本体动作（Action）
动作用以定义可以面向具体本体做些什么。如，可以创建教师、可以修改教师的信息、可以删除教师，所以教师本体上定义有编码为“Create”、“Update”、“Delete”的动作。动作是依赖于本体的，如果本体是“文档”则动作编码为“Create”、“Update”、“Delete”不再合适，“Upload”、“Download”、“Compress”、“UnCompress”更合适。
字典（InfoDic）
有些本体元素在实体上的取值不是任意的。当本体是“人”时，人有“民族”这个本体元素，本体元素“民族”的“数据类型”是字典型的。“教师”本体是“人”本体的一个子类，张老师是一个“实体人”，张老师的“民族属性”取值就不是任意的而是由教育部的“民族”字典限定的。
组织结构（Organization）
组织结构用以对具体本体的实体集进行单元划分。对于师生数据交换平台的“教师”和“学生”本体来说两者的组织结构巧合是一样的。师生实体集的组织单元是“区县”、“学校”、“电教馆”、“教科所”等这样的具有一定程度的稳定性的行政、企业、事业单位。组织结构和字典一样具有可枚举性质，整个**市大约有700多个教育性质的组织结构，但组织结构与字典有一个重要的不同：组织结构具有层级性质，这体现在组织结构的编码上。本数据交换平台的组织结构来源于学籍系统。
编码
计算机不擅长处理像“张老师”、“教语文的”、“他是数学系的”这样的信息。所以为了计算机化需要设计一种更利于计算机理解的语言。基本上各行各业都有国家级的相关编码标准。
状态码（StateCode）
状态码在结构上包括三个字段，由一个必选字段和两个可选字段组成：编码（StateCode）是必须的，原因短语（ReasonPharse长度50个英文字符）和状态描述（Description长度无限）是可选的。各节点处理下列状态码的方式相同。
{stateCode:200, reasonPharse:'Ok', Description:’接收成功’}
{stateCode:200, reasonPharse:'成功', Description:’执行成功’}
{stateCode:200, reasonPharse:'Ok', Description:’干的不错，恭喜你成功了’}
Hecp的状态码和Http状态码具有相同的分类规律。状态码取值在[0-200}左闭右开区间表示info，[200-300}区间表示success，[400-500}区间表示fail，500表示error（服务节点内部逻辑异常）。
信息（Info）
信息与数据和信号有些不同，“信息”二字的下面隐含了“翻译”这件事情，也就是说“能翻译”的数据和信号才是信息。比如，这里书写一个字符“1”读者能知道它是什么意思吗？读者看到“1”只是收到了一个视觉“信号”，如果交换系统不告诉你这里的字符“1”是性别“男”的意思的话恐怕字符“1”对你来说就只是一个无意义的视觉信号罢了。收到字符“1”并将它识别为性别“男”这就是“翻译”。 信号被翻译成已知的事物才能成为信息。而“翻译”是什么？是“映射”，激进一下，不妨把信息直接定义为“映射”，信息是：抽象到抽象的映射，抽象到存在的映射，存在到存在的映射，信息就是映射。 那么A被映射到B，B被映射到C，C再被映射到A，这里的映射是不是信息？是。虽然这是一个闭合的映射环。但是“我们”人类是知道它的无意义的。我们之所以能够识别出这些映射是无意义的是因为我们有“知识”和“智慧”。“知识”是什么呢？ 信息是映射。而“知识”是选择映射路径的能力。比如“今天天气预报说明天有雨，于是小明取消了明天晒被子的计划”这就是“知识”。小明收到了明天有雨的信号，然后在头脑中做了一系列的映射“时间映射、下雨和水映射、水和湿映射、湿和被子映射、湿被子和睡觉不舒服映射 等”关键是在这一系列映射后小明做出了“明天不晒被子”的映射，从而“明天的雨水无法映射到小明的被子”小明选择了映射的路径，选择映射路径的能力就是“知识”。 数据交换进程中所进行的一切活动都是事先设定好的“映射”并无“知识”和“智慧”，有智慧的是“人”，数据交换平台将数据收集过来，然后站在平台外部的“人”使用这些数据进行“决策（选择映射路径）”：比如领导看到某个老师各种条件都不错头脑中考虑了一下是否将这个老师与“教育标兵”映射。
信息标识（InfoID）
首先，标识是一个范畴很大的概念，为了说清问题我们需要把这个概念放在一个具体的领域边界中。本文档需要对业务标识、存储标识、信息标识这三个概念做鉴别性定义，这些定义所基于的领域边界是“师生基础数据”。当我们在本文和相关的其它文档中提到这三种标识时它们分别指的是： 业务标识 像教师的身份证件号，学生的学籍号这样的可以充当标识的字段我们称作业务标识。 存储标识 各业务系统持久化教师和学生数据时所使用的标识，如数据库中教师表的主键。 信息标识 信息标识用于数据交换，它在具体实例上可能和业务标识重叠也可能和存储标识重叠但它与这两者所基于的观察角度不同。 信息标识是符合“信息格式”章节所定义的格式的字符串。信息标识策略有两个：“单列Guid信息标识”和“多列联合信息标识”，后者的实现基于前者。 理想的情况下对于各种本体类别的实体（Entity）都能找到合理的单列业务标识作为单列信息标识，如对于教师，可以采用身份证号码作为信息标识；对于学生，可以采用学籍号作为信息标识，对于员工可以采用工号作为信息标识，对于上路的汽车可以使用车牌号作为信息标识。但现实中往往并没有一套现成的这种数据可供导入中心节点，并且很多将要与中心节点对接和有潜在对接需求的业务系统在设计时并没有考虑类似身份证号这样的业务标识，虽然如此但它们应该都会有一套自己的标识——如存储标识，虽然各系统自己的存储标识不是像身份证件号这样超越具体系统而有意义的业务标识。 本系统的数据交换协议引入了联合信息标识以应对难以找到单列信息标识的现实，与多列联合信息标识同时引入的还有单列Guid标识策略。多列联合信息标识策略以Guid标识策略为基础。
单列Guid标识策略
单列Guid标识策略为命令的信息标识（InfoID）字段引入了一个约定，约定Guid标识字段对应的本体元素码为”Id”，即如果节点收到信息标识为 ”{‘id’:’ E872A51E-6440-4C49-B5FB-7A1D1CAE4B28’}”或 “{‘id’:’ E872A51E-6440-4C49-B5FB-7A1D1CAE4B28’,’XM’:’张三’}” 的命令则认为该命令使用的是Guid标识策略，只要信息标识中有编码为”Id”的字段则忽略其它信息标识字段（如忽略绿色部分的’XM’:’张三’）。 由中心端为每一个教师和学生分配一个唯一的Guid，各应用系统获取中心端的实体（Entity）记录把中心端的单列Guid标识与自己的本地实体（Entity）标识配对起来。很明显，把各节点的本地标识与中心节点的标识配对起来是一项绕不过的繁杂工作，必需一套合理的策略来应对这个问题，多列联合信息标识策略就是用来处理这个问题的。
多列联合信息标识策略
正如上面所说，单列Guid标识策略可以简单唯一的标识一条记录，但却带来了一个新的难题，就是如何和由谁来制作把各节点的本地实体（Entity）标识与中心节点的单列Guid信息标识映射起来的字典？多列联合信息标识策略就是用来解决这个问题的。简单的说多列联合信息标识策略就是“以多列联合信息标识换取单列Guid信息标识的策略”。如，客户节点向中心节点发送信息标识为”{‘SJHM’:’15261855522’,’XM’:’李白’}”动作类型为”head”的命令，中心节点根据收到的命令返回BetterInfoID字段值为” E872A51E-6440-4C49-B5FB-7A1D1CAE4B28”的建议信息标识的响应结果，客户节点收到建议的单列Guid信息标识后把该标识记录下来并用于建立自己的本地实体（Entity）标识与中心端的单列Guid信息标识映射的映射字典，这就是以多列联合信息标识换取单列Guid信息标识的过程。前面说多列联合信息标识策略是基于单列Guid标识策略的就体现在这里。多列联合信息标识换单列Guid信息标识的流程如下： 根据多列联合信息标识获取单列Guid建议信息标识的过程有时也称配对实体的过程。理想的情况下基于多列联合信息标识策略的客户节点运行一段时间后应可以为大部分实体（Entity）建立起标识映射字典了。但现实上例外总是会存在的，对于余下的配不上对的实体（Entity）就需要人工参与处理了。
资料
Hecp认为基于Http的Restful是错误的，而不是认为Restful是错误的。Hecp认为实现Restful的时候不应借助任何传输层的概念（如不应借助任何Http Method），Hecp认为服务端无需关注任何传输层的状态码（如不应关注Http的状态码，如果传输层使用的是Http则服务端应返回的Http状态码应永远是200，不应处理任何Http的状态码）。 首先Http是超文本转移协议而不是控制协议。通常文档中也会使用“资源”来指代超文本。Http作为一种传输协议其所面向的本体是“资源”。资源包含很多东西，可以分为结构化的和非结构化的两种。视频、声音、图片等都是非结构化的资源，区分结构化还是非结构化的关键是目标资源是否可以被通用软件容易的使用，而视频声音图片等设计为被专用软件容易使用。结构化的数据类似关系数据库定义的数据，它是易于使用的。Http的另一个本体是“转移”，Http的一整套东西都是围绕着“资源”和“转移”这两个本体来设计的，所以是定位符Url而不是标识符Uri。Http是一种传输协议，我们可以语义通顺的说把一个资源从A地“Post”到B地，但是使用Http的Post Method或Put Method表示Create了一个用户是语义不通顺的。Web上的接口大都是控制接口，所控制的不是包罗万象的“资源”而大都是结构化的数据，并且多为实体。
所谓实体是具体本体下的一个具体事物，这个事物可能存在物理世界的真实映射也可以是完全虚构的事物。实体有一个重要属性是必须可以“标识”，也就是说必定可以区分出两个实体的不同。现在和将来在计算机系统中的实体大多是分布式实体。分散在各个节点中的实体需要数据交换，这个“交换”使用控制协议表述比使用“传输”协议更加准确。
如今基于Web的接口越来越多，多的难以控制。究其主要原因是这些接口大多面向功能设计。面向功能设计导致随着业务的变化和新功能的增加接口越来越多难以治理最终发生爆炸，一发不可收拾。基于Web的接口将会越来越多，面向协议的接口设计是大势所趋。面向协议的接口设计是什么样的呢？笼统的说，就是像众多云计算厂商选择的那样的。但某些云计算厂商的接口设计似乎缺乏理论指导。
什么是面向协议的接口设计？可以简单的表述为类似Http那样风格的接口设计。如果表述的更细一些则面向协议的接口设计有“本体”、“元素”、“动作”、“状态码”、“字典”、“实体”、“标识”、“编码”、“组织结构”等概念。其中“动作”类比Http的Method，“状态码”类比Http的StateCode。
但面向协议的接口设计中的“动作”不是Get、Put、Post等“资源”“转移”词汇而是Create、Update、Upload、Download、Compress、UnCompress、Delete、Audit等更具业务意义的“实体”“控制”词汇。面向协议的接口设计的“状态码”和“原因短语”不是Http（数据转移协议）的状态码而是更具业务意义的InvalidApiVersion、InvalidClientType、ExecuteOk、ToAudit等状态码和原因短语，在面向协议的接口设计的接口的契约上不绑定任何Http的Method和StateCode。因为面向协议的接口设计不应绑定任何Http Mehod所以Restful被排除了。 http://www.cnblogs.com/xuefly/p/3428505.html