<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
  <channel>
    <title>技术之窗</title>
    <description></description>
    <link>http://rootle.javaeye.com</link>
    <language>UTF-8</language>
    <copyright>Copyright 2003-2008, JavaEye.com</copyright>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <generator>JavaEye - 做最棒的软件开发交流社区</generator>
      <item>
        <title>Re: 大家看看一个十万人在线级别的架构是否合适？</title>
        <author>ss19811029</author>
        <description>
          <![CDATA[
          <br/>
          作者: <a href="http://rootle.javaeye.com">ss19811029</a>&nbsp;
          链接：<a href="http://rootle.javaeye.com/blog/111009" style="color:red;">http://rootle.javaeye.com/blog/111009</a>&nbsp;
          发表时间: 2007年08月11日
          <br/><br/>
          声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
          <br/><br/>
          推荐你一片文章，可能对你的架构设计思路有帮助    说说大型高并发高负载网站的系统架构 By Michael  转载请保留出处：俊麟 Michael&rsquo;s blog (http://www.toplee.com/blog/?p=71) Trackback Url : http://www.toplee.com/blog/wp-trackback.php?p=71  　　我在CERNET做过拨号接入平台的搭建，而后在Yahoo&amp;3721从事过搜索引擎前端开发，又在MOP处理过大型社区猫扑大杂烩的架构升级等工作，同时自己接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，可以和大家一起探讨一下。   　　一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。  　　大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。  　　上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。  1、HTML静态化 　　其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。  　　除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。目前很多博客也都实现了静态化，我使用的这个Blog程序WordPress还没有静态化，所以如果面对高负载访问，www.toplee.com一定不能承受 :)  　　同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。  　　在进行html静态化的时候可以使用一种折中的方法，就是前端使用动态实现，在一定的策略下进行定时静态化和定时判断调用，这个能实现很多灵活性的操作，我开发的台球网站故人居(www.8zone.cn)就是使用了这样的方法，我通过设定一些html静态化的时间间隔来对动态网站内容进行缓存，达到分担大部分的压力到静态页面上，可以应用于中小型网站的架构上。故人居网站的地址：http://www.8zone.cn，顺便提一下，有喜欢台球的朋友多多支持我这个免费网站:)  2、图片服务器分离 　　大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。  　　在应用服务器和图片服务器上，可以进行不同的配置优化，比如Apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。  　　我的台球网站故人居8zone.cn也使用了图片服务器架构上的分离，目前是仅仅是架构上分离，物理上没有分离，由于没有钱买更多的服务器:)，大家可以看到故人居上的图片连接都是类似img.9tmd.com或者img1.9tmd.com的URL。  　　另外，在处理静态页面或者图片、js等访问方面，可以考虑使用lighttpd代替Apache，它提供了更轻量级和更高效的处理能力。  3、数据库集群和库表散列 　　大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。  　　在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。  　　上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。  4、缓存 　　缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。  　　架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的mod_proxy缓存模块，也可以使用外加的Squid进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。  　　网站程序开发方面的缓存，Linux上提供的Memcached是常用的缓存方案，不少web编程语言都提供memcache访问接口，php、perl、c和java都有，可以在web开发中使用，可以实时或者Cron的把数据、对象等内容进行缓存，策略非常灵活。一些大型社区使用了这样的架构。  　　另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块和eAccelerator加速和Cache模块，还要知名的Apc、XCache（国人开发的，支持！）php缓存模块，Java就更多了，.net不是很熟悉，相信也肯定有。  5、镜像 　　镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和 EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。  6、负载均衡 　　负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。  　　负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。另外有关初级的负载均衡DNS轮循和较专业的CDN架构就不多说了。  6.1 硬件四层交换 　　第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。  　　在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。  6.2 软件四层交换 　　大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。  　　软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。  　　一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。  总结： 　　对于大型网站来说，前面提到的每个方法可能都会被同时使用到，Michael这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。  　　转载请保留出处：俊麟 Michael&rsquo;s blog (http://www.toplee.com/blog/?p=71) Trackback Url : http://www.toplee.com/blog/wp-trackback.php?p=71
          <br/><br/>
          <span style="color:red;">
            <a href="http://rootle.javaeye.com/blog/111009#comments" style="color:red;">已有 <strong>0</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
          </span>
          <br/><br/><br/>
          <span style="color:#E28822;">JavaEye推荐</span>
          <br/>
          <ul class='adverts'><li><a href='/adverts/42' target='_blank'><span style="color:red;font-weight:bold;">搜狐网站诚聘Java、PHP和C++工程师</span></a></li><li><a href='/adverts/41' target='_blank'><span style="color:red;font-weight:bold;">北京: 千橡集团暨校内网诚聘软件研发工程师</span></a></li></ul>
          <br/><br/><br/>
          ]]>
        </description>
        <pubDate>Sat, 11 Aug 2007 01:01:16 +0800</pubDate>
        <link>http://rootle.javaeye.com/blog/111009</link>
        <guid>http://rootle.javaeye.com/blog/111009</guid>
      </item>
      <item>
        <title>面向服务的方法在业务规则开发中的运用</title>
        <author>ss19811029</author>
        <description>
          <![CDATA[
          <br/>
          作者: <a href="http://rootle.javaeye.com">ss19811029</a>&nbsp;
          链接：<a href="http://rootle.javaeye.com/blog/110227" style="color:red;">http://rootle.javaeye.com/blog/110227</a>&nbsp;
          发表时间: 2007年08月08日
          <br/><br/>
          声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
          <br/><br/>
          <p><span class="topstoryhead">推荐一片文章看看，我看了下，觉的不错</span></p>
<p><span class="topstoryhead">转载自</span></p>
<p><span class="topstoryhead"><font face="Arial">http://www.oracle.com/technology/global/cn/pub/articles/bpel_cookbook/geminiuc.html</font></span></p>
<p>&nbsp;</p>
<p>许多组织正从面向对象的业务流程管理范例转移到面向服务的方法；实际上，服务正在成为应用程序开发的基本元素。同时，业务流程执行语言 (BPEL) 已经成为编排这些服务和管理业务流程的无缺陷执行的事实标准。这些趋势所产生的结果是，为更灵活、更经济高效地管理业务流程提供了一些良机。 </p>
<p>大多数业务流程（贷款审批就是一个典型示例）包含多个决策点。在这些决策点处，将对某个条件进行评估。业务流程根据这些标准或业务规则更改它们的行为。实际上，这些业务规则对业务流程起到了推动作用。这些规则通常嵌入到业务流程本身或自定义 Java 代码的内部，这将导致在将来的某个时候出现若干问题： </p>
<ul>
    <li class="bodycopy">业务规则比业务本身更改得更频繁，而更改和管理嵌入的业务规则是一个复杂问题，并超出了大多数分析员的能力范围。因此，随着业务规则的更改，程序员通常要消耗大量时间来执行该任务。 </li>
    <li class="bodycopy">大多数组织都缺少中央规则信息库。因此，策略中任何涉及到组织范围的更改都无法运用到所有业务流程中。 </li>
    <li class="bodycopy">业务流程无法重用规则。因此，IT 人员最终要为每个流程设计规则，这通常导致不一致性或冗余。 </li>
</ul>
避免这些问题的最佳方法是使用<em>规则引擎</em>将业务流程与业务规则分离。在该方法中，规则公开为服务，而 BPEL 流程在到达决策点时通过查询该引擎来利用这些服务。该方法更为灵活 - 可以通过图形方式操作规则，而不是在编程语言中或在流程内部对规则进行编码。业务用户可以使用工具自行编写规则，并且无需 IT 人员的协助即可进行部署后的规则更改。由于大多数更新和功能增强是由业务用户执行的，因此可以显著减少维护成本。
<p>规则引擎和 BPEL 是两种互补技术。Oracle BPEL 流程管理器提供了高级工具来显示、设计和管理 BPEL 流程，而第三方规则引擎使复杂的业务逻辑可以用类似英语的语法表示，并由非程序员领域专家对其进行编辑。 </p>
<p>在&ldquo;BPEL 指南&rdquo;的第一部分中，我将根据我所在团队的自身经验来提供分离流程和规则的最佳实践。并通过代码示例提供一种开发方法，更改将 BPEL 与规则引擎集成的管理策略。最后，我将介绍该体系结构如何在不同的层中正确划分逻辑。 </p>
<p>&nbsp;</p>
<span class="parahead1">分离规则与流程</span>
<p>&nbsp;</p>
将规则引擎集成到流程管理框架中要求事先进行一定量的投资。在尝试进行此集成之前，将规则与流程分开是很重要的。因此，系统体系结构方面的一个主要决策是如何实现业务策略、业务流程和支持业务逻辑。实际上，架构师必须交流或设计最佳实践，以便设计人员在设计系统功能时知道应在何处应用每个相关技术 - BPEL、业务规则、Java/Web 服务。
<p>&nbsp;</p>
如图 1 所示，业务逻辑被分布到三个不同的 IT 基础架构层中：业务流程、Web 服务和规则。我们将对它们进行依次介绍。
<p>&nbsp;</p>
<p>&nbsp;</p>
<div align="center"><img src="http://www.oracle.com/technology/pub/images/geminiuc_bpelcookbook_f1.gif" alt="" />
<p><span class="boldbodycopy">图 1</span> 体系结构：分离规则与流程</p>
</div>
<p>&nbsp;</p>
<strong>业务流程层。</strong>该层负责管理业务流程的总体执行。这些使用 BPEL 实现的业务流程可以是长期运行的业务流程、事务业务流程以及持久业务流程。流程逻辑支持分布到 Web 服务/EJB 调用中的高级事务（&ldquo;sagas&rdquo;）以及嵌套的子流程事务。BPEL 引擎支持对工作流进行审计和检测，因此比较适合于
<ul>
    <li class="bodycopy">将不易变化的工作流步骤与易变的业务规则分开 </li>
    <li class="bodycopy">实现行业流程 </li>
    <li class="bodycopy">实现需要补偿的流程 </li>
    <li class="bodycopy">支持流程的大型实例化 </li>
    <li class="bodycopy">设计需要审计的流程 </li>
    <li class="bodycopy">协调异构技术，如连接器、Web 服务和支持 Web 服务调用框架 (WSIF) 的逻辑 </li>
</ul>
<strong>Web 服务层。</strong>Web 服务层将现有的应用程序层功能公开为服务。这样，多个业务流程便可以重用这些服务，从而实现面向服务体系结构 (SOA) 的承诺。
<p>Web 服务实现功能逻辑和域逻辑。功能方法通常是无状态和中等粒度的。例如，Web 服务可能包含系统数据的实用程序方法、实体操作和查询方法。可以使用多种技术实现 Web 服务并隐藏实现平台之间的差别。因此，该层比较适合于： </p>
<ul>
    <li class="bodycopy">为特定实体/域领域实现中等粒度的方法 </li>
    <li class="bodycopy">集成原有的代码/第三方工具 </li>
    <li class="bodycopy">封装应用程序层中的逻辑、自定义代码和实现 </li>
</ul>
<strong>规则层。</strong>规则引擎通常是复杂逻辑（涉及实体之间的一些相互依赖性以及与顺序相关的逻辑计算）的发源地。从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。
<p>&nbsp;</p>
规则引擎可以对规则集进行并行和按顺序的评估。此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。与传统的 Java 过程代码相比，该模块设计提供了一个更简单、可维护性更高的解决方案。
<p>&nbsp;</p>
此外，正如我在前面指出的，规则具备声明特性，并使业务分析员能够进行高级 GUI 编辑。现代规则引擎的执行速度非常快，并提供了内置的审计记录。规则层的典型特性包括
<ul>
    <li class="bodycopy">包含耦合和复杂的逻辑 </li>
    <li class="bodycopy">支持使用并行执行进行高效的业务逻辑评估 </li>
    <li class="bodycopy">包含基于多个业务规则评估构建的复杂返回结构 </li>
    <li class="bodycopy">允许将域逻辑转换为简单规则 </li>
    <li class="bodycopy">实现高度易变的业务策略 </li>
</ul>
由于规则在 Web 服务层中公开为服务，因此可以在所有企业间应用程序中重用，从而简化了新应用程序和集成的开发。
<p>&nbsp;</p>
<span class="parahead1">开发和维护</span>
<p>&nbsp;</p>
<p><span class="bodycopy">为演示开发过程，我将使用称作 <tt>Eligibility Process</tt> 的业务流程示例。该流程用于评估家庭是否有资格加入特定的医疗保健项目。根据家庭的属性（收入、子女总数），它将该家庭指定给 Healthcare Program 1 或 Healthcare Program 2。</span>在分析阶段，根据易变性和复杂性将逻辑分为不同类别的存储桶。正如在前一部分中所介绍的，规则通常对复杂的返回结构（需要多个业务验证以及频繁更改或影响组织大部分的策略）进行建模。而部门或组织流程则在业务流程层中建模。 </p>
<p>&nbsp;</p>
典型的开发流程包含三个步骤：
<ol>
    <li class="bodycopy">在规则集中创建规则 </li>
    <li class="bodycopy">将规则集公开为 Web 服务 </li>
    <li class="bodycopy">从 BPEL 中调用规则集 Web 服务 </li>
</ol>
开发阶段需要专门的角色（如规则开发人员、流程开发人员、业务分析员和 Web 服务开发人员）才能完成这些任务（请参阅图 2）。
<p>&nbsp;</p>
<p>&nbsp;</p>
<div align="center"><img src="http://www.oracle.com/technology/pub/images/geminiuc_bpelcookbook_f2.gif" alt="" />
<p><span class="boldbodycopy">图 2</span> 开发和维护角色</p>
</div>
<p>&nbsp;</p>
<strong>1. 在规则集中创建规则。</strong> 在开发的最初阶段，规则开发人员在集成的图形开发环境（如 ILOG 的 JRules 业务规则管理系统）中创建初始规则。（有关 Oracle Fusion 中间件中业务规则功能的信息，请参阅<a href="http://www.oracle.com/technology/global/cn/pub/articles/bpel_cookbook/geminiuc.html#sidebar" class="bodylink">边条</a>。）
<p>&nbsp;</p>
<table class="bodycopy" cellspacing="0" border="1" bordercolor="#111111" align="right" width="40%" cellpadding="5" style="BORDER-COLLAPSE: collapse">
    <tbody>
        <tr>
            <td>
            <div align="center"><a name="sidebar"></a><span class="parahead1">Oracle Fusion 中间件规则引擎</span> </div>
            <p>&nbsp;</p>
            该示例演示了如何将 ILOG 的规则引擎与 Oracle BPEL 流程管理器集成在一起，但请注意，Oracle Fusion 中间件的未来版本将把一个新的本机业务规则引擎与 Oracle BPEL 流程管理器集成在一起。
            <p>&nbsp;</p>
            使用 Oracle BPEL Designer 中的 Decision Service 向导，用户可以将业务规则集成到 BPEL 项目中。该向导将能够浏览 Oracle Business Rules（Oracle 业务规则）以及第三方规则引擎的信息库。此外，用户能够将 BPEL 变量映射为规则信息库中的事实、插入新的事实并执行规则。然后，BPEL 引擎将针对规则引擎事实自动执行从基于 XML 的变量到基于 Java 的数据类型的任何格式转换。
            <p>&nbsp;</p>
            部署后，业务用户将能够访问与业务流程相关的规则并进行更改，而不必重新部署流程。该方法将显著简化 BPEL 流程与规则引擎的集成，并增强体系结构的灵活性。 </td>
        </tr>
    </tbody>
</table>
创建规则前，应设置规则信息库和对象模型。通过规则信息库可以在业务规则的生命周期内维护和管理业务规则。业务规则操作的问题域通过 ILOG JRules 以业务对象模型 (BOM) 的格式表示。BOM 通过表示模型的可执行版本的 Java 类或 XML 模式表示。XML 模式可以帮助确保数据的灵活性。详细地实现对象模型通常是开发人员的任务。
<p>&nbsp;</p>
开发人员创建对象模型和规则信息库后，您需要决定哪些规则可以由分析员维护，以及哪些规则要用低级语言 (IRL) 开发。创建开发人员级规则后，开发人员与分析员协作标识剩余规则并在规则模板（可以由多个非技术方重用）中捕获它们。该方法简化并加快了规则的生成，同时减少了可能出现的人为错误。
<p>&nbsp;</p>
<p>为启动基于模板的规则创建流程，分析员需连接到规则信息库。当分析员从信息库中打开规则程序包时，他们将能够访问该程序包的 BOM。ILOG 支持通过它的业务应用程序语言 (BAL) 定义高级规则。分析员可以在此时编辑现有规则，也可以创建新规则。可以在维护期间通过模板（用于限制可以对规则进行的修改）修改规则。 </p>
<p>&nbsp;</p>
规则编辑器有一个默认模板，使开发人员可以使用 <tt>IF&ndash;THEN</tt> 结构创建条件和操作。如图 3 所示，业务分析员创建了一个检查家庭子女总数的规则。如果该变量等于 2，则家庭有资格参加 Healthcare Program 1。规则在数据类型 <em>eligibilityResult</em> 中返回值 true。
<p>&nbsp;</p>
<p>&nbsp;</p>
<div align="center"><img src="http://www.oracle.com/technology/pub/images/geminiuc_bpelcookbook_f3.gif" alt="" />
<p><span class="boldbodycopy">图 3</span> 创建一个检查家庭子女总数的规则</p>
</div>
<p>&nbsp;</p>
开发一个新规则后，可以使用 ILOG Rule Builder 工具内部的示例数据对其进行测试。Rule Builder 中的该调试器支持断点，使用户可以检查有效的内存数据并显示规则执行顺序。完成规则编辑和测试后，分析员将规则程序包导入到规则集中并部署回信息库。
<p>以下代码示例显示了 <tt>Eligibility ruleset</tt> 的实现。 </p>
<pre>// Eligibility ruleset receives an account and calculates eligibility results for multiple programs

ruleset eligibility {
	in Account account;
	out List eligibilityResultsList = new ArrayList();
	
}

// calculate program 1 then program 2 eligibility
flowtask Program1_TaskFlow {
	body = { 
		Program1_Setup;
		Program1_Eligibility;
		Program2_Setup;
		Program2_Eligibility;
}
};

// Determine which rules are setup rules for program 1
ruletask Program1_Setup{
	body = select(?rule) {
		if(&quot;Program1_Setup&quot;.getTask(?rule) )
			return true;
		else
			return false;
	}
}

// Determine which rules are eligibility rules for program 1
ruletask Program1_Eligibility{
	body = select(?rule) {
		if(&quot;Program1_Eligibility&quot;.getTask(?rule) )
			return true;
		else
			return false;
	}
}

// Create an eligibility result (JAXB object) for program 1
rule Progam1.CreateEligibilityResult {
	property task = &quot; Program1_Setup&quot;;
	when {
		?account:Account();
		?person:Person();
				
	}
	then {
		bind ?result = new EligibilityResult ();
		?result.setPersonId(?person.getPersonId());
		?result.setProgramType(ProgramEnum.PROGRAM1);
		?result.setEligible(Boolean.FALSE);
modify ?person { getEligibilityResults().add(?result); };
	}
};


// simple rule make person eligible if over 6 years old and returns
// result back in finalResults map 
rule Program1.AgeQualification {
	property task = &quot; Program1_Eligibility&quot;;
	when {
		?person:Person(?age:getAge().intValue(););
		evaluate(?age &gt;= 6);
} 
modify ?result {setEligible(Boolean.TRUE); };
finalResults.add(?result);
	} 

};
</pre>
<strong>2. 将规则集公开为 Web 服务。</strong> JRules 等规则引擎提供了相应的工具来生成包装程序 Web 服务或会话 Bean，以包装新开发的规则集。Web 服务开发人员将创建一个包装程序，以将规则集公开为 Web 服务。
<p>&nbsp;</p>
<p>XML 是一个用于集成规则、EJB、BPEL 流程和 Web 服务的关键标准。BPEL 使用本机 XML 访问数据，而 Web 服务使用它来序列化数据（并将在 Doc/Literal 调用中原封不动地使用它）。XML 可以在规则中直接使用。通过编组，可以将 XML 直接转换为 JAXB 对象树。可以使用本机 Java 对象执行规则。 </p>
<p>&nbsp;</p>
Web 服务应在它们相应的 WSDL 定义中导入 XML 模式。从 XML 模式中生成的 DTO 对象（如 JAXB）还可以帮助确保数据顺利转换，而不会出现转换错误。
<p>&nbsp;</p>
<p>Eligibility Web 服务提供从 XML 到 JAXB 的转换，然后调用 <tt>Eligibility Rules Delegate Session Bean</tt>。要隐藏调用 JRules 自定义库的复杂性，可以创建一个会话 fa?ade。该方法使实现规则引擎&ldquo;不可知&rdquo;；可以将系统轻松地移植到一个新的规则引擎提供程序。<tt>Eligibility Delegate Session Bean</tt> 对 <tt>Eligibility fa?ade Session Bean</tt> 进行 RMI 调用。该会话 bean 使用 <tt>ruleSession.executeRules(&quot;RuleApp/eligibility&quot;)</tt> 调用 RuleApp 程序包中的 <tt>Eligibility ruleset</tt>。 </p>
<pre>import ilog.rules.bres.session.IlrRuleExecutionResult;
import ilog.rules.bres.session.IlrStatelessRuleSession;
import ilog.rules.bres.session.ejb.IlrManagedRuleSessionProvider;
import ilog.rules.bres.session.util.IlrRuleSessionHelper;
	.
	.
	.
public List assessEligibility(AccountRoot account) {
	
	List eligibilityList = null;
	// get stateless rulesession instance
	IlrStatelessRuleSession ruleSession = null;
	try {
		ruleSession = IlrManagedRuleSessionProvider.getProvider()
				.createStatelessRuleSession();
	} catch (ilog.rules.bres.session.IlrRuleSessionCreationException ce) {
		String msg = &quot;Failed to retrieve RuleSession Provider&quot;;
		throw new InfrastructureException(msg, ce);
	}

	// pass borrower and credit as &quot;in&quot; parameters of the stateless session.
	IlrRuleSessionHelper helper = new IlrRuleSessionHelper(false);
	helper.addParameter(&quot;account&quot;, account);

	try {
	// execute rules and handle results
IlrRuleExecutionResult res = ruleSession.executeRules(&quot;/RuleApp/ eligibility&quot;, null, 
helper.getJavaClassResolver(this), helper.getParameters());
		eligibilityList = (List)res.parametersOut.getHandle(&quot;finalResults&quot;).getValue();
	} catch(Throwable t) {
            
String msg = &quot;Failed to execute rule!&quot;;
		throw new InfrastructureException(msg, t);
	}
	return eligibilityList;

}</pre>
<strong>3. 从 BPEL 调用规则集 Web 服务。</strong> 开发所有自定义系统组件后，开发人员应将系统与 BPEL 引擎集成。原有系统和新的自定义组件由 BPEL 流程编排。可以在此时解决兼容性、数据类型转换和 Web 服务协议方面的问题。流程开发人员和/或系统集成商将在 Oracle BPEL Process Designer 内部实现编排流。
<p>&nbsp;</p>
<p>例如，BPEL 将使用以下代码调用基础 Eligibility Web 服务。 </p>
<pre>&lt;assign name=&quot;setAccount&quot;&gt;
&lt;copy&gt;
&lt;from variable=&quot;BPELInput&quot; part=&quot;payload&quot;
query=&quot;/tns:EligibilityProcessRequest/tns:Account&quot;&gt;
&lt;/from&gt;
&lt;to  part=&quot;parameters&quot; 
query=&quot;/nsxml0:assessEligibility/nsxml0:Account&quot;   
variable=&quot;webservice_account&quot;/&gt;
&lt;/copy&gt;
&lt;/assign&gt;

&lt;invoke name=&quot;CallEligibilityWebservice&quot; partnerLink=&quot;EligibilityWebservice&quot; 
portType=&quot;nsxml0:EligibilityService&quot; operation=&quot; assessEligibility &quot;   
inputVariable=&quot;webservice_account&quot; outputVariable=&quot;webservice_eligibilityResults&quot;/&gt;
</pre>
<strong>维护阶段。</strong> 对于维护阶段（项目中的最长阶段）而言，将业务规则移出 Java 代码并移入规则引擎中将增强维护的可管理性。正如我在前面所介绍的，业务管理者可以在运行时使用图形界面修改规则，业务规则和 BPEL 流程可以相互独立地进行更改。
<p>&nbsp;</p>
<span class="parahead1">使用 Oracle BPEL 流程管理器执行 JRule</span>
<p>&nbsp;</p>
显然，规则、Web 服务和 BPEL 流程的设计和开发涉及多种不同的技术。在本部分中，我将介绍这些技术如何在运行时协同工作以执行 <tt>Eligibility Process</tt>。尽管该示例专门基于 Oracle BPEL 流程管理器和 ILOG JRule，但它可应用于许多其他环境。
<p>&nbsp;</p>
<p>规则引擎调用将出现在三个层中（请参阅图 4）：BPEL 调用规则 Web 服务、规则 Web 服务调用规则引擎、规则引擎应用程序代码接收输入并返回结果。 </p>
<p>&nbsp;</p>
<div align="center"><img src="http://www.oracle.com/technology/pub/images/geminiuc_bpelcookbook_f4.gif" alt="" />
<p><span class="boldbodycopy">图 4</span> 规则引擎调用演示</p>
</div>
<p>&nbsp;</p>
在示例业务流程的上下文中，应用程序使用 XML 有效载荷调用 <tt>Eligibility process</tt>。该有效载荷包含有关帐户的信息（如家庭属性）。<tt>Eligibility process</tt> 反过来调用 <tt>Eligibility Web service</tt>。<tt>Eligibility Web service</tt> 提供从 XML 到 JAXB 的转换，然后调用 <tt>Eligibility Rules Delegate Session Bean</tt>。后者使用 RMI 与会话 session fa?ade 交互。Session fa?ade 激活规则引擎，后者随后计算 eligibility 结果并将这些结果返回给该流程。<tt>Eligibility Process</tt> 将评估返回的结果并将 Program 1 或 Program 2 指定给该帐户。在该示例中，我们提供了一个远程服务器来运行 eligibility 规则，也可以在本地托管该规则。（注意，最佳实践是不要将非流程服务与 BPEL 流程管理器放在同一位置，这样可以实现更好的可伸缩性。）
<p>&nbsp;</p>
该示例有效演示了如何将业务逻辑划分为规则、BPEL 和 Web 服务：
<ul>
    <li class="bodycopy"><tt>Eligibility BPEL Process</tt> 显式定义了必须根据接收的 <tt>Eligibility Results</tt> 数据执行的步骤。<tt>Eligibility BPEL Process</tt> 将基于 <tt>Eligibility Results</tt> 调用不同的分支。Program 1 和 2 分别执行不同的步骤，可以使用 BPEL Designer 轻松地修改这些步骤。 </li>
    <li class="bodycopy">Eligibility Web 服务为 BPEL 流程管理器执行中等粒度的任务，BPEL 流程管理器封装有关如何发送对应关系以及将任务排队的机制。Web 服务作用于诸如数据库键（如 Account OID）这样的常见数据模型（可用于提取详细数据以执行所需任务）中的摘要数据。 </li>
    <li class="bodycopy">Eligibility 规则既不修改原始数据，也不访问外部数据源。由于您拥有准确的规则数据输入/输出记录，因此规则引擎审计线索比较简单。 </li>
</ul>
图 5 演示了通过 Web 服务将规则集成到 J2EE 平台的细节。规则被部署到独立的 ear (EligiblityRules.ear) 中并在规则引擎管理控制台中注册。余下的支持逻辑部署在另一个 ear (EligibilityRuleService.ear) 中，后者包含 <tt>EligibilityRules</tt> 将需要的 <tt>Account</tt> JAXB 对象的类以及用于调用规则的会话 fa?ade。会话 fa?ade 隐藏了调用 JRules 自定义库的细节，同时还可以使系统移植到一个新的规则引擎提供程序。
<p>&nbsp;</p>
<p>&nbsp;</p>
<div align="center"><img src="http://www.oracle.com/technology/pub/images/geminiuc_bpelcookbook_f5.gif" alt="" />
<p><span class="boldbodycopy">图 5</span> 通过 Web 服务将规则集成到 J2EE 平台中</p>
</div>
<p>&nbsp;</p>
<span class="parahead1">结论</span>
<p>&nbsp;</p>
在这篇 BPEL&ldquo;指南&rdquo;中，我介绍了用于在三个不同层（业务流程层、Web 服务层和规则层）中分布业务逻辑的策略。可以使用这些辅助技术最大限度地降低数据和逻辑之间的相关性。但是，为了获得充分的好处，设计师必须执行严格的分析以分解系统组件，并使用相应的技术来设计它们。开发过程涉及多种技术和各种角色。在参与开发过程之前，必须标识相应的资源。最终的体系结构是一个灵活的平台，业务用户可在该平台上处理多数业务更改，而无需 IT 人员的参与。
          <br/><br/>
          <span style="color:red;">
            <a href="http://rootle.javaeye.com/blog/110227#comments" style="color:red;">已有 <strong>0</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
          </span>
          <br/><br/><br/>
          <span style="color:#E28822;">JavaEye推荐</span>
          <br/>
          <ul class='adverts'><li><a href='/adverts/41' target='_blank'><span style="color:red;font-weight:bold;">北京: 千橡集团暨校内网诚聘软件研发工程师</span></a></li><li><a href='/adverts/42' target='_blank'><span style="color:red;font-weight:bold;">搜狐网站诚聘Java、PHP和C++工程师</span></a></li></ul>
          <br/><br/><br/>
          ]]>
        </description>
        <pubDate>Wed, 08 Aug 2007 18:18:05 +0800</pubDate>
        <link>http://rootle.javaeye.com/blog/110227</link>
        <guid>http://rootle.javaeye.com/blog/110227</guid>
      </item>
      <item>
        <title>J2EE历史及未来</title>
        <author>ss19811029</author>
        <description>
          <![CDATA[
          <br/>
          作者: <a href="http://rootle.javaeye.com">ss19811029</a>&nbsp;
          链接：<a href="http://rootle.javaeye.com/blog/99191" style="color:red;">http://rootle.javaeye.com/blog/99191</a>&nbsp;
          发表时间: 2007年07月09日
          <br/><br/>
          声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！
          <br/><br/>
          这里我们先看看J2EE的发展史和现状。 <br />   <br />   目前流行的Struts等MVC技术实现了页面显示和业务逻辑层的分离，以及MVC框架的可重用性；EJB Session Bean实现了业务逻辑的远程分布式的透明调用，从而实现了业务组件和调用的者的分离，以及业务组件的可重用性；EJB Entity Bean 实现了业务逻辑层和数据持久层的分离，以及数据持久层的可重用性；Web Service技术实现了服务接口的传输和调用的标准化，服务接口和服务实现的分离，以及Web服务组件的可重用性。<br />    当前技术界最热门的就是SOA（Service Oriented Architecture），即以服务为导向的的软件开发思想，因为目前最有潜力的市场需求是各种跨平台服务的整合。SOA的核心是要实现服务和技术的完全分离，从而达到服务的可重用性。<br />    SOA和Web Service的共同点：<br />    1.都提供服务。<br />    2.服务接口都是基于开发的。<br />    3.服务接口和服务的具体实现都是分离的。<br />    其实，Web Service是构建SOA的核心组件。从技术的角度来讲两者的区别如下：<br />    Web Service 服务接口需要绑定具体实现服务的服务组件来实现服务，它对具体的服务实现完成了封装，实现了服务的透明化，客户端不需要知道服务是如何实现的，但Web Service组件本身是知道服务是如何实现的，另外客户端调用Web Service组件时需要知道Web Service的具体位置和传输协议，这些都会造成一定的不灵活性，它只是实现了一定程度上的抽象。<br />   SOA架构平台之和服务接口进行绑定，对服务接口实现了封装，实现了服务接口的透明化，服务位置的透明化，服务传输协议的透明化。SOA本身也不知道服务具体是如何实现的当客户端通过SOA调用服务时，不需要知道真正的服务提供者是谁，具体的服务位置在哪里和具体的传输协议是什么。SOA实现了最高程度上的抽象化，为实现具有最高灵活性的服务建立了构架基础。 <br />   SOA架构的要点：<br />   1.SOA架构所提供的服务之间是松散耦合的。<br />   2.SOA架构应该按更接近于实际业务本身的粗粒度的角度来对服务进行划分，发布服务接口方法。<br />   3.SOA架构中的所有服务的具体实现，位置和传输协议对调用者来说都是透明的。<br />   <br />   SOA将会是java技术界的领导者。
          <br/><br/>
          <span style="color:red;">
            <a href="http://rootle.javaeye.com/blog/99191#comments" style="color:red;">已有 <strong>0</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
          </span>
          <br/><br/><br/>
          <span style="color:#E28822;">JavaEye推荐</span>
          <br/>
          <ul class='adverts'><li><a href='/adverts/41' target='_blank'><span style="color:red;font-weight:bold;">北京: 千橡集团暨校内网诚聘软件研发工程师</span></a></li><li><a href='/adverts/42' target='_blank'><span style="color:red;font-weight:bold;">搜狐网站诚聘Java、PHP和C++工程师</span></a></li></ul>
          <br/><br/><br/>
          ]]>
        </description>
        <pubDate>Mon, 09 Jul 2007 00:08:49 +0800</pubDate>
        <link>http://rootle.javaeye.com/blog/99191</link>
        <guid>http://rootle.javaeye.com/blog/99191</guid>
      </item>
  </channel>
</rss>