摘要:在上次关于AF框架的事件模型的随笔中介绍了AF的事件分发机制，这个事件分发机制比较好的解决了如果通过Web Services来让客户端得到服务器端事件的问题，让Web Service和Remoting的事件处理模型看上去完全一致，为在AF上开发事件驱动的应用程序带来极大的便捷。 但是由于这个模型在Web Service模式下是采用的轮询机制，这种机制会产生这样的问题： 性能问题。每个客户端都频繁的轮询服务器，在工作站比较多的情况下会给服务器的负载带来巨大的压力。 响应延迟。在这种事件分发机制下。事件的响应时延取决于轮询的频率，轮询频率越高则延迟越小，而频率越低则延迟越大。 这两个问题互相矛盾：为了提高事件的响应速度，就必须提高轮询频率；而提高了轮询频率又会加大服务器的负载。所以造成了事件响应速度和服务器负载两者不可兼得的局面。 为了解决这个问题，AF改良了事件分发机制，将事件探测器移到服务器端，结构如下图所示： 从结构上来看，没有太大的变化，主要的改变是将事件探测器从客户端移动到了服务器端。客户端照样也轮询事件，但是如果没有事件，服务器的这个线程就进入睡眠状态，不让它返回。同时该线程每隔一定时间就醒来检查一下有没有事件发生。如果有事件就马上返回。 因为这种轮询不占用网络资源，所以可以将服务器的轮询间隔时间设置得很短（目前默认值是100ms）。同时因为服务器Hold了线程，所以客户端的事件轮询也可以设置得很短，甚至可以无延迟。 这样一来，由于是服务器内部的线程处理，并且获取事件的操作代价并不高，所以这个事件探测器大部分时间都会是在休眠状态，因此服务器并没有被消耗多少资源。同时由于轮询不需要远程传递结果，因此可以将轮询时间设置得非常短，因此也极大的提高了事件的响应速度（原来的事件的最长响应时间是1s，现在是100ms，提高了十倍）。 另外，为了防止客户端意外的中断和请求超时，可以设置一个最长轮询次数。假如超过了最长轮询次数，服务器线程也返回，假如客户端仍然是活跃的，它马上会发出一个新的获取事件请求。然后服务器又开始进入新的轮询。...[阅读全文]

摘要:在以前的随笔中，介绍了一些关于Agile Framework的功能部分的特点，不过都还是一些“点”的介绍，这次介绍一下Agile Framework的整体模块组成结构，让大家对Agile Framework有一个从点到面的了解。 Agile Framework目前主要包含两个部分：客户端部分和服务器部分。在服务器端，AF的采用了Castle作为核心的的IoC容器，由于采用了这种轻量级容器技术，使得AF可以很容易的支持“POJO”业务对象（这是Java里面的说法，不知道在.Net里面同样的意思应该怎么叫）。而在客户端，AF采用的是Composite UI Application Block，它是一个结构非常酷的SmartClient框架，而且本身也带有一个IoC容器。由于采用了CAB技术，使AF拥有了非常强大灵活的界面插件能力。 Caslte拥有一个非常强大的IoC核心以及MonoRails Web框架和ActiveRecord数据框架，但是缺少一个强大的SmartClient客户端。而CAB有很强大的客户端框架，却没有相应的服务器部分。在一个企业应用架构中，往往需要同时构建服务器端和客户端应用，假如单独的使用它们的话会非常麻烦。 AF对这两个容器框架都做了许多额外的扩展工作，把它们包装起来，使得这两个框架无缝的融合为一体。同时在这个基础之上做了许多对构件企业应用程序非常有帮助的服务集成和扩展。 这幅图表述了Agile Framework的基本模块结构和开发模式，Agile Framework提供了通明的分布式计算能力，客户端组件和服务器端组件实际上虽然处于不同的容器之中，但是对组件来说，Agile Framework提供了几乎完全相同的容器模型，客户端组件访问服务器端服务就好像访问本地容器中的服务一样。 开发人员在Agile Framework框架上编写应用程序，目前可以获得如下好处： 分布式容器。只需要编写客户端界面控件和服务器端的业务逻辑组件，并“插入”到框架之中就可以。由框架提供依赖注入能力。并且依赖关系可以是分布式的，比如你可以在客户端插件中声明一个服务器端组件的依赖请求。 分布式事件。无论是服务器端还是客户端组件，只要是放到Agile Framework中，所有的组件都获得了完整的通信能力，除了可以请求组件的服务外，还可以互相之间订阅事件。并且事件是完全解耦的，并不需要显式的挂接事件，只需要声明一下事件发送者和订阅者的标记，Agile Framework会自动的连接有对应关系的事件。同样，事件也是分布式的，你可以在客户端组件中订阅服务器端的事件。 透明的底层传输机制。目前在Agile Framework中同时支持两种数据传输方式：Web Service和Remoting。你可以根据实际使用环境的需要灵活的配置。你可以在Intranet中将传输方式配置成Remoting，提高性能。或者将传输方式配置成Web Service，以满足通过企业防火墙的需要。而这一切对组件来说都是透明的，完全不用关心底层具体的传输方式。甚至你可以配置成“自动检测”，框架首先尝试采用Remoting，如果不能用Remoting就自动切换成Web Service。 自动离线处理机制。不需要再去编写复杂的离线处理任务，Agile Framework已经提供了一套完善的离线处理机制，采用Agile Framework编写的应用程序可以非常轻易的拥有离线处理功能。让你的应用程序拥有非常好客户体验。 常用服务和类库。与Castle和CAB不一样，Agile Framework是一个企业应用开发框架，所以内置了许多帮助开发企业级应用程序的服务和类库，比如日志服务、事务服务、工作流服务、缓存服务、安全认证服务、异常管理服务等等。此外还提供了大量的非常有用的帮助类库（Helper），比如单位转换、动态排序、表达式计算、日期转换、加密压缩、文件操作等等在企业开发中会频频使用到的基础功能。 对Agile Framework的结构总体概览就介绍到这里，以后会详细的介绍Agile Framwork的一些内部技术细节以及框架所提供的各种服务和Helper类的功能介绍和使用方法。 Agile Framework是一个基于.Net 2.0技术的开源企业开发框架，目前Agilelabs Team正在加紧开发中，期望能尽早的放出第一个版本。希望了解更多信息请访问敏捷实验室。...[阅读全文]

摘要:上一回简单介绍了一下Agile Framework的事件自动连接功能，这次来详细介绍一下事件功能的实现原理。 在Agile Framework中，只要为组件分别标记上EventPublisher和EventSubscriber就可以自动实现互相之间的连接，实现了事件的完全解耦。这个功能和Castle容器的EventWiringFacility的功能很像（在Composite UI Application Block中也有同样的事件机制）。但是和它们不同的是，Castle和CAB都只支持同一个容器内的事件互相连接。而Agile Framework的容器是分布式的，客户端组件和服务器组件都可以被加入到容器中，因此，Agile Framework的事件传递机制也是分布式的。简单的说，在服务器的业务组件中定义的事件也可以被客户端的组件接收到。 为了实现这个功能首先需要解决一个难题：因为Agile Framework可以同时支持Web Service和Remoting数据传输接口（只需要在配置文件中简单的修改一下配置，框架采用什么类型的传输接口对开发人员来说是完全透明的），所以就必须让事件传递机制同时支持这两种接口。用Remoting还比较好解决，因为Remoting本身就支持远程的事件机制。但是Web Service就麻烦了，它只支持简单请求/响应的无状态访问模型，无法主动让服务器发消息给客户端。 Agile Framework采用的Event Dispatch机制比较完美的解决了这个问题，以下是框架的事件模型图： 在整个结构中，Event Dispather是所有事件的中转站，它订阅了系统中所有的事件，并且知道每一个事件接受者。 事件的传递机制简单描述如下： 当Event Dispatcher接收到一个被触发的事件后，他会检查事件订阅列表，逐一将事件分发到每个接收者，根据事件接收者所处的位置不同，这时会有如下几种不同的情况： 假如事件接受者就在容器内部，Event Dispatcher会直接将事件发送到该接收者。 假如事件接收者是在客户端（Smart Client）并且接口是Remoting，Event Dispatcher会调用Remoting的远程接口将事件发送到客户端。 假如事件接收者是在客户端（Smart Client）并且接口是Web Service，Event Dispatcher会将事件发送给一个叫Event Holder的对象，这个对象负责接收所有发送给客户端的事件，并且保存下来。在客户端框架会有一个叫Event Detector的对象定时通过Web Service进行轮询来检查EventHolder中的事件。假如有事件是被发送到该客户端的，就会接受该事件数据并转发给客户端的事件接收方法。 如果事件接收者是Web页面，在Agile Framework中也有一个功能类似Event Detector的Ajax对象也会对Event Holder进行轮询。因此在Agile Framework中业务组件所定义的事件也能被Web页面对象接收到。 以上就是Agile Framework事件分发机制的基本原理。Agile Framework是一个开源的基于.Net 2.0技术的中间件平台，目前正在开发中，更多信息请访问敏捷实验室。 ...[阅读全文]

摘要:采用Agile Framework框架开发企业应用程序会编写大量的业务组件，这些组件都是被作为插件插入到框架中，结构上是完全解耦的。虽然按照SOA的设计理念在每个子系统之间不应该存在直接通信，但是有时候也可能需要在组件之间通信，比如和基础子系统或工作流组件通信。 因为，为了能保持最大程度的保持组件之间解耦状态，Agile Framework提供了组件之间的事件自动连接机制（Castle也提供了一个EventWiringFacility，提供了同样的功能，但是有一个比较严重的Bug：假如在系统中存在相互之间都有发布和订阅关系的组件就会造成死循环）。 在Agile Framework中使用自动事件连接非常简单，只需要对发布的事件打上EventPublisher特性，然后在订阅方法上打上EventSubscriber标记，框架就会自动的把具有相同eventkey的事件连接起来： public class Publisher{    [EventPublisher("eventkey", "description")]    public event EventHandler<CommonEventArgs<String>> EventPublished;    public void RaiseEvent(string data)    {        if (EventPublished != null)            EventPublished(this, new CommonEventArgs<String>(data));    }}public class Substriber{    private string recievedArgs;    [EventSubscriber("eventkey")]    public void EventSubstribe(object sender, CommonEventArgs<String> args)    {        recievedArgs = args.Args;    }} 这样，当Publisher触发了EventPublished之后，Substriber就会接受到这个事件。关于Agile Framework更多信息请访问：敏捷实验室...[阅读全文]