目前的系统中，前端的变化越来越多样。光web前端而言，HTML+JS，JQuery，Ext以及其他的各种框架等。曾经Ext刚出来时，我们为其美观、整洁的样式所吸引，但当我们开始熟悉并使用Ext时，却发现其界面让人审美疲劳。前篇一律的界面，让人觉得没有创意。

    最终，我们又回到原来前端的开发模式，通过美工设计界面和样式。然后用JQuery控件，来实现设计的这种表单、列表等。Ajax模式和Post提交模式目前还是共存，考虑到安全性、性能等各种问题，还是不能某种前端技术就能主导整个系统的实现。

    手机App终端出现后，我们发现又有新的前端实现，来访问。我们设计使用HttpClient来提交和获取服务器数据，或者直接用HTML5来设计前端界面。

    单当我们希望HTML5等帮我们统一手机、浏览器等多种终端时，却发现HTML5的展现效果，并不令人满意。特别是现在低版本IE的问题等。

    相对而言，后台的服务程序开发，相对而言框架没有那么容易变化。SSH框架，基本可以满足大部分项目的要求。

    当面对前端的要求时，我们针对具体的界面要求，设计Form类，Bean类、Action以及Hibernate相关的配置文件和类。这种模式由于现在技术成熟，相应的技术人员也多，因此我们可能感觉相对简单。

    但是这种模式也存在问题，对于一个简单的页面应用，可能具有大量的class以及大量的xml配置文件。而且对于不同的前端，我们基本上会配置不同的Struts配置，并且创建新的类。虽然工作简单，代码也重复，但是庞大的文件数目，也使得维护非常困难。

    因此我们需要有个设想，能不能针对一种服务，不管是多种前端来访问，后来实现上只需要一个文件就可以搞定。一项服务对应一个文件，当服务内容变更时，只需要改动一个文件的内容，就可以满足多个终端的需要。

    基于这种设想，我们需要定义每个前端，都用标准的接口。这一块我们需要定义统一的url来接收服务，同时通过参数来区分返回的格式。返回格式包括Json、XML、HTML、JS等。

    定义了统一接口之后，我们如何实现一个文件来对应实现一个服务呢。这一块我们需要借助规则引擎的实现。

    规则引擎通过一个规则包文件，来定义传入的接口数据、需要处理的数据库对象、临时变量或者对象、业务处理逻辑以及返回的接口数据。

    通过一个文件这种设计方式，可以极大简化系统的整个架构。架构师可以将每个界面上需要与服务器端交互的功能，统一用单一的服务来加以设计。使得设计文档中的功能和最终实现的文件，一一对应。

    通过面向服务编程，彻底屏蔽了后台数据库的实现，对于前端界面而言，只需要按照交互的要求，来和服务接口打交道。之后后来的服务，是采用关系型数据库存储、还是采用云存储、还是采用NoSQL存储，就变得无关紧要。可以随时对数据库实现加以调整。

    但是面向服务编程，还有一个轻量级和重量级的问题。对于纯粹的前端而言，URL访问方式没有性能问题。但是如果是后台服务本身之间的相互调用，那就变成负担了。这种情况下，就需要通过后端相互调用的接口。使得接口本身会自动判断，如果是本地的话，就是native方式调用，如果是远程服务，就通过url方式调用。

    最终实现轻量级的面向服务编程。