目前的系统中，前端的变化越来越多样。光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方式调用。
最终实现轻量级的面向服务编程。
转自 http://www.chromium.org/developers/design-documents/oop-iframes
这是chromimu工程内部的一份计划文档，并未付诸实施。但是，我们可以根据它来学习一下google的思想。
这篇文章是对我们计划的一个总体描述，作为 Site Isolation project的一部分。
我们的目的包括在多进程内跟踪iframe；在进程间调用和跟踪脚本；支持frame内跨进程导航；发送输入事件到正确的进程。
我们期望将chromimu的tab-level的逻辑变成frame-level的，这样，每个frame就可以在不同的进程中存在。
背景当收到一次呼叫的时候，FS会在TU层创建两个线程，一个线程为状态机线程，另外一个为消息线程。状态机线程通过switch_core_session_thread_launch创建，顾名思义其作用是不断的检查channel的状态，并进行处理。以下为详细处理过程。
状态机的执行机制：
2个回调函数
分别为：
const switch_state_handler_table_t *driver_state_handler = NULL;
const switch_state_handler_table_t *application_state_handler = NULL;
下面为具体的代码分析：
FS里面有大量的结构体，其变量的类型为函数指针。然后定义此结构，直接使用全局函数名称进行初始化。达到回调的效果。
例：
结构体
struct switch_state_handler_table {
/*! executed when the state changes to init */
switch_state_handler_t on_init;
/*! executed when the state changes to routing */
switch_state_handler_t on_routing;
。。。。/这里只显示部分
};
全局结构变量
switch_state_handler_table_t sofia_event_handlers = {
/*.on_init */ sofia_on_init,
/*.on_routing */ sofia_on_routing,
。。。
};
通过sofia_event_handlers即可对所有的函数进行调用。
通过宏定义进行回调
#define STATE_MACRO(__STATE, __STATE_STR) do{....}while(...)
状态机的回调过程，下图：
概括为：
1、根据状态机的状态执行mod_sofia中对应的回调函数
2、根据状态机的状态执行application和core设置的对应的回调函数
3、如果状态没有发生改变根据状态机的状态执行对应的standard函数
l 状态机状态一览
typedef enum {
CS_NEW,
CS_INIT,
CS_ROUTING,
CS_SOFT_EXECUTE,
CS_EXECUTE,
CS_EXCHANGE_MEDIA,
CS_PARK,
CS_CONSUME_MEDIA,
CS_HIBERNATE,
CS_RESET,
CS_HANGUP,
CS_REPORTING,
CS_DESTROY,
CS_NONE
} switch_channel_state_t;
以上为呼叫过程中的所有状态机。其中标注蓝色的状态会根据当前状态执行状态机函数。
修改channel状态
当channel的状态发生改变，进行修改时，会进行唤醒动作，把之前进入sleep的session线程唤醒。然后从新执行状态机。
另外一个线程为消息线程，其功能为不断的从呼叫对应的消息队列里面取出消息，并进行处理，我在SESSION文档里面有过描述，会创建一个消息队列。
消息的处理会在消息队列里面进行描述。这里不再消息讲述。