| 服务器架构拓扑图
结构说明：
一、缓冲方案
二、客户端优化
三、通信协议支持
四、服务器说明
五、关于存储类型
六、任务执行器
七、集群部署与维护
八、WWARE推荐的开发方法
一、缓冲方案
1. CDN友好的静态化
传统CDN只缓冲静态资源，例如图片，JS，CSS等很久不变的内容。对于数据库动态创建的内容而言，使用CDN缓冲，性能还会有所下降。WWARE的缓冲机制改变了这一点，CDN可以缓冲所有的内容——无论静态内容还是动态内容。
WWARE默认的缓冲机制是，所有Web controller创建的内容，默认具有长生命周期，只有内容依赖的资源变动时，由Web controller刷新除Browser层之外的缓冲。这允许我们静态化全部内容，极大提升缓冲性能，非常适合于内容刷新周期慢的应用场合——例如商品详情，一次更新，很久不会变化。在其不变的时间内，其内容被当做普通页面被CDN分发，这将会极大提升用户体验。
对于频繁刷新的内容，例如聊天。可以关闭其缓冲特性，则默认客户端会自 动通过api.YOURDOMAIN来绕开CDN。WWARE正在支持运行期的频度检查，如果检查到更新频度过快，会自动临时关闭CDN缓冲。这个特性尚未支持完毕，目前需要手动指明是否绕开CDN。
2. 碎片化缓冲
传统的页面拼装发生在逻辑层，这导致缓冲内容必须以页面为单位，大幅降低了缓冲效能。而WWARE的缓冲以小于页面的逻辑块为单位，通过将页面拼装前移到CDN层来提升缓冲性能。例如，一个页面，如果只有右上角一个小块(DIV)是用户信息，构成其它内容的块都属于公共信息。则每次组装只需要请求最小的右上角的块，其它块都从位于CDN的缓冲中获取，从而大幅降低了服务器压力，并提升了访问速度。
碎片化缓冲还带来一个额外的特性：高复杂度页面的实现更简单，性能更佳——而且复杂度越高，这个特性越显著。这是因为WWARE可以任意将页面拆分为多个逻辑部件，这导致每个拆分出来的视口(View)所涉及的数据规模在下降，逻辑关系也在下降，从而每个视口的逻辑关系(数学公式)更简单，因此更容易实现。而随着视口增加，由于碎片化缓冲，不同视口被分发到不同的控制器去处理(并且独立缓冲)，这个过程是全并行的——只要部署的控制器数量不成为瓶颈，其执行速度比原始复杂单页面版本更快，意味着用户可以更快得到结果，而无需等待。因此，WWARE为我们带来了一个打破传统概念的特性：你把复杂度拆的越低，就意味着性能越高。
3. 浏览器级优化
由于不同浏览器支持的特性不同，对不同资源的处理性能也不尽相同。在CDN的最前端，会根据UA信息，构建浏览器的特性表。根据这个特性表，再对内容执行一次最终的优化——完全针对浏览器级的优化，并缓冲起来，为下次相同特性的浏览器直接返回。这会最大化利用访问者的浏览器能力。
4. 智能信标(Smart Beacon)
网络应用的挑战之一就是多级缓冲机制引发的数据同步问题——也就是在保障用户与最新数据交互的前提下，如何尽可能的多级缓冲数据？我们采用信标(beacon)技术来自动克服这一困难。WWARE为应用创建全自动智能信标，首先将所有的动静资源分离，包括HTML，会被自动拆分为静态部分以及依赖资源(通过ajax获取)两个部分；然后将所有资源的同步信标集中在HTML页面上，HTML页面被设置为对浏览器无缓冲(此特性不能使用传统CDN)，任何资源的内容发生变化时，会获取到新的唯一URL并自动更新HTML，并且根据这一新资源的依赖资源缓冲状态设置其缓冲特性，以确保缓冲一致性（您访问WWARE创建的网络应用时，变动某些数据，并审查页面内容，会发现其引用的资源URL会发生变化，并且这些资源一定是对缓冲友好的）；最后，使用appcache技术，将HTML页面的信标设置在appcache上。需要注意的是，即便动态数据部分(即使用ajax获取的部分)也遵循这里描述的信标机制以获取最大的缓冲性能。而且，这里描述的复杂过程由WWARE全自动完成。您可以断开网络链接，并访问WWARE创建的可离线项目，会发现其在无网环境下依然正常工作。智能信标帮助我们达到一个伟大的目标：让页面首次打开速度为秒开；二次访问速度为瞬开(小于动画两帧间隔时间，通常是10~30毫秒)。这一目标意味着，无需安装的浏览器轻应用，也可以无网工作，并且性能将会超越绝大多数访问本地数据的APP。这将大幅提升用户使用Web应用的体验，并大幅降低应用推广难度和费用。
二、客户端优化
我们会在用户浏览器上执行wwclass.min.js。这个文件作为集群控制的最前端，执行如下任务：
1. 根据当前视口信息，决定加载顺序。换言之，除了主文件，其它资源只有必要的才会被直接加载。这显著降低了从DOMContentLoaded到load之间所需加载的资源。所有非直接显示的资源，会被延迟加载，而这个延迟，访问者是体会不到的，只能感觉到页面加载速度很快。因此这个特性会大幅提升用户体验。
2. 定义了客户端的VV模型。整个wware以MVVCP模型构建，其中，浏览器支持了VV两层，并可以通过wide(Wware IDE)全图形化编辑，而WWARE编译器支持了MP两层，C由人工输入业务逻辑，WWARE编译器产生最终代码。现在，客户端的数据绑定基于knockoutjs,逻辑派遣基于anijs,而服务器端的规则寻找基于swi-prolog，规则训练基于fann及tensorflow。
3. 维护客户端的双向通道。WWARE支持websocket（当前版本尚未兼容旧的commet协议）。在websocket基础上，使用stomp协议来执行双向通信。并且ws通道与ajax通道支持相同的基于数据绑定的VV命令原语，从而让重客户端应用开发变得简单而有趣。
4. 执行客户端的容错。当检查到部分服务器失效时，自动寻找下一服务器。对于使用heart-beat切换服务器的机制是一个补充。但是在分布系统下，其扮演了分发中心的角色。
5. 执行客户端组装，以最大化利用所有数据集群的能力。例如，一个页面中，频繁更新的用户数据部分从controller直接获取，而其它内容从CDN获取，在客户端组装在一起。您注意到某些页面，显示出来之后，会有部分内容转圈，并显示加载中，就是这个部件在工作。
6. 在多数据中心下，通过gossip协议来协商服务器处理的目标地址，对不同请求切换其URL前缀。用于客户端驱动的容错以及分布。这个特性取消了中央热点，使得系统处理上限完全并彻底的消失。无论是百亿、千亿乃至万亿的并发，只要多加数据中心就可以支持了。因为，不同用户被自动分发到不同数据中心。现阶段，wware的自动编译分配的分布单元，只能处理像网上订票这样的简单依赖，将其拆分为如不同数据中心处理不同车次的分布策略；对于复杂依赖，依然需要人工介入，人工制定分布策略。
三、通信协议支持
1.HTTP/HTTPS
2.SPDY
3.HTTP2
4.WEBSOCKET
5.SMTP
6.POP3
7.SIP
8.DNS
WWARE不仅仅是一个WEB服务器，它是一个综合的业务逻辑处理中心。协议一旦被接入，就可以由controller所处理，并以web页面作为主要人机界面。 WWARE支持websocket，并可以在多个数据中心之间自由寻址。这扩张了传统WEB应用的RR(Request-Response)模型，允许服务器任意时刻主动通知WEB客户端。使用WWARE的应用，页面上是不应该出现刷新按钮的——服务器可以在需要时自动刷新。
WWARE支持SPDY以及HTTP2，这将降低HTTP与HTTPS之间的性能差异。可以在不降低用户体验的情况下，大幅提升网站安全性，提升访问者的信任。让我们一起拥抱安全的HTTPS时代吧。
四、服务器说明
1. 全异步模型
在wware选择的支撑环境里，所有的服务器都支持全异步模型。这将大幅降低对系统资源的消耗，提升响应效率。如果按照WWARE推荐方法开发应用，那么整个系统将全部是异步模型。而且按照WWARE推荐方法书写代码时，不需要考虑异步——只需要以同步方式思考即可(严格来说，甚至不应该有执行等计算机相关概念，详情参考下文)。WWARE编译器会首先从函数语言编译得到指令语言，然后进一步尝试自动将代码从同步转化为异步，最终代码的异步模型类似javascript里的worker，opencl里的work-item，每个分组的代码是原子的（Atomic Block）——只需要在开始和结束同步一次代码，中间无需考虑同步，因此可以很方便的被异步调度与执行，这确保最终在目标平台运行的程序是完全异步的，从而带来了指数级的性能提升。当前版本没有把自动分组的代码调度到任务执行器上执行，只是重新调整了异步IO的顺序。人工在WIDE中绘制的逻辑图或手写的同步代码会先构建相应代码，然后经过编译器生成AST（抽象语法树），按照变量影响范围、涉及异步操作等信息，计算得出代码分组。目前，wware中代码分组的判定矩阵，使用变量影响范围、涉及IO的效率、变量前置引发的同步数、同步效率等信息构成的数据流图(Data Flow Graph)计算。其系数通过采集jsperf中的相关性能数据，由google tensorflow确定，并使用fann进行验证。由前面描述可知，目前异步的主要目标是针对IO，不针对重计算，并且数据来源限定了使用javascript(基于V8 engine做了优化以方便运行于nodejs环境)。如果需要重计算的应用场合或者使用其它语言，请自行书写异步代码。由于数据采集的局限性，在发布时配置环境变量WWNOTRANS或者简单断开网络链接可以禁止自动代码分组，如果发现禁止分组之后性能反而有提升，请将相关代码发送给spc@wware.org以帮助我们改进。。
之所以选择Nodejs作为控制器的运行环境，是因为控制器的主要职责是任务调度，这需要大量IO，相对于其它异步服务器框架(Tornado,Jetty,Coro,Yaws...)，Nodejs在异步IO领域的灵活性以及简洁性都拥有很大的优势(重计算领域可以选择Yaws,也是wware任务执行器的可选环境之一)，这会降低编译器的工作量。
2. NGINX服务器
我们的Web server。采用的是基于异步模型的Nginx。并且添加了如下定制模块：
(1)内存缓冲
(2)缓冲刷新
(3)面向浏览器的动态优化
(4)链接热迁移
3. Web controller
业务逻辑派遣层的执行环境，我们采用了Node.js，基于V8执行javascript代码。原始书写的代码(不是Javascript)无需考虑异步，无需考虑状态，在发布时，对代码执行编译，正确处理其异步模型以及资源消耗，stateful等等话题。虽然也可以直接写javascript代码，但是javascript本质上只是WWARE的运行环境(Nodejs)指令，相当于物理机里的CPU指令集；因此，直接书写javascript代码并不是推荐的编写方法，使用推荐的标准方法书写代码，并不需要了解javascript，只不过会产生javascript代码而已(详情参考下文)。因此，WWARE环境下，服务器业务逻辑代码会比传统开发更简单，并且创建智能应用更容易——其实，在wware开发环境下，大多数情况下，不需要书写哪怕一行传统意义上的代码，也不需要有传统的开发知识。
4. 集群维护协议
对于一个数据中心的集群内敏感数据（consensus data), 我们采用etcd来同步。对于多数据中心之间的敏感数据，由于etcd所支持的raft协议,要求低延迟的稳定网络环境，不适合做数据中心之间的敏感数据同步。因此，多数据中心之间的数据同步，我们采用了支持gossip协议的serf来维护。
5. 多数据中心的设计目标
对于多数据中心，我们的设计目标是分布系统，而不是冗余或者基于同步的性能。换言之，每个数据中心处理的数据是不同的——只有其中很少一个部分需要同步。整个调度中心位于客户端，由客户端根据用户需求驱动分布。这个模型可以非常好的解决并发访问上限的问题。无论多少并发，只要系统规模足够大，永远不会有延迟现象。
现在很多系统的规模受制于单数据中心。例如国内的铁路订票系统12306，拥有很好的单数据中心。但是单数据中心的硬件限制摆在那里，当海量并发发生时，这个单数据中心总有无法承受的极限。而WWARE将其分布起来，由没有上限的数据中心来处理，例如不同车次由不同数据中心处理，并在客户端根据所选车次计算得到对应数据中心地址。理论上，并发的限制会消失。
因此，WWARE的多数据中心并不能取代传统的异地备份或者CDN等跨数据中心方案，它的设计目标是将整个系统按照算法(Hasher)分布到不同数据中心，以解决海量用户并发问题。换言之，WWARE的多数据中心方案是基于分布式系统(Distribution System)的高容量(High Capacity)方案。而不是高性能(High Performance)方案，也不是高可用性(High Availability)方案，高性能与高可用的问题，WWARE在每个数据中心内部解决。
五、存储
目前各类存储各有优缺点，wware将其分为五类，分别加以利用。
1. 文件存储
用于存储文件类资源。文件存储只需要兼容posix规范，可以挂载到本地文件系统即可。因此，CEPH,glusterfs,NFS等分布文件系统方案都可以被wware无缝支持。
2. 内存存储
数据获取的延迟(Latency)是影响系统性能的主要因素。对磁盘而言主要是寻道时间，HDD在10ms级，SDD在100us级，而DDR3-2666内存可以进入800ps级别。相差100,000-10,000,000倍。因此，集群内部各节点，使用内存存储来存储热点数据。当前，wware使用的内存存储为REDIS集群，并做了适当修正，用于支持热点迁移。所谓热点迁移，是因为网络也是有延时的，如果配置没有问题，电口网络的延时，通常在50微秒级别，而光口网络的延时，短距与电口基本一致，随距离加大，光口优势逐步增加，但是与内存的速度差距依然在万倍以上。因此，WWARE支持了热点迁移，也就是一个数据被频繁使用时(热点)，直接缓冲在本地内存，更新方会以graft protection的方式主动通知刷新缓冲。正是因为这些细节的优化，应用在WWARE集群环境中执行，会比不注意IO性能的单机应用还要快很多倍——对比很多APP，我们实现的相同功能的页面，从网络加载的速度会超越APP从本地打开的速度。(APP与网页的区别，1%是为了打破浏览器沙盒，99%是为了减少网络加载，从而提升性能)。
3. 全文检索
Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。
Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。
处理多租户（multitenancy）不需要特殊配置，而Solr则需要更多的高级设置。
Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。
各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。
4. 事务数据库
由于全文检索缺乏事务(Transaction)支持，因此，wware引入了事物数据库来支持这一特性。目前wware采用的是Postgresql。我们选择Postgresql的原因如下：
（1）PostgreSQL以BSD协议发布，对商业友好。并且PostgreSQL的社区非常庞大，使其经历了大量的测试，确保了性能与稳定。
（2）与PostgreSQl配合的软件很多，有很多分布式集群软件，如pgpool、pgcluster、slony、plploxy等等，很容易做读写分离、负载均衡、数据水平拆分等方案。并且都以对商业友好的协议发布。
（3）PostgreSQL源代码结构清晰，易读性好，这增加了其维护性，也意味着其改进空间更大。国产数据库基本都是在PostgreSQL基础上封装而来，就是例证之一。
您也可以使用Mysql,Oracle,Sql Server等其它数据库。但是此时您需要自己注意全索引状态，wware没有测试创建的代码，在其它数据库下是否是全索引状态。
wware的全索引支持，是为了保障检索速度与规模无关。换言之，一条数据与百亿条数据的检索速度几乎是一致的。实际上，无论传统数据库还是全文检索，如果确保检索条件最终都能正确利用索引(bitmap,btree,hash,rtree,lsm...)。那么，其检索效率遵循Hash的检索效率，为固定常数O(1)——最糟糕的情况会是o(n)，再加上bulk支持，更可以消除数据增加引发的额外计算时间增加，消除糟糕情况出现的概率。传统上，检索与数据规模有关，通常原因是设计的检索语句并没有配置为全索引状态。如果利用wware自己的检索生成器，那么wware会同时修改索引配置，确保检索语句全部命中合适索引。
当然，实践中，也有很多聚合计算类的需求，聚合计算是严格的数据规模线性相关的。WWARE尝试生成合适的存储过程，将聚合类计算分发到所有的集群节点，以提升性能。但是，聚合类需求依然是数据规模相关的，处理千万、亿级的数据就很吃力了——除非使用大规模集群来缓解。因此，产品设计中，如果有可能，应该规避聚合类需求。如果聚合需求不可避免，并且规模庞大，需要构建合适的诸如MapReduce之类的机制来解决，典型的可以使用Hadoop,Apache spark，这些都可以很方便的被wware所集成。相对于使用spark之类的大数据处理框架，除非为了复用已有资源，推荐使用WWARE自身的大数据处理框架。WWARE自身的任务迁移(当前尚未支持热迁移)，允许您的一段代码可以无缝的分发到任意多的任务执行器来执行，并可以在控制器(Web Controller)保持进度跟踪，从而反馈到用户端。这带来几个好处：
(1)数据处理代码与控制器代码保持相同的环境，因此，您可以利用WWARE提供的图形界面以同步方式完成全部业务逻辑，并视需求将其部署到N个任务处理节点上。整个过程只需要以同步思维方式完成一份代码。需要澄清的是，WWARE不是一种新的语言(概念上，可以看作一种图形语言)，而是一个all in one工具，通过图形界面可以产生合适的代码，并最终通过优化将其协同起来。
(2)不同于spark中采用的scala语言，WWARE以图形界面的方式让您编辑方程式，并利用octave solver解析出指定返回变量的方程式，进而生成相应代码(现阶段以package形式插入到octave中，需要手动维护)。利用WWARE桥接器和采集器来映射变量名称(octave不支持中文)以协同octave产生的代码。WWARE的数学公式编辑界面基于mathjax构建(没有采用更佳性能的KaTex，是因为其仅仅支持*Tex，并且公式中不支持中文)。相对于采用scala的spark，WWARE的首要目标是便捷性，其假想用户为领域专家。因此整个框架以编译的方式隐藏了大数据存取、网络协同、任务分发、WEB处理、数学公式编译(利用octave)、神经元训练(基于fann)、分类训练(基于libsvm)、逻辑推导(基于swi-prolog)等与计算机相关的知识。十分适合领域专家使用，可以快速开发出基于WEB界面的数学密集型智能应用，但是，这个框架势必会牺牲部分灵活性。
(3)WWARE为了弥补因易用性提升而丧失的部分灵活性，通过产生中间层代码来解决。这些自动生成的中间代码是人可读的Javascript，并以Promise-A兼容的when作执行流控制，允许计算机领域专家十分方便的增删改代码而无需调整整体结构。
如果一定有理由使用第三方方案，可以将其集成在任务处理器端，并需要做好数据桥接工作。
5. 外部存储
有很多外部的网盘，云盘，乃至出于异地备份而自己构建的外部存储，可以被wware利用。wware暴露了一组API，需要自行实现这组API来支持外部存储。现在，wware尚未支持任何的外部存储。
六、任务执行器
web controller作为一个热点——调度中心也意味着指挥中心。应该集中全部精力去执行调度的职责。因此，需要消耗系统资源的事情，例如邮件发送，短息通知等，被wware以任务的形式调度到专用的任务执行器上去执行，从而降低调度中心的工作量。从代码角度来看，执行器拥有与调度器相同的执行环境。wware目前不支持自动分拆及迁移任务，但是roadmap中已经有了这一特性。正是因为执行器的存在，controller可以获得更高的并发性。由于任务可以通过网关调度到其它环境下执行——极端的例子，可以通过internet，把高耗时的任务（例如渲染，科学计算，物理模拟等）放到民用环境下利用特殊计算机(例如专用的FPGA，需要水冷的显卡集群)执行，从而大幅提升整个系统的吞吐量。
任务分发，目前wware采用的是RabbitMQ集群。如果使用其它Message Broker，需要实现wware的相应接口。
我们采用RabbitMQ来做job的调度服务器。用于集群间任务的调度。
七、集群部署与维护
目前wware的集群部署采用ansible方案。没有使用puppet,chef。
八、WWARE推荐的开发方法
虽然您可以使用任意您熟悉的语言，采用任意习惯的编码方法学来落实代码，如果以WWARE推荐的方式来做，会发现WWARE的工具更顺手，换言之，WWARE会帮您做更多的事。
WWARE服务器端推荐的开发思路是函数编程（functional programming)，更具体而言，推荐采用逻辑编程(Logic Programming)。采用这种思路时，WWARE的工具支持更好。因此，如果您有过使用Java,C++,Javascript,Python,Perl等任意语言采用面向对象/过程/事件/指令等方法学进行开发的经验(语言本质与您采用的方法学无关，我们关心的是编码过程中指导思考方式的方法学，这里列出语言方便构建直观概念)，请意识到，WWARE里采用了不同的开发方法。如果您有使用clojure,coffescript,lisp,elixi,R,prolog,mathlab,octave等任意语言以自适应函数/数据流等面向数学的方法学进行开发的经验，那您会更轻松的理解WWARE中的很多做法。如果您有过解应用题的经验(当然，肯定有，而且不少:=)，您可以把WWARE开发看作解应用题，我们所有服务器端工作的目标是获取一系列信息点，以符合当前操作的预期。这些信息点就是求解，而输入就是已知，求解过程也请按照函数编程方法来思考。至于性能，请相信WWARE会做的越来越好。因为大多数产品都是十分简单的逻辑应用题——表现特征是，代码是简单的数据存取(CRUD)，此时您也许看不出指令方法与WWARE推荐方法之间的区别，下文简单解释，为什么WWARE采用了逻辑编程作为主要的服务器端方法学。下文描述使用的函数特指我们数学中的函数，如果有面向指令编程的知识会有助于理解。
传统指令型方法及其派生方法，正如名字暗示的，您给出指令，计算机一条条执行，是对计算机最灵活但对支持个性需求不友好的一种处理方式——其实现的难易程度取决于您可以使用多少指令，换言之是掌握了多少基础库，而不是对业务问题的理解深度；是由汇编、C、C++一路迁移过来的以计算机思维为第一主体的常用方法，由于其积累了大量的资源(第三方库及相关方法学)，并且对人而言，理解基本的计算机概念比理解数学建模更容易，而且使用OO的多态、ED的路由等特性可以很好的将代码复用和需求复用衔接在一起，因此目前占据了统治地位。
函数编程正如其名称暗示的一致，认为程序就是一系列数学方程式，首要任务是用数学描述业务问题，然后将数学公式录入计算机，这种程序的动态模型就是就是前面得到的数学公式，这里数学公式的地位相当于面向对象中的时序图。函数编程的代码，需要由编译器生成计算机指令来得以执行(mathlab里导出为C语言也可以看作创建了计算机指令，WWARE以类似的方式支持函数编程，不过导出的是javascript代码)。现在，这些编译器还有不足，编译的结果往往不如人精心调制的性能优秀，并且从实际问题抽象出数学函数并不比理解完计算机思维写指令代码容易——前者类似物理研究而后者类似专业翻译。这也是为什么函数语言使用相对较少，主要在数学密集型应用里出现的原因之一。
说完函数语言的基本概念，继续来说说其优点。最大的优点就是更贴近计算本质(数学发展了太长时间了，虽然是废话，但是很重要)，因此抽象程度高，如果工具集合适，更容易创建复杂并且智能的应用。让我们站在函数的角度来解释下人工智能，来更直观的理解这个优点。
1. 一个系统，就是一个嵌套包含若干子函数的大函数。物理领域，基于总结出的规则(数学公式表示的定律)，通过获取容易测量的值来得到难以测量的值以解决很多实际问题(诸如各种温度计、速度表....)。为了理解这个描述，我们采用SWI-prolog官方教程中的例子like来看一下，情敌规则可以被定义为A,B同时喜欢(like)C，那么AB就是情敌。所以，整个系统只需要采集一层喜好关系，就可以回答更多深层问题（情敌，脚踩两只船....)，并且可以实时追加规则定义，以获得更符合应用场景的回答，同时可以查询求解过程(backtrack)，从而得到使用哪些规则来联立解题的过程——也就是得到面向指令方法中的算法过程。请注意，这只是一层，如果是100层，10,000层彼此关联的逻辑呢？反观指令语言，正如其含义，逻辑是由人预设的，换言之，您需要自行设计可能的解题过程并编码。如果采用函数编程，一个数学函数，被拆解为若干函数，给定已知和求解，计算机会搜索所有的内置规则，寻找到可以从已知求出未知的若干规则的联立。您可以把您知道的物理考试题使用IEEExplore里的程序求解下，就可以意识到这种自动寻找已知规则组合的能力会带来什么了。这其实就是专家系统(Expert System)。其重心在于规则拆解以及规则制定——严格来说，如果没有合适工具辅助，不考虑需求变动，这个工作的难度及工作量大于指令型方法。换言之，面向指令是写出一个可能的解题过程，而如果希望自动寻找解题过程，需要精心设计(最小)规则集并全部落实，这些规则集一定大于某一个具体问题的。WWARE中以代码段方式内建了规则集，并不断扩充，以方便快速开发(Rapid Development)。
2. 进一步的，聚焦上文任何一个规则(子函数)，以函数语言的方式来思考，依然是一个函数，除了人工指定其规则之外，还有一个获取办法是训练，这就是神经元网络的作用了。很多时候，我们不知道公式是什么，但是我有一大堆实验数据，并且输入输出确定，请计算机自动帮我找到中间的规则——也就是得到对应的判定矩阵集(代表了若干n元m次方程组)。诸如fann,tensorflow等开源库就可以用来做这个事情。这意味着规则可以很方便的自我进化，如果连接自身的输入输出以构成一个正反馈系统，那就是一个可以自我学习进化的专家系统了，可以解决更为广阔的问题，从而延伸整个系统的覆盖范围。例如ERP中，部分不好以指令方式量化的管理、分配职责可以被计算机实现了，如果拥有大数据，这个特性在大数据分析领域用武之地更大，类似功能在WWARE中都可以以一个十分简单的方式得以实现。
3. 当然，这还不能完整模拟人的智能，还有一个重要问题，就是在开放环境下确定哪些数据之间有关联，并且需要从极少的数据中判定出来。例如，牛顿发现，速度、时间以及力是有关系的，如果当时有计算机，到这一步，加上海量实验数据，计算机就可以通过计算从而首先发现牛顿第一定律了，那可能现在就只有XX计算机第一定律了。现阶段的计算机理论，是无法解决开放环境下哪些因素有关系的问题的——由于找不到问题的收敛条件，无论用枚举或统计模拟算法(例如MCTS)，问题的可计算性都趋于0。这是现在的未解之谜，WWARE当然也不能解决，也没有尝试解决，WWARE只不过是综合利用已知方法，利用前人的经验(第三方库及其相关理论)让开发更简单，更高效，结果更高质而已。
WWARE中支持了一系列包括代码段管理，代码段创建，代码段关系推演，页面标注等工具来简化逻辑编程，在服务器端，经过标注的隔离，已经是纯粹的基于信息点的逻辑关系问题了，并且这些逻辑关系所需的子函数已经被大量支持，并可以通过关系推演来辅助确定其组合，因此，即便是简单问题——也是最常见的产品形态，逻辑编程的劣势也会消失，甚至您会发现对于没有接触过编程的人来说，使用WWARE采用逻辑编程思路上手更容易。
性能征集令
如果您发现了有比我们更好的性能指标，我们有重奖（奖金价值10万起）。
但是需要满足以下条件：
(1)同等硬件环境以及依赖数据条件下比我们快。
(2)需要提供实现方案，以及关键部分的源代码。