169it科技资讯


当前位置:  编程技术>软件工程/软件设计
本页文章导读:
    ▪利用规则引擎打造轻量级的面向服务编程模式          目前的系统中,前端的变化越来越多样。光web前端而言,HTML+JS,JQuery,Ext以及其他的各种框架等。曾经Ext刚出来时,我们为其美观、整洁的样式所吸引,但当我们开始熟悉并.........
    ▪google blink的设计计划: Out-of-Progress iframes      转自 http://www.chromium.org/developers/design-documents/oop-iframes 这是chromimu工程内部的一份计划文档,并未付诸实施。但是,我们可以根据它来学习一下google的思想。 这篇文章是对我们计划的一个.........
    ▪FS SIP呼叫的消息线程和状态机线程      THREAD 当收到一次呼叫的时候,FS会在TU层创建两个线程,一个线程为状态机线程,另外一个为消息线程。状态机线程通过switch_core_session_thread_launch创建,顾名思义其作用是不断的检查channel的状.........

[1]利用规则引擎打造轻量级的面向服务编程模式
    来源: 互联网  发布时间: 2013-11-19

    目前的系统中,前端的变化越来越多样。光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方式调用。

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

作者:joeyshi 发表于2013-7-5 16:17:06 原文链接
阅读:48 评论:0 查看评论

    
[2]google blink的设计计划: Out-of-Progress iframes
    来源: 互联网  发布时间: 2013-11-19

转自 http://www.chromium.org/developers/design-documents/oop-iframes

这是chromimu工程内部的一份计划文档,并未付诸实施。但是,我们可以根据它来学习一下google的思想。


这篇文章是对我们计划的一个总体描述,作为 Site Isolation project的一部分。


我们的目的包括在多进程内跟踪iframe;在进程间调用和跟踪脚本;支持frame内跨进程导航;发送输入事件到正确的进程。


Frame概述

我们期望将chromimu的tab-level的逻辑变成frame-level的,这样,每个frame就可以在不同的进程中存在。

背景
一般情况下,那些有脚本相互调用的网页需要存活在同一个进程(如果他们在同一站点),或者需要有一种方法能够彼此传递消息(如果他们在不同的站点)。chromium管理这些关系,是通过将所有页面都放在同一个BrowseringInstance对象中,并把具有同一个BrowsingInstance对象的页按照站点分组放在SiteInstance对象中(在 Process Models中有描述)。
BrowsingInstance通常只包含一个tab,但是当网页使用window.open或者 targeted link时,它也可以包含多个tab. 需要注意到,BrowsingInstance并不知道一个窗口内table的数量,因为手动创建的tab在他们自己的BrowsingInstance中。

为支持像postMessage这种跨进程交互,chromium必须在其他进程的BrowsingInstance中保存一个"可换出的(swapped out)"版本的DOMWindow,作为一个代理。
例如下图


如果站点A的一个网页,可以在它自己的进程内部找到一个代表占地B的活动tab的可换出的DOMWindow。这个DOMWindow将会传递postMessage调用到站点B的对应的进程中的对应页面。

对于out-of-process iframes,chromium也需要跟踪这些可换出DOMWindow,就像对待tab那样。

浏览器进程
在浏览器进程,chromium必须为每个tab跟踪整个frame树。WebContenst将管理以额FrameTreeNode对象树,和当前页的frame树对应。每个FrameTreeNode将包含frame的信息(如,frame的名字),它将负责frame中的跨进程导航,并支持其他进程frame传递过来的消息。

渲染进程
在每个渲染进程,chromium必须跟踪BrowsingInstance中的每个frame的DONWindow,让javascript代码能够找到frame并发送消息给他们。我们需要最小化每个DOMWindow的开销。

我们计划将frame相关的逻辑,从content模块的RenderView和RenderViewHost类中分离,放入一个新的RenderFame和RenderFrameHost类中。这些新的类将分配他们自己的远程id好,以便IPC消息能够识别他们。我们将为每个活动的Frame提供一个RenderFrame类,而且,在其他进程的BrowsingInstance中,我们将提供一个对应的、廋的“可换出“的RenderFrame对象。下图展示了一个包含了两个tab的BrowsingInstance,每个tab包括两个子frame,这些可换出的代理对象,用虚线表示。



blink内部

在blink内部,我们希望能够明确区分出真实的活动frame和那些只是包含代理对象的可换出的Frame。
从概念上,活动Frame包含一个普通的DOMWindow和一个Document,而可换出的Frame包含一个RemoteDomWindow,并没有Document。
我们计划重构Frame,以便Document只通过DOWindow(从Frame中移除直接对 Document的依赖)来访问,这会影响到很大一部分代码。

使用这种方法,可以让我们通过"swappedout://"URL和IPC消息过滤来淘汰当前可换出的逻辑,因为RemoteDOMWindow将没有Document。

这意味着,blink中的代码不能假定Document能够在一个进程中全部遍历。它可能需要改变例如Editor和焦点跟踪这一类代码。

注意:我们正在调研如何减少这些可换出RenderFrame和DOMWindow对象的内存占用,它将比现在的chromium占用更多的内存。
今天,一个BrowsingInstance的内存需求是O(tabs * processes),而且,大部分BrowsingInstance值包含1到2个tab。新的模型将需要 O(frames*processes)。
这将会使用更多的内存。因为frame的属性将远大于tab的数量,并且,不同站点的frame将会增加更多的进程。
幸运的是,有很多机会可以减少内存的开销。

导航
chromium将在子frame间支持跨进程的导航。不同于现在,让渲染进程拦截所有的导航并觉得是否让浏览器进程处理,新的模型将在浏览器进程的网络栈中处理这些导航。
如果导航跨越了站点的边界,浏览器进程将会交换frame的渲染进程。浏览器进程之所以能够做到这一点,是因为它直到所有的frame树,并且在上层决定。
实现这一点,需要适配TransferNavigationResourceThrottle对象,并给IO线程以足够的信息,以便它能够判断是否需要交换。

tab的历史会话也将因子frame在不同进程渲染而变得复杂。当前,blink小心的跟踪渲染进程中每个HistoryItem中的frame树,而浏览器进程使用NavigationEntry仅仅跟踪每个后退/前进条目。我们将移除blink的HistoryController中的frame跟踪逻辑,并保持在浏览器进程中直接跟踪每个frame的导航。

我们将用更贴近HTML5标准的方法来表示tab的历史会话。相比为没额HistroyItem clone Frame树的做法,我将在浏览器进程中跟踪每个frame的历史会话,并为后退和前进导航使用分离的“joint session history"列表。列表中的每个条目都将使用一个树指向frame对应的历史会话。

渲染
为了能够在不同进程渲染iframe和它的父页,浏览器进程将在渲染进程间传递信息,帮助GPU进程以正确的顺序和位置来渲染图像。也写逻辑可能适配或者部分用在BrowserPlugin上。

这部分的设计见separate document

 
输入事件
正在调研...

作者:doon 发表于2013-7-5 18:02:35 原文链接
阅读:3 评论:0 查看评论
    
[3]FS SIP呼叫的消息线程和状态机线程
    来源: 互联网  发布时间: 2013-11-19
THREAD

当收到一次呼叫的时候,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文档里面有过描述,会创建一个消息队列。

消息的处理会在消息队列里面进行描述。这里不再消息讲述。

作者:zp752963831 发表于2013-7-5 17:09:36 原文链接
阅读:55 评论:0 查看评论

    
最新技术文章:
▪主-主数据库系统架构    ▪java.lang.UnsupportedClassVersionError: Bad version number i...    ▪eclipse项目出现红色叉叉解决方案
▪Play!framework 项目部署到Tomcat    ▪dedecms如何做中英文网站?    ▪Spring Batch Framework– introduction chapter(上)
▪第三章 AOP 基于@AspectJ的AOP    ▪基于插件的服务集成方式    ▪Online Coding开发模式 (通过在线配置实现一个表...
▪观察者模式(Observer)    ▪工厂模式 - 程序实现(java)    ▪几种web并行化编程实现
▪机器学习理论与实战(二)决策树    ▪Hibernate(四)——全面解析一对多关联映射    ▪我所理解的设计模式(C++实现)——解释器模...
▪利用规则引擎打造轻量级的面向服务编程模式...    ▪google blink的设计计划: Out-of-Progress iframes    ▪FS SIP呼叫的消息线程和状态机线程
▪XML FREESWITCH APPLICATION 实现    ▪Drupal 实战    ▪Blink: Chromium的新渲染引擎
▪(十四)桥接模式详解(都市异能版)    ▪你不知道的Eclipse用法:使用Allocation tracker跟...    ▪Linux内核-进程
▪你不知道的Eclipse用法:使用Metrics 测量复杂度    ▪IT行业为什么没有进度    ▪Exchange Server 2010/2013三种不同的故障转移
▪第二章 IoC Spring自动扫描和管理Bean    ▪CMMI简介    ▪目标检测(Object Detection)原理与实现(六)
▪值班总结(1)——探讨sql语句的执行机制    ▪第二章 IoC Annotation注入    ▪CentOS 6.4下安装Vagrant
▪Java NIO框架Netty1简单发送接受    ▪漫画研发之八:会吃的孩子有奶吃    ▪比较ASP和ASP.NET
▪SPRING中的CONTEXTLOADERLISTENER    ▪在Nginx下对网站进行密码保护    ▪Hibernate从入门到精通(五)一对一单向关联映...
▪.NET领域驱动设计—初尝(三:穿过迷雾走向光...    ▪linux下的块设备驱动(一)    ▪Modem项目工作总结
▪工作流--JBPM简介及开发环境搭建    ▪工作流--JBPM核心服务及表结构    ▪Eclipse:使用JDepend 进行依赖项检查
▪windows下用putty上传文件到远程Linux方法    ▪iBatis和Hibernate的5点区别    ▪基于学习的Indexing算法
▪设计模式11---设计模式之中介者模式(Mediator...    ▪带你走进EJB--JMS编程模型    ▪从抽象谈起(二):观察者模式与回调
▪设计模式09---设计模式之生成器模式(Builder)也...    ▪svn_resin_持续优化中    ▪Bitmap recycle方法与制作Bitmap的内存缓存
▪Hibernate从入门到精通(四)基本映射    ▪设计模式10---设计模式之原型模式(Prototype)    ▪Dreamer 3.0 支持json、xml、文件上传
▪Eclipse:使用PMD预先检测错误    ▪Jspx.net Framework 5.1 发布    ▪从抽象谈起(一):工厂模式与策略模式
▪Eclipse:使用CheckStyle实施编码标准    ▪【论文阅读】《Chain Replication for Supporting High T...    ▪Struts2 Path_路径问题
▪spring 配置文件详解    ▪Struts2第一个工程helloStruts极其基本配置    ▪Python学习入门基础教程(learning Python)--2 Python简...
▪maven springmvc环境配置    ▪基于SCRUM的金融软件开发项目    ▪software quality assurance 常见问题收录
▪Redis集群明细文档    ▪Dreamer 框架 比Struts2 更加灵活    ▪Maven POM入门
▪git 分支篇-----不断更新中    ▪Oracle非主键自增长    ▪php设计模式——UML类图
▪Matlab,Visio等生成的图片的字体嵌入问题解决...    ▪用Darwin和live555实现的直播框架    ▪学习ORM框架—hibernate(二):由hibernate接口谈...
▪(十)装饰器模式详解(与IO不解的情缘)    ▪无锁编程:最简单例子    ▪【虚拟化实战】网络设计之四Teaming
▪OSGi:生命周期层    ▪Javascript/Jquery——简单定时器    ▪java代码 发送GET、POST请求
▪Entity Framework底层操作封装(3)    ▪HttpClient 发送GET、POST请求    ▪使用spring框架,应用启动时,加载数据
▪Linux下Apache网站目录读写权限的设置    ▪单键模式的C++描述    ▪学习ORM框架—hibernate(一):初识hibernate
 


站内导航:


特别声明:169IT网站部分信息来自互联网,如果侵犯您的权利,请及时告知,本站将立即删除!

©2012-2017,169IT.COM,E-mail:www_169it_com#163.com(请将#改为@)

浙ICP备11055608号