互联网企业协作

Future Internet 2011, 3, 49-66; doi:10.3390/fi3010049

 

 

 

 

文献

互联网企业协作

Charles Petrie

美国加利福利亚斯坦福，斯坦福大学，计算机科学系，邮编94305

邮箱：[email protected]; 电话: +1-650-269-1516; 传真: +1-650-725-7411

 

接收日期；2010年11月11日 / 接受日期：2011年1月11日 / 出版日期： 2011年2月17日

 

---

                                                                                                                                                                                                               

摘要：目前，企业内外与其他企业通过互联网相连的方式愈发难以管理，尤其是当双方之间的联系愈加动态化。在协调变化所产生的影响，尤其是此类影响正通过网络传播时，当前的方法往往无法扩展。所需的正是互联网如何支持这种协调的新范式。确实，互联网应该且可以提供现今缺失的基本协调功能。在本文中描述了这种“协调性的互联网”是如何运作的。（本文为 [1] 的扩充）。协调性互联网的一项关键功能正是积极观察人类的行为（类似当下在桌面搜索完成），并将此类活动关联，从而在人类当前任务中影响他人，或在受到他人影响时及时通知。为实现此目的，可以将标准的协调功能应用为常见的互联网层，且该层可以被更专业化的应用程序用作实用功能。这样协调的互联网能让企业管理彻底更新换代，且适用于无论大小、共有或私有的所有企业。例如，静态工作流中，除了最常规的流程，其他都将成为过去式。一些解决方案提供了此类协调性基板的存在证明，例如并发工程中的Redux解决方案（本文中提及）。然而，为实现未来互联网中协调性这个基本功能，协调工程中的新领域还有待研讨。

关键词：互联网；企业；协调

 

---

 

1. 1. 从Web 2.0到语义Web服务

 

定义模糊的Web 2.0技术与更前一代之间的主要区别在于，在Web 2.0 阶段，数据的发布更加民主：任何人不用编程都可以发布。如此的互联网（并不只是Web）技术促成了“新兴集体”[2,3] 的兴起，这往往导致了现存经济模型的意外中断。

Web服务带来了动态互联网科技过程中的下一步。准确地说，“web服务”并非只指WSDL [4]，而是指优越于远程过程调用(Remote Procedure Call) 的任何其他技术，因为根据Dagstuhl定义 [5]， 它拥有公开的属性，如SA-REST [6]， 而非自身的REST。

区别具有公开属性的Web服务的效果是，从原则上看，用户可以在未细致了解服务如何实现的情况下，使用公共服务。此类属性的描述应该是“公开的”，因为其比代码子程序库更标准化。此类意图通常被描述为“语义”，下一节会详细介绍。

Web服务应该也是民主的，这意味着服务不会被用户更改。民主的另一个含义，则是现如今的程序可以像人类一样“工作运行”。Web服务也可以是“即时的”，意味着用户可以在没有事先安排的情况下随时调用该服务。

结论便是，我们可以拥有一个自由的服务市场：用户可以在相互竞争的服务之间进行运行时间的选择。尤其对企业来说，这无疑提供了更大的灵活性：只要出现意外情况阻止默认服务的使用，便可以找到替代的服务。

如果民主和及时原则应用于互联网上所有的公共服务，它们将构成一个开放的及时服务自由市场。但由于各种现实原因 [7]，动态开放服务的发展似乎还遥遥无期。

 

2. 2. 服务语义

 

即使是有限Web服务的民主性也严重依赖于服务的标准化属性描述，通常被设想为语义Web [8]。本文其余部分提及的“服务”，其定义如[9]所述，其包括但不限于Web服务。服务可以通过多种方式实现，包括移动应用程序。

探讨“语义”超出了本文的范畴和意图，原先在 [10] 和 [11] 中已有提及。简而言之，我们将语义等同于互操作性：一个增长，另一个也随之增长。如果所有人都采用相同的标准在计算机上表示一切，语义将是完整的。而在现实中，出于不同目的为不同人群提供语义的技术是多种多样的。

服务中对语义有着很强的要求，而这也取决于它们的使用方式。在本文中假设语义的问题最终会被解决，例如通过 [12] 中提到的方式。现在简要讨论此情况发生的部分可能方式，尽管有所偏离重点，但仍然十分重要。

如果需要动态自动组合服务，那么语义和规划技术必须相当复杂。最理想的方式便是使用各种逻辑。但不幸的是，只有学者专家才会理解类似F(−→x , do(a, s)) ≡ γ + F (−→x , a, s) ∨ (F(s, s) ∧ ¬γ − F (−→x , a, s)) [13] 的语句，而他们往往不会很快对行业产生剧烈的影响。开发服务语义最可能的三种场景如下。

首先是“产业服务园区”的发展 [14] 。由于在所谓的“服务型主导的架构”中需要可重复使用性和服务性的组合，因此在这些封闭的应用程序中极其需要语义的存在。这些语义可能更符合子程序的标准化参数，而非逻辑。这样下来的问题则是，逻辑会解决发生概率大的问题，但在匆忙生产中可能却被忽略。

例如，忽视UDDI  [15] 的失败，工业服务园区索引服务更可能按照类别而非具体的作用效果，因为前者更加可行。也不太可能提供复杂的组合服务，因为其目的在于在低级别控制流程。相反，服务属性描述可能足够适用于服务之间预定义的优先关系，从而让大部分将服务定义为具有新功能独特技术的理由站不住脚。其甚至不太可能解决一些基本的问题，例如默认假设（如批准请求）、突发情况和动态重新规划等。

大型供应商的客户可能会要求改进，但在历史上也并非如此。因此，随着问题的暴露和时间的推移，我们或许能看到，表述不清的语义会将变得更为复杂。

网络和移动设备上的消费者应用程序可能会推动垂直市场的简单语义。例如社交网络和基于旅行的网站往往会为人的属性和地理位置唯一标示提供语义。RDF [16] 数据库的使用越来越多，主要引擎也在提供越来越多的语义搜索功能 [17] 。

随着这些应用程序变得更具有互操作性，随之而来的是实用型的解决方案，更能针对分布式的更新和不同的命名空间。对于工业园区，这类的语义可能无法解决问题。然而，此方法的优点在于，一些面向消费者的语言用于表述简单商务服务属性描述时有可能发展，例如想要表达营业时间在太平洋标准时区上午9点至下午5点等，但在不太民主的服务园区中则不太可能实现。

还有一种效果很好的相关方法是开发新的应用程序，例如“SEAmail”[18]。此类应用程序会通过初试设计为特定的应用程序提供足够的语义。这通常会由企业家完成，在此，除了与“全球工作流程”内容无关的内容则不予更多推想。“全球工作流程”是通过语义实现的新工作流程模型的一个可能示例，也是 [8] 中所提及通过语义实现工作流程和协调的第一个示例。

首先是检查静态工作流程中的问题，该问题将被全球工作流程中的动态工作流程所解决。之后则会发现，这只是企业管理进行更激进的变革时所迈出的可能且必要的中间一步。

 

3. 3. 宇宙并不按照工作流程运行

 

如今的企业主要由一组静态流程运行，大体也被称为静态的“工作流程”，该术语在某些情况下的定义可能更为狭窄。重点是，编写此类预定义程序的（工作流程）程序员必须确定公司政策（例如，管理者需要授权超过一定数量的请求）并预见了所有应在将来处理的突发事件。

与此相反，世界上事件发生的原因正是因为物体遵循物理定律而非按照编程。正如抛出球体运动的弧度轨迹并不是由书面程序而定，而是重力和动量定律的结果。即使是发射导弹，也会考虑这些定律并将算法进行物理调整以实现目标。这些定律可以被明确化，并且计算将其考虑在内。如果宇宙也像企业一样运行，这样的物理定律将隐含在代码中，在向预计的方向抛球时，都会计算出一条运动轨迹。

通过这种静态程序管理企业的结果是，管理者永远都无法得知企业的政策是否得到了正确的表述，再结合需要完成的任务和当前的环境，工作流程的用户常常也会被困在一个过于复杂的过程中。如此的静态工作流程也无法轻松响应政策和紧急事件带来的变化。

其中还有供应链的问题，此类问题由供应商的必需变化导致，并且无法通过现在的工作流程处理，举例如下，详见[19]。

• CENTRA为一家汽车公司，需要将CD播放器连接至已通电源的CD分配器上。
• 所使用的技术为一种特殊电源/控制连接，只能有制作连接器的公司断开。
• 任何制作连接器的公司都会同时提供断开连接的服务。
• 每个组件都有2个端口用于连接。
• UNIBUS提供了连接CD组件的服务。
• CENTRA提供的一项服务是可以通过任何闲置的端口将CD组件连接至汽车底盘。
• 提供运输服务的公司可以将组件（连接组件也是组件）在不同公司之间运输。
• CARDs提供CD分配器（在服务中广告）。
• CDsR’Us提供CD播放器和电源（在服务中做广告）

处理此类标准供应链的工作流程，也称为一系列的服务调用，其目的显而易见。组件被运送至Unibus后，按照Centra的指示标准被制作成连接器，之后再将完成的宏组件运输至Centra，最终和汽车底座连接上。

但现在有一个意外情况：CDsR’Us无法按时提供电源。于是，基于语义的属性描述，搜索显示另一家公司WeCDs可以提供连通电源的CD播放器，并可以按所需数量按时交付。先暂时忽略管理的变更，关注点放在如何更改工作流程以利用此解决方案来应对突发事件。

一种简单的工作流程修改方法是将WeCD替代CDsR’Us作为CD播放器和电源组件的供应商。图1中说明了此举的一个小缺点。“计划”箭头所指的是工作流程的构建。

 

图1，工作流程修改

 

简单更换供应商会导致CENTRA无法将最终产品连接至汽车底盘，因为所有的连接器已在使用中。标准的工作流程技术在真正执行前，不会检测到此问题。而昂贵的解决方法则是将整个系统运回WeCD，并要求断开CD播放器和电源，再将结果发回。

在认清世界运转和工作流程技术之间的关系后，此处概述了一种将语义用于动态工作流程系统的方法，该方法可以解决静态工作流程系统的问题。

 

4. 4. 全世界通用的工作流程

 

动态工作流程作为静态工作流程的一个不完整的折中解决方案，对所有人都开放，尽管在某些领域有所限制，但极端地说，是对互联网上的所有人开放。其限制的程度由语义的一致决定。此处勾勒出的一种可能性则更类似一种说明性装置，而非技术性提议。

鉴于商定的语义，可能会有类似Process-XML (PXML)来描述工作流程任务，和一个用于交换PXML消息的协议，以及流程服务器。每个任务属性描述都有一个控制部分和工作属性描述。该任务属性描述会阐明工作流程中的前后任务步骤，以及二者的执行人。前者代表历史记录，后者则代表尚未执行的计划。PXML的控制部分则会包括标准的工作流程控制机构。其中还包括已分配的任务无法在某些时间内完成，或问题出现分裂合并时，应该向谁推送通知。

工作部分描述了任务所需的输入和输出文档。同样，提供的输入文档也是执行历史的一部分。输出文档则是计划的，并构成了完成任务的当前标准。此处“文档”的概念可能非常抽象，甚至包含了任务完成的声明。此外，可能还会有与任务相关的前后条件。前者应该在任务分配时已经满足，后者应由任务参与者满足。

在计划的工作流程中，任务被分配给参与者，但该流程可能并不完整。工作流程由中央服务器监控着。工作领域内（可能是整个开放的互联网中）的任何人都可能收到分配的任务。这可能是对任务进行公开拍卖的结果，亦或是搜索能力足够参与者的结果。

在接收到分配的任务时，参与者可以拒绝或接受。参与者还可以通过修改输出文档和后置条件，以及PXML描述任务的控制部分来调整改变工作流程。唯一无法改变的是截止至当前对执行历史进行描述的部分。除此以外，正因为PXML为可修改的描述属性，对计划工作的实际工作和控制部分都可能会有变动。

任务完成后，新的PXML会被发送至另外一个或多个任务分配者。然而，在接收之前，调解通信的流程服务器可能无法支持此类更改，因为其违反了特定的政策约束，或是因为其无法依据变更重新计算可行的工作流程。而个人参与者可能施加约束的程度，例如指定强制性的输入/输出，也需要进一步的设计分析。

互联网上的任何人都可以使用如此的开放型工作流程。具体要求如下：（1）商定的消息和任务语义，（2）客户端软件可以接收、编辑和发送消息，（3）与中央服务器通信（其中可能会有用于不同目的的多个服务器）。该软件可以是基于Web、电子邮件或应用程序的任何软件。

[3] 中描述的“快闪公司”的愿景将成为现实，随着优化任务描述需求的出现，如拍卖等垂直市场中可能会迅速出现合适的语义。

重点是需要认清，工作流程技术的下一阶段是动态工作流程。一旦认清到这一点，距离工作流程完全成为过去时也就不远了。

用于开放式全球范围的工作流程的初始流程模板可以通过组合服务的先进技术来指定，正因为任务和服务的语义将大致相同。

更重要的是，任务参与者的更改导致了工作流程的重构，为了确保落实，则需要某种形式的动态流程综合和重新规划。收到提到的参与者会注意到全球性的工作流程协议本身并不能解决第三部分提到的供应链问题，就算对可互操作的动态流程有了足够的语义也是如此。动态流程综合和所需的重新规划技术是完整的AI计划，其中涉及到第二部分中提及的类似公式，尽管该公式对用户不可见。这就导致了更激进的愿景。

 

5. 5. 企业物理

 

过去十年出现了很多用于动态组合Web服务的技术。如果能够发现并运用具有通用描述属性的可重用服务，新流程则可以自动实现动态组建，以按需达到基于状态的目标[19]。此举将让世界工作流程的重新定义成为现实。但那时，人类已经不再需要工作流程了。

给定一个目标，例如报销差旅费用，可以为此创建一个新的流程，即时这个流程只能在这次让一个人完成一次报销。而本次流程需要考虑的问题为企业现有的政策， 如上级经理必须批准的金额以及成为经理的条件。

公司内部和跨公司项目中的个人可以根据需要合成工作流程和其他流程。公司可以通过明确此类流程需要遵循的政策和约束来管理该流程，而不是相信编程者能正确解释此类政策，或等待新政策静态编码的完成。这便是企业物理。

这样的动态过程应该并允许变更：如遇突发事件、矛盾、新机遇、政策修订和完全失败等。

这又确实是一个封闭的世界，因为所有的模型都是封闭的。值得注意的是，在某些情况下，该模型仅能在内联网的范围内使用。尽管如此，这个模型也比静态工作流程中一成不变的代码所指代的当前模型更好。一旦政策发生变化并明确阐明，所有流程合成体将立即明确地将其考虑在内。对于任何突发情况也是如此：一旦明确阐明，模型和实际执行便会变化，因为在企业物理中，模型正是执行的内容。

有多种方法可以实现企业物理。最简单的方法如[20]所示，其中关系数据库和规则明确表明了公司的策略。最开始的优势便是，只需编写一次，便在所有情况下都可自动使用。此外，所使用的技术类型也越来越为企业IT所熟悉。

不太为人所知的是各种形式的计算逻辑，范围涉及数据记录到完整的一阶逻辑。这意味着几乎任何种类的策略都能在计算中得以表述和使用。此类逻辑的一大主要优点是，查询的答案可以全方面考虑，快速并自动提供非常复杂的信息。

微分逻辑的一些新研究提供了有效计算工作流程的方法[21]。企业的“法则”可以由授权的管理人管随意编写和更改，之后用户可以在系统中查询一些问题和流程，且其确保正确并能遵循所有的政策和约束条件，因为其本质上是逻辑的证明。

服务为动态流程提供了一种重要方法，前提是其具备足够的语义描述，如世界性工作流程的任务。在过去的十年中，许多论文中已经发表过有关自动组合服务的AI规划方法。基本上有两种方法：静态工作流程的自动生成和一次性流程实例的按需动态生成。本文更提倡后者，并在 [19] 中解释了方法。

流程的完整演绎（即基于逻辑证明）的组合能确保流程正确无误且无需验证。当使用完整规划（相比于原始的反向链接）时，第三部分所需的联合目标则能得到处理。

最后，额外的好处是用户知道该流程是为当前问题或为了实现当前目标和制定，且该流程能够解决问题。但并没有确切方法可以找出静态工作流程实际实现了什么。

这对于流程合并来讲尤为重要。当使用静态流程完成此操作时，例如当两家公司需要合并流程来合作时，最终流程则需要验证，以确保其安全性和灵活性，但并无证据表明其符合任何特定的目标或最终状态。相比之下，演绎综合下的流程无需验证并确实可以达到特定的最终状态。

尽管这需要企业IT的重大变革，但各种关系数据库和形式逻辑，以及服务和AI规划，都能为企业物理提供可证明的解决方案：运行必须遵守明确的企业法规，并构建正确的流程以实现目标。

对此技术愿景的一个（多个）反对意见便是其无法扩展。然而，可能发生的情况是，对基于逻辑技术的解决方案会扩展，但并非是扩展现有的方法以满足高度复杂且动态化的分布式全球供应链，特别是通过网络服务和基于移动通信的服务产生的使用越来越多。

在此（最后）提出如何管理全局动态过程的问题，即本文的主题。如果全球动态流程中，不同企业的各种参与者同时响应突发事件和新的机遇，结果可能是无法控制的混乱，这也是目前存在静态工作流程的原因。

 

6. 6. 协调互联网

 

如果可以实现动态过程的愿景，那么未来的互联网环境可能，甚至必须成为“协调性互联网”。这个愿景将是一个“积极主动”的互联网环境，其不仅能促进共享和协作还能积极协调人类和不同程序，尤其是分布式动态流程中提供且被消费的服务。与其形成对比的是单纯的协作，其中的系统只支持人为发起的信息共享。

协调的其中一个定义便是以来管理 [22]，这意味着某些系统内的更改会根据某些模型进行传播。更具体地讲，本文所说的“协调”是在一般情况下是指设计（尤其是流程）中给正确用户推送的异步通知。流程组件依赖于彼此的特色功能，并当该种功能发生变化时，有时流程也会改变，但正确用户也会收到关于该变更传播影响的通知。

谷歌文档 [23]中提到了非协调性协作机制的示例：其管理内部的依赖性以保持文档的一致性，但对协调用户并无大用。这种系统邀请用户之间共享，但不会帮助其工作：作者必须相互邀请才能共享文档。

有限协调机制的一个示例便是逻辑电子表格 [24] 的协作版本，当一位用户在其显示器上修改字段时，互联网中其他电子表格内的相关字段都会出现对应的更新。而当此系统检测到冲突（如违反限制）且该冲突没有定义的自动解决方案，其必须通过某种方式通知所有相关的用户，原型中会以修改收影响字段的颜色来展示。这个小例子则是系统通知受影响用户并提醒其采取行动的方式。

协调型互联网远不止于此：它会观察人类行为 （类似今天在计算机上完成的搜索），将活动关联并主动通知其当前任务受到或影响他人活动的时间和方式。示例通知包括发生的冲突和涉及的人员，以及要求的安全一致的解决方案，持续的警告，协同机会以及不再需要的任务。

一个有用的小窍门便是可以增加协调性，但不会惹恼用户。可以通过查看未来分布式的供应链来了解最低的要求是什么。

 

7. 7. 未来供应链场景

 

未来汽车制造商不会再生产汽车，只会管理流程。理论上DellAuto的供应链中，底盘部件在上海制造，之后由墨西哥的ChassisMax组装，再被运往斯图加特的EnginesR’US。现在假设有一个新机会：位于塔斯马尼亚的AssemNow可以以更低的价格在更短的时间内制造接下来的20哥地盘。动态修改DellAuto的供应链需要什么条件？

首先，必须检查和ChassisMax取消当前订单的合同返款是否小于采用AssemNow节省下来的费用。如果是，则需要向以下人员发出以下通知：

• 在ChassisMax取消订单，在AssemNow重新下单。
• DellAuto的财务部表示不再需要向墨西哥银行存款。
• DellAuto财务主管表示应取消ChassisMax的预付款，并支付罚金。
• DellAuto的订单部门表示应向AssemNow发出采购订单。

无需通知EngineRUs，因为与运输服务交换的消息显示底盘将在原定日期到达斯图加特。协调系统只会注意到变更产生的影响，这是由于其通过相互的依赖传播，但并不会因为变更的发生就会发出无用的通知。

此项功能的影响可能会改变世界，不仅仅是会改变公司的管理方式，更是足以改变任何大型企业的运作方式，尤其是一些零时企业，如提供全球灾难性救援的企业 [25]。

如前所述，遇到工作流程无法处理的供应链场景时，便需要新的技术。如果没有一些协调机制，即使是用世界工作流程处理DellAuto的供应链问题也会很难。有多种方法可以处理对依赖项及通过其传播的变更的管理。[26]中逻辑电子表格机制想实现此目的，则可以通过察觉逻辑表达是否有“假”并指出能得到该不一致结论的参数值即可。这需要超高的一致性：即使存在逻辑不一致的情况下也能够进行合理明智的推理十分管用，因为分布式系统中的许多来源都可能会产生逻辑的不一致 [27]。

[28]中提出了另一种通用技术，其中表述了Web服务的依赖关系。如逻辑电子表格一样，这其实是一个广义的依赖概念。尽管二者都提供了识别冲突变量值分配所有者的基本机制，但都没有特定的通知方式。

本文在下一届中总结了一个详尽描述协通知的解决方案，该方案在现存的工程领域 [29]早已存在，并且也是一种模型，其中包括多种情况下通用设计的特殊依赖项。该模型还专门定义了一组在特定情况下发送的通知。

 

8. 8. 一种协调机制：Redux

 

协调互联网可以被视为分布式参与者处理配置货规划问题时的管理方式。当出现多个目标切并无单一目标功能时，正如大型项目中有多名工程师，最佳的优化方法便是确保在不损害另一个解决方案的同时进行改进，即帕累托最优。

Redux设计模型作为Redux’ [30] 中的子集，在设计模型 [31] 中使用了帕累托最优。完整的Redux模型是由编程模型衍生出的一种计划，操作者被选中以应用于目标，此举便被称为“决定”，其结果必须是一个新的目标或一项新的分配。后者可能是变量赋值，但通常则可能是关于合并设计的任何声明。

完整Redux的一般方法可以被认为是面向目标或操作者的编程。系统的子集Redux则管理了所有Redux对象之间的依赖关系，其具体有效性取决于变更及其定义的传播方式。

完整的Redux可用于实现完整AI计划和企业物理所需的流程综合。Redux是底层的协调引擎，几乎可以用于满足企业物理所需的任何计划和推理系统。并且，Redux实现了一个专门的依赖管理模型，且普遍适用。

逻辑电子表格和大多数通用的依赖管理方法只会考虑这种退化的情况，并且该情况下，每个决定都能准确地分配单值变量的值，反而不适用Redux。然而，许多协调情况需要更加精细的目标和决策。

给定冲突（如违反约束条件或阻止目标达成）和解决方案（即某种设计决策的修整），在使用基于理由的真相维护系统（JTMS）时，且当解决冲突的方法不止一种而导致依赖导向回溯（DDB）无效时，Redux在构建此类冲突修正理由时便会强制执行帕累托最优。如此的理由不应将任何不满足条件的循环导入JTMS网络。

图2中说明了具备简单冲突的Redux模型。两位参与者，A1和A2分别尝试通过决议D1和决议D2来达到其个人目标。当两者均有效时，便导致了分配A1和A2，并进一步导致违反了相关约束。在这种情况下，由于没有其他决议支持此类分配结果，因此如需解决冲突则需要撤回D1和D2.且两位参与者都不能撤回对方的决议。双方都会收到有关冲突的通知，并有权请求可能的解决方案清单。

 

图2：Redux示例冲突

 

如果A1想要撤回D1，Redux便会让目标G3失效。这不会让决议D3失效，但会使其失去最优性。之后D3的所有者会收到一条通知，告知其将不再需要D3且可以将其撤回。如果该所有者决定如此，之后的G4和G5也会收到同样影响，且这两者的拥有者也会收到相似的通知。

A1也会收到这样的通知：即使G1先前已被实现，但由于其所有的子目标都已实现，现今的情况已经不再如此了。如果A1做出新的决议来满足G1，则撤回D1以解决冲突的选择就成了该新决议最优性的基础。无论是已违反约束的约束，还是决议D2失去其有效性（出于各种原因），该项新决议的这种最优性理由都会变得无效，且A1会收到通知，告知其现在有机会返回最开始的决议（可能是最初首选），且 不会引起最初的冲突。

Redux模型的显著特征包括：（1）区别开需要实现的目标和不应违反的约束；（2）区开影响决议最优性及其有效性的条件；（3）区别开因失去帕累托最优而产生机遇以及冲突。

区别开需实现的目标和不应违反的约束已证明在配置技术中普遍有效 [32].实现目标或解决约束则是Redux管理的两种类型任务。

逻辑电子表格（以及约束满足系统）通常将所有内容都表述为约束，但当无法自动确定约束解决方案且用户必须选择时，则有了隐晦的目标。某些版本的逻辑电子表格也存在不完整性，比如，当存在“其中之一”类型的约束时，也能算是一种目标。

当前的一个商业系统 [33]也明确表示了这种变量选择的必要性。Redux将这个概念扩展到必须以某种方式实现的一般目标，因为这是AI规划的抽象概念，当遵循特定约束（通常是时间的序列）时，至少某些状态应该实现。

最优性和有效性之间的区别对于管理变化的传播十分重要。在Redux中，决策的最优性取决于其适用目标的有效性以及各种原因，其中这些原因可能还是环境事实。

在完整的Redux中，其最优性原因用于推理操作员用以实现目标的最佳方案，但其可能也是决策者想要说明的任何原因。例如，选择航班最基本的原因，可能和费用有关。如果（在购买机票之前）费用有所更改，则应该通知用户选择此航班的原因也已经更改。但是，这个计划不应该自动改变，因为可能和某种意外事件的发生有关，例如航班取消。（完整的Redux中包含偏好的概念，其可以根据明确注明的二元偏好，允许选择部分操作员，并记录此举的原因，因此其中可能是完整的一阶逻辑，以及解决冲突的最佳方案推理。此功能可用于企业物理中以建立公司策略，尽管不能用于决定全球最优性，但这本身在通常情况下便是不切实际的。）

一般来说，仅仅因为失去最优性便取消决议有效性并不是一个好想法，这不仅会导致分布式设计中的变化传播，并且这样做根本不值得。例如，就因为出现了一个新的航班，其价格比原先预定的航班低了2欧元，这趟新的航班根本就不值得让人改变包含多个航班的旅行计划。

失去最优性有效性的一个特例则是帕累托最优损失。如果用户为响应冲突，撤销了第一个决定并为实现同一目标而作出第二个决定，Redux便会假设第一个决定为局部最优，并构建一个特殊的理由来合理解释第二个决定的最优性。如果变更让最初的冲突无效，则该解释也无效。

例如，如果另一位决策所有者（出于某种原因）撤回与第一个决策（现已撤回）有冲突的第三个决策，则可以再次作出第一个决策，这也表明其失去了帕累托最优性。另一方面，由于Redux中的约束可能只在某些条件下有效，如果最初的约束失去有效性，也会导致帕累托最优的损失。在所有的情况下，决策所有者都会收到通知，告知其有机会重新作出原始的决策。

Redux中提供了一组对主动协调有效的通知，[30]中有对其的正式定义。最简单的例子就是，先前例子中的超级任务实现方式有所改变，子任务便会显得多余。

Redux模型中内置的一组通知示例如下：

• 你被分配到了一个任务
• 由于更高一级的决议无效，你的目标也随之无效
• 你的决议应被重新考虑因为
• 原因有所改变
• 之前的决议不再有冲突
• 你的目标无法再满足因为
• 对你决议的输入无效
• 子目标无法被满足
• 你促成了约束的违反/目标实现的障碍
• 以下为你要求的已知且安全一致的解决方案选项

在某些情况下，在不造成约束冲突的情况下根本无法实现目标。用户可能会将其称为目标障碍。目标障碍冲突几乎和违反约束一样。DDB积累了所有使目标无法实现的约束违例，所涉及的系列决定都被用作给决定所有者发送通知。如果要解决目标障碍的问题，至少一位必须撤回其决定。

Redux还保证决定者的变更不会导致循环的波动，并在分布式环境中，通过对决定原因和冲突产生的原因的管理，确认出解决冲突和目标障碍的安全方案。

在二者同时发生的情况下，AND/OR决策树中通过撤回来解决冲突的最小子集则会自动生成。此类的解决方案是安全的，因为其不会在网络中引入不可满足的循环，并且在包含的意义上也是最小的子集。Redux中使用动态的DDB版本可完成以上决策树的计算。虽然基于假设的真值维护系统（ATMS）通常会在所有可能的世界中计算此类选择的最小子集，[33] 中提及的基于ATMS的约束处理系统也会对此按需进行动态计算。

 

9. 9. 影响

 

Redux的通知可能是代理、服务或一般应用程序之间交换的正式消息。ProcessLink [34] 则是将Redux用作协调管理器的原型并发工程系统。其为基于代理的一个系统，其中包含了一组可在各代理之间交换的定义明确的信息。

图3为典型的ProcessLink架构。值得注意的是，不用设计师之间的设计协调可以扩展至构建设计的计划中，因为其计划本身也是一个设计。在 [29] 中描述了设计系统如何通过通知与构建计划系统相联系，以便当未完成的设计发生变化时，时间表会自动优化以响应此类变化。

图4中，左侧为设计人员界面（Java应用程序中），右侧则为计划构建者的界面。最上的两个界面展示了拾取头（PUH）的最初设计及其构建时间表。最初，PUH为定制设计，因此其重量直到建成之后才能得知。因此必须在PUH建成之后安排其机械支持，因为必须将支撑设计成正确的强度。

左下的界面中，设计师决定不再定制PUH，而是选择使用业内已有的PUH。旧的设计则被标记成了红色以代表其无效性。依赖这个旧决定的任务和一个子目标也被标记成了红色。而新决定（绿色标记）的其中一个新任务便是我们从PUH的规格中得知了具体的重量。

图3 ProcessLink架构

图4 设计/计划协调

设计系统针对此更改对计划系统发出通知。同样使用Redux的计划系统发现只有在PUH建成之后才有的机械支撑计划成了次优决策，并可以对其进行修改。如果计划者在编程控制下作出这样的操作，则可以将其设计为自动修改并使整个计划缩短。

很明显，这样的功能是允许快速设计的，即在设计完成之前就可以开始建造。但总的来说，对构建者、总承包商、检察院和各种分包商之间的协调能力是非常需要的，并且可以显著减少任何大型项目上所需的成本和时间。

这显然也延伸到了即时供应链里，尤其是当语义服务允许发现更佳的服务和产品，以及所需构建供应链的动态合成流程。

这同样也延伸至任何大型的人为尝试和努力中，例如协调灾难救援，对小规模也同样适用，例如组建乐队以及场所预定和旅游的设计。很容易看出，垂直领域中将开发出专门的“向导”应用程序，以加快此类计划的构建以及对其执行和修订的管理。

企业协调是互操作互联网的下一个飞跃。

 

10. 10. 协调工程

 

Redux是协调互联网所需的协调依赖管理和通知模型的存在证明。尽管正如本文所述还有许多尚未完成，但用于管理文中描述的场景则是绰绰有余。

除了Redux之外，还有其他协调模型已经Redux尚未解决的突出问题。Redux的特征则可以作为 [27] [28] 中的扩展来实现。

在任何情况下都可能需要超一致性的方法，因为在任何分布式的复杂系统中一定会出现逻辑上的不一致。但值得注意的是，Redux和 [33]中的系统都是基于真值维护系统的版本，其中的节点是命题，除了检测任意而非合乎逻辑的约束违例之外没有其他的推理。

然而，完整的Redux确实使用逻辑推理来推理操作员的选择、下一步的工作目标以及各种条件。尽管合理的节点并不是此推理的一部分，但潜在的事实却是，并且可能需要超一致性。尽管Redux对推理方法不可知，甚至可以在此使用一些 [35]中提出的非演绎方法。

总体来说，协调工程领域还需要有更多的研究。其主题可以包括用于检测和理解当前任务和过滤通知的适用技术，以便其有助于 – 而非分散注意力或干扰人类。

已知的研究问题包括 （1）理解如果将约束满足技术和 DDB [36]相结合；（2）更好的底层合理化图示控制算法；（3）更好地表达承诺的动作和沉没成本；（4）在供应链中提供合适的信息透明度。第四点尤其具有挑战性。供应链中的终端供应商需要知道供应链下游供应商的进度和产品变更。很明显，此类信息可以按需在供应量往上传递，但很难让其他供应商看不到这样的信息，由于竞争冲突，这样的信息隔绝还是很有必要的。

另一个普遍的计算机科学问题便是解决冲突。Redux中没有建议何种解决方案更适用于解决何种冲突。依赖领域偏好和独立领域偏好的建议泛多。（例如，当只有一个选择时，该决定可以自动撤回。）尽管此项研究的大部分都是与提供最低限度一致的答案子集有关，但当数据库不一致时，其与进行中的工作之间也有联系。

在理想情况下，协调还应为用户提供建议以便其考虑更改决策。这在三个层面上可以完成。第一种是被动模式：考虑传播提议的决策变更影响并报告计算出的结果。第二种是主动“ping”：通知所有其他决策所有者并考虑其反应。第三种是Redux的现状：进行变更并与其他人合作解决由此产生的冲突（如有）。如何最好地实现这样的功能则是一个很好的工程问题。对决策修订和解决冲突而言，使用敏感性分析并提供指导是非常有趣的科学性问题。

有关互联网中实施协调的细节问题涉及协调功能的哪些部分应嵌入互联网的哪一层面。例如，消息通知可以有智能路由器和分布式服务器处理吗？“观看”功能是否应该在浏览器插件和移动设备应用程序中实现？在ProcessLink的前身Next-Link [31] 中，标准工程程序中被手动插入了代码。有没有更有扩展性的方法？

协同互联网与物联网也有同样的深度问题，例如更改产品和服务属性描述的授权。

协同互联网为计算机科学提供了丰富的研究新课题，并有可能从根本上提高人类管理复杂项目的能力。人类有着足够的技术开始对其的构建。

 

 

 

参考及备注

1. Petrie, C. The Future of the Internet is Coordination. In Proceedings of FES-2010: Future Enterprise Systems Workshop 2010, Berlin, Germany, 20 September 2010.
2. Petrie, C. Emergent Collectives for Work and Play. Available online: http://www-cdr.stanford.edu/∼petrie/revue/ (accessed on 13 January 2011).
3. Petrie, C. Plenty of Room Outside the Firm. IEEE Internet Comput. 2010, 14, 92–96. Available online: http://www-cdr.stanford.edu/∼petrie/online/peer2peer/vision2010.pdf/ (accessed on 13 January 2011).
4. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. Available online: http://www.w3.org/TR/wsdl20/ (accessed on 13 January 2011).
5. Dagstuhl Seminar on Service-Oriented Computing Session Summary Cross Cutting Concerns. Available online: http://tinyurl.com/webservdef/ (accessed on 13 January 2011).
6. SA-REST: Semantic Annotation of Web Resources. Available online: http://www.w3.org/Submission/SA-REST/ (accessed on 13 January 2011).
7. Petrie, C. Practical Web Services. IEEE Internet Comput. 2009, 13, 93–96. Available online: http://www-cdr.stanford.edu/∼petrie/online/peer2peer/practicalws.pdf/ (accessed on 13 January 2011).
8. Berners-Lee, T.; Hendler, J.; Lassila, O. The Semantic Web. Scient. Am. 2001, 184, 34–43.
9. Petrie, C.; Hochstein, A.; Genesereth, M. Semantics for Smart Services. In The Science of Service Systems; Demirkan, H., Spohrer, J.C., Krishna, V., Eds.; Springer: New York, NY, USA, 2011, in press.Future Internet 2011, 3 65

10. Petrie, C. The Semantics of Semantics. IEEE Internet Comput. 2009. Available online: http://www-cdr.stanford.edu/∼petrie/online/peer2peer/semantics.pdf/ (accessed on 13 January 2011).
11. Petrie, C. Pragmatic Semantics. IEEE Internet Comput. 2005, 9, 95–96. Available online: http://www-cdr.stanford.edu/∼petrie/online/peer2peer/w505.pdf/ (accessed on 13 January 2011).
12. How to Publish Linked Data on the Web. Available online: http://www4.wiwiss.fu-berlin.de/ bizer/pub/LinkedDataTutorial/ (accessed on 13 January 2011).
13. This is a standard formula used in the formalization of planning of web services among, other actions.
14. Petrie, C.; Bussler, C. The Myth of Open Web Services—The Rise of the Service Parks. IEEE Internet Comput. 2008, 12, 94–96. Available online: http://www-cdr.stanford.edu/∼petrie/ online/peer2peer/serviceparks.pdf/ (accessed on 13 January 2011).
15. UDDI/BSR Requirements Gap Analysis. Available online: http://logic.stanford.edu/talks/gap/ (accessed on 13 January 2011).
16. RDF/XML Syntax Specification (Revised). Available online: http://www.w3.org/TR/ REC-rdf-syntax/ (accessed on 13 January 2011).
17. Introducing Rich Snippets. Available online: http://googlewebmastercentral.blogspot.com/2009/05/ introducing-rich-snippets.html/ (accessed on 17 February 2011).
18. Kassoff, M.; Petrie, C.; Genesereth, M. Semantic Email Addressing: The Killer App? IEEE Internet Comput. 2009, 13, 30–37. Available online: http://logic.stanford.edu/sharing/ Papers/sea-ic.pdf/ (accessed on 13 January 2011).
19. Petrie, C. Planning Process Instances with Web Services. Available online: http://logic.stanford. edu/sharing/papers/IVIS09-serviceplanning.pdf/ (accessed on 13 January 2011).
20. Date, C.J. What Not How: The Business Rules Approach to Spplication Development; Addison-Wesley: Boston, MA, USA, 2000.
21. Genesereth, M. Stanford Logic Group, Stanford University, Stanford, CA, USA. Private Communications, 2010.
22. Malone, T.; Crowston, K. The Interdisciplinary Study of Coordination. ACM Comput. Surv. 1994, 26, 87–119.
23. Google Docs. Available online: https://docs.google.com/ (accessed on 20 January 2011).
24. Kassoff, M.; Valente, A. An Introduction to Logical Spreadsheets. Knowledge Engineering Review; Cambridge University Press: Cambridge, UK, 2007; Volume 22, pp. 213–219.

25. Petrie, C. Collective Work. IEEE Internet Comput. 2008, 12, 80–82. Available online: http://www-cdr.stanford.edu/∼petrie/online/peer2peer/collectivework.pdf/ (accessed on 13 January 2011).

26. Kassoff, M.; Genesereth, M. PrediCalc: A Logical Spreadsheet Management System. In Proceedings of the 31st VLDB Conference, Trondheim, Norway, 2005; pp. 1247–1250.

27. Bertossi, L.; Hunter, A.; Schaub, T. Introduction to Inconsistency Tolerance. In Inconsistency Tolerance; Springer: Berlin/Heidelberg, Germany, 2005; pp. 1–14.

28. Tolksdorf, R. A Dependency Markup Language for Web Services. In Proceedings of Net.ObjectDays 2002 Workshop, Erfurt, Germany, 7–10 October 2002; pp. 573–584.Future Internet 2011, 3 66

29. Petrie, C.; Goldmann, S.; Raquet, A. Agent-Based Project Management. In Lecture Notes in AI 1600; Springer-Verlag: Berlin, Germany, 1999. Available online: http://www-cdr.stanford.edu/ProcessLink/papers/DPM/dpm.html/ (accessed on 13 January 2011).
30. Petrie, C. The Redux’ Server. In Proceedings of International Conference on Intelligent and Cooperative Information Systems (ICICIS), Rotterdam, The Netherlands, 12–14 May 1993. Available online: http://www-cdr.stanford.edu/ProcessLink/papers/redux-prime.pdf/ (accessed on 13 January 2011).
31. Petrie, C.; Webster, T.; Cutkosky, M. Using Pareto Optimality to Coordinate Distributed Agents. AIEDAM 1995, 9, 269–281. Available online: http://www-cdr.stanford.edu/NextLink/ papers/pareto/pareto.html/ (accessed on 13 January 2011).
32. Wielinga, B.; Schreiber, G. Configuration-Design Problem Solving. IEEE Expert 1997, 12, 49–56.
33. Haag, A.; Rieman, S. Product Configuration as Decision Support: The Declarative Paradigm in Practice. 2010, in preparation.

34. ProcessLink. Available online: http://www-cdr.stanford.edu/ProcessLink/ (accessed on 13 January 2011).

35. Fensel, D. Unifying Reasoning and Search to Web Scale. IEEE Internet Comput. 2007, 11, 94–96.
36. Petrie, C.; Jeon, H.; Cutkosky, M. Combining Constraint Propagation and Backtracking for Distributed Engineering. In Proceedings of AAAI’97 Workshop on Constraints and Agents, Providence, RI, USA, 27–31 July 1997; Technical Report WS-97-05; AAAI Press: Menlo Park, CA, USA, 1997.

⃝c 作者注于2011年，供瑞士巴塞尔MDPI刊登。本文为符合开源协议条款和条件的公开文章。 (http://creativecommons.org/licenses/by/3.0/.)