1 资料

• JDK5.0垃圾收集优化之--Don't Pause(花钱的年华)  
• 编写对GC友好，又不泄漏的代码(花钱的年华)  
• JVM调优总结  
• JDK 6所有选项及默认值  

2 GC日志打印

  GC调优是个很实验很伽利略的活儿，GC日志是先决的数据参考和最终验证：

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps(GC发生的时间) -XX:+PrintGCApplicationStoppedTime(GC消耗了多少时间) -XX:+PrintGCApplicationConcurrentTime(GC之间运行了多少时间)

3 收集器选择

CMS收集器：暂停时间优先

   配置参数：-XX:+UseConcMarkSweepGC
   已默认无需配置的参数：-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(full gc时压缩年老代)

   初始效果：1g堆内存的新生代约60m，minor gc约5-20毫秒，full gc约130毫秒。

Parallel收集器：吞吐量优先

    配置参数： -XX:+UseParallelGC -XX:+UseParallelOldGC(Parallel收集年老代，从JDK6.0开始支持)

    已默认无需配置的参数： -XX:+UseAdaptiveSizePolicy(动态调整新生代大小)

    初始效果：1g堆内存的新生代约90-110m(动态调整)，minor gc约5-20毫秒，full gc有无UseParallelOldGC 参数分别为1.3/1.1秒，差别不大。

    另外-XX:MaxGCPauseMillis=100 设置minor gc的期望最大时间，JVM会以此来调整新生代的大小，但在此测试环境中对象死的太快，此参数作用不大。

4 调优实战

      Parallel收集高达1秒的暂停时间基本不可忍受，所以选择CMS收集器。

      在被压测的Mule 2.0应用里，每秒都有大约400M的海量短命对象产生：

1. 因为默认60M的新生代太小了，频繁发生minor gc，大约0.2秒就进行一次。
2. 因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0，存活的临时对象不经过Survivor区直接进入年老代，不久就占满年老代发生full gc。

     对这两个参数的调优，既要改善上面两种情况，又要避免新生代过大，复制次数过多造成minor gc的暂停时间过长。

1. 使用-Xmn调到1/3 总内存。观察后设置-Xmn500M，新生代实际约460m。(用-XX:NewRatio设置无效，只能用 -Xmn)。
2. 添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小，观察后设置-XX:MaxTenuringThreshold=5。

      优化后，大约1.1秒才发生一次minor gc，且速度依然保持在15-20ms之间。同时年老代的增长速度大大减缓，很久才发生一次full gc，

      参数定稿：

 -server -Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC   -XX:MaxTenuringThreshold=5  -XX:+ExplicitGCInvokesConcurrent

      最后服务处理速度从1180 tps 上升到1380 tps，调整两个参数提升17%的性能还是笔很划算的买卖。

     另外，JDK6 Update 7自带了一个VisualVM工具，内里就是之前也有用过的Netbean Profiler，类似JConsole一样使用，可以看到线程状态，内存中对象以及方法的CPU时间等调优重要参考依据。免费捆绑啊，Sun 这样搞法，其他做Profiler的公司要关门了。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

  与Mule 2.0抵死缠绵了两周，喜忧掺半。但只在2.0之后，Mule才算真正 站到了ESB的起跑线上。
 
  完整的笔记见我的Wiki: http://wiki.springside.org.cn/display/calvin/Mule , 这里主要列一下实际的升级感受。

• InfoQ中文站新闻  
• Mule2.0的What's new  
• Migrating Mule 1.x to 2.0  
• Pattern Based Development with Mule 2.0   《Open-Source ESBs in Action》作者文章

1. 很Spring，很SCA的配置文件

• 全Spring又全nameSpace化的配置文件，简洁而规范，在IDE中有良好的提示。
  尤其是transport相关的endpoint的改进明显，原来的URI<endpoint address= "pop3://bob:secret@localhost:62002"> 或如下的connector

            改为transport特定的namespace后，IDE中清晰显示了可选的配置项。

• SCA的Service/Component概念。
  Service/Component代替了原来注定要被遗忘的MuleDescriptor，其中Component定义业务逻辑的POJO，Service定义如何以服务的方式管理组件的配置。
  在POJO中调用远程服务的Nested Router也改为了很SCA的Binding。
  Component也有Component 与 PooledComponent的选项。完整的例子如下：

      上文按pooling-profile定义的pooled-component，在spring中定义mySpringPojo，并将一个远程的CXF Endpoint binding到POJO的CreditAgencyService变量中，可直接调用；

• 可视化拖拽的Eclipse 插件Mule IDE。
  虽然还非常原始，但总算有个盼头。

2. 架构的更改

1. Web Service支持增强
   随着CXF作者的加入，Web Service这事实上SOA里最重要的Transport得到了加强，WSDL终于可以通过annotation准确配置。
   虽然无奈，就冲这个理由就应该升级到2.0了。不是2.0太好，而是1.4太差了。 
2. REST支持增强
   Mule RESTPack  ，支持apache abdera(Atom Publish协议实现)，Jersey(JSR131 RESTful WebService实现)和Restlet 三种Transport。
3. 代码结构的合理化
   抽象出相对稳定的org.mule.api接口包，代替原来的org.mule.umo包。
   开发团队还检查调整了Mule中所有对象的定义，使其更加准确。
4. 各个模块的升级
   如核心MuleManager大对象拆成MuleContext and Registry，运行时Reistry支持动态加载Service，支持向OSGI进军；
   如以流的方式转换处理消息。
   如SEDA模型定义的细化，见后。
5. 工具增强
   Mule Galaxy   SOA治理工具(开源)， Mule Saturn  消息流监控工具，Mule HQ   底层监控工具。
   不过还没试用不知道实际效果如何。

3. 遗憾的地方：

1. 性能下降
   无论是代替XFire的CXF还是Mule 2.0，都拖得性能大大下降。
   用一个简单例子测试，Mule 1.4+XFire  : Mule 1.4 + CXF : Mule 2.0 + CXF 的每秒事务数对比是15000：10000：8000。
   
2. 仍然没有自带的集群  ，负载均衡，流量控制实现。
   不像BEA、ServiceMix都使用JMS的底层，Mule使用vm queue在单一JVM的节点间流动。
   我们团队主要用TerraCotta  在集群里同步状态数据，流量控制与负载均衡也是自己实现。
3. CXF transport 仍然使用Mule自己实现的Http Connector。
   CXF Standlone也是用Jetty的，看tomcat们努力的劲头，相信谁都能随便实现一个不错的Http Connector。
4. 从1.4升到2.0非常的花时间。
   估计团队重构的太兴奋了，从代码到配置文件再到XFire to CXF，一些代码级修改还没文档详述。
5. 文档从1.4版更新到2.0版的进度太慢，而且文档仍然简略。
6. 质量仍然需要在使用中检验。
   文档说2.0版本的比1.x版本增加了30%的单元测试用例，按理来说项目质量应该提高了。
   但还是被我发现了在很重要的AbstractEntryPointResolver类里，居然有内存泄漏，原因是用没有重载Object的equals()函数的StringBuffer作为HashMap的key，结果map永远都在增大。
   这说明了，开源项目的质量，最终是靠一个积极使用和反馈的用户群和一个活跃的开发团队，"用"出来的。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

      TerraCotta  通过将POJO对象在群集内下的共享，让POJO不再局限于SNA(Share Nothing Architect)的架构，比较透明的支持了集群模式，可谓POJO开发模型的最后一块拼图。

      其实它的原理很简单，本身是一个中央式的Cache服务器。在应用启动命令中添加Terracotta参数，Classloader就会根据配置文件在JVM级以AOP方式修改ByteCode，用户透明地将对象存储于中央服务器。

      为了性能，它以对象属性而不是整个对象为存储单位；为了可用性，它本身也支持主备集群。

• Sessions Configurator 。以Debug模式将tc-confg.xml运行在一个预配置的双机集群下，让你观察共享对象的数值变化，出现运行时错误时，提示配置文件缺漏错误的修正。
• Eclipse插件。通过对着任意的类、属性、函数点右键来设定tc-config.xml。

     说是用户透明，其实只是最美好的愿望，可能还是有些代码修改：

• 同步问题。原本单机运行的程序，改成集群运行，跑不掉的是先要将自己共享对象类的代码改为线程安全的，如使用线程安全的ConcurrentHashMap 、AtomicInteger属性，或在访问属性的代码中加入synchronized控制。然后在xml中配置Terracotta的autolock将锁其扩展到群集范围，设定以锁为边界的批量更新属性的事务。
  反向理解TC的CTO同志关于调优的讲话，锁没搞好的话对性能影响挺大。

• 本地资源属性。有些很local的属性如文件句柄是没办法共享的，这时候就需要配置为Transients 属性。这种属性在另一个JVM里就会被强制设为Null。怎么办呢？推荐的做法是另写一个初始化这些属性的init函数，在tc-config.xml中配置调用。更少侵入的做法是直接在tc-config.xml中写beanshell脚本，不过这脚本不好写。

     最后TC承担了实现POJO集群的功能，但TC Server本身就存在单点故障的危险，需要配成Cluster模式。在TC的Persistent HA Cluster模式中，所有数据会Persist到磁盘，Cluster中永远只有一个Active Node，其他节点就作为Passive Nodee。Active Node的失效切换与Client的重连都是透明的。 Passive 与Active Node使可以用同一块支持文件锁的磁盘空间，也可以让Active Node将所有变化通过网络同步到Passive Node上。一般采用后者。

       另外，已经可以买国内的支持服务了。唯一遗憾要到12月份的TC2.7版，才会支持Glassfish 2。 

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

    08已过了一季，马上就要三十的人了，总有些脱不开烟火气的惫懒。为了那些"将来"，今年要读的书:

一、架构模式
   模式，就仿佛一个代号。一个大的架构，总能分拆成一个个代号与符号来演绎。
   SOA、ESB、SCA，注定了还是这一两年内纠缠着业界和客户的名词，大型架构内应用间的集成交互、性能、伸缩性、可靠性、可管理性、可扩展性、安全性，永远都是设计人员的心头好。

• 《Pattern-Oriented Software Architecture, Volume 4 -- A Pattern Language forDistributed Computing》架构模式的超级集大成目录。愿出版社快点翻出中文版造福市民。
• 《企业集成模式：设计、构建及部署消息传递解决方案》，重读之，Mule、Apache Camel、Spring Intergration都是它最实际的解释者。
• 《Remoting Patterns- Foundations of Enterprise, Internet and Realtime Distributed Object Middleware》，旧书但有点声名不响，前半卷应该可读。

   下半年国外还会有些关于SOA与ESB的书要出来，如《SOA Design Patterns》，《Implementing SOA : Total Architecture in Practice》，《Open-Source ESBs in Action》，《Service-Oriented Architecture and Event-Driven Architecture: J2EE Integrated Solutions》，静待。
    而关于X性的书，下半年会有本《Patterns for Fault Tolerant Software》。

二、BI
    越是Web2.0，越需要BI，比如豆瓣起家的法宝。
    而且，离什么算法高数都好遥远了，忽然间看回一排排数字，心里很意动，感觉又成为了《世界尽头与冷酷仙境》里的计算士。

• 《Programming Collective Intelligence -- Building Smart Web 2.0 Applications》 Web2.0里的群体智慧。愿出版社的动作更快一点。
• 《数据挖掘--实用机器学习技术 2nd》 Weka作者的书。

    还有一本《Collective Intelligence in Action》国外下半年会出版，这次是for Java程序员的，有weka，有java data mining api。

三、Good Programmer

      越来越远离补充基础的年龄，赶紧多看点书了。

• 《代码大全2nd》，细读之，书是好书，尤其是对于刚毕业两三年的人。对于一把年纪的，看了总比不看好。
• 《编程珠玑2nd》，闲得没事时可以看看，补充一下某些我们这些惯写应用程序的人早已失去的能力。
• 《Beautiful Code》，也是闲得没事看的，继续盼望出版社赶快译快校。
• 《Code Craft --The Practice of Writing Excellent Code》标题不错。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

OverView

• Apache CXF 
• Web Services Using Apache CXF(JDJ) 
• Dan Diephouse XFire作者的Blog，现工作于MuleSource。
• 余昌 、Willem Jiang  两位IONA北京员工的Blog。 

架构笔记

CXF的架构看多了有点熟悉而无聊，核心模块更是经典得没法更经典了。

     一、核心处理模块：

• Bus -- CXF容器，基于Spring的Container与Configuration。
• ServiceModel -- 服务元数据，其中ServiceInfo类似WSDL，而其他部分描述了DataBinding，Interceptors等CXF属性。
• Message -- 在框架内流动的通用信息单元。
• Interceptor -- 在管道内处理信息的功能单元，由Interceptor Chain控制，分属不同的阶段(Phase)。

      二、扩展模块：

• FrontEnd -- 用户编程API(如jax-ws,simple,javascript)，被隔离于核心模块。
• Trainsport -- 抽象、可扩展的传输层(如servlet,jetty,jms,local)，Destinations与Conduits代表接收与发送者。
• Binding -- 抽象、可扩展的协议解释层(如soap,http,xml,object)，实现createMessage()初始信息，然后通过预设置的一系列专用Interceptor实现解释。
• Data Binding -- 抽象、可扩展的XML与Java Object映射层(如jaxb,aegis)，实现不同的Reader与Writer进行编解码。

      三、运作流程 

1. CXF可以独立运行(Jetty)，也可以整合到Web服务器(servlet,jca)
2. 使用FrontEnd(如JaxWsServiceFactoryBean)从WSDL或annotated java class反射创建ServiceModel
3. 在Transport(http，jms,local)上接收请求
4. 通过Binding(SOAP，REST，JMS和Corba)创建Message，并由一系列Binding预设定的Interceptor进行解释与WS-*协议处理
5. 确定目标的Java服务，并把Data Binding(JAXB,Aegis)解码参数
6. 最后调度Java方法，将返回结果重新编码并发送回去。

直接处理原始XML请求的Provider接口

JAX-WS的API有两个层次，除了常见DataBinding后调用最终Java方法外，还可以使用客户端的Dispatch与服务端Provider接口，绕过DataBinding处理，直接处理XML。

在Spring配置文件里，将implementor指向Provider，指定WSDL，然后编写下类实现invoke函数。

@WebServiceProvider(portName="stockQuoteReporterPort" serviceName="stockQuoteReporter")
@ServiceMode(value="Service.Mode.PAYLOAD")
public class  stockQuoteReporterProvider implements Provider<DOMSource>
public stockQuoteReporterProvider(){
  }

public DOMSource invoke(DOMSource request){
    DOMSource response = new DOMSource();
    ...
    return response;
  }
}

 又见范型，<DOMSource>指明了数据的类型，可选DOM/SAX/StreamSource。也可以是Service.Mode.MESSAGE下的完整SOAPMessage或JMS的DataSource。记得需要自行拼装返回的XML结果。

   JAX-WS新增的这个功能是为复杂Web服务编写贴身订造的。被绕过的DataBinding，可以自行调用JAXB2.0的api完成。至于WSDL，可以写死，也可以用wsdl4j动态扩展。

其他笔记

• CXF中的Message信息：
  ID--唯一属性。
  Content--内容。可通过  <T> T getContent(Class<T> format) 函数获取，内部实现为Map<Class<?>, Object> contents。
  Exchange属性特别的将In Message 、Out Message、Fault与Transport信息关联。
  InterceptorChain--要处理Message的Chain。
• Invoker ，CXF默认是直接调用POJO或Spring里的Bean，可以通过Invoker调用EJB等对象。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

1.Overview

• SEDA 
• Adaptive Overload Control for Busy Internet Servers 
• An Architecture for Highly Concurrent,Well-Conditioned Internet Services 

     SEDA(Staged Event-Driven Architecture)的核心思想是把一个请求处理过程分成几个Stag，不同资源消耗的Stag使用不同数量的线程来处理，Stag间使用事件驱动的异步通信模式。

     更进一步，在每个Stage中可以动态配置自己的线程数，在超载时降级运行(如输出纯文字页面)或拒绝服务。

     在每个Stage的通常有如下组件:

• Incoming Event Queue ，事件队列。
• Admission Controller  阀门，拒绝服务。
• Dynamically sized Thread Pool， 线程池。
• Event Handler ，实际处理业务的Compinent。
• Resource Controller ，控制Stage的参数。

2.Web2.0+SOA环境下的SEDA应用

    Web2.0对架构师提出了新的挑战 ，  JavaEE 的同步调用机制(除JMS)，有限的线程池与连接池(超出范围性能会下降)，固定的定义在JNDI的资源对Web2.0/SOA的需求并不吻合。对BEEP，SCTP这些协议，必须依靠JCA另行编写模块来实现长连接模型。

    Java EE 迎合 Web 2.0(IBM DW) 提出，从统计学上看在系统总线程数固定的情况下，使用SEDA能获得较高的Throughput，阶段间的资源差异越大就越明显。
    比如处理一个Web 2.0常用Mashup请求，有如下几步：

1. 接收用户请求(1单位时间)
2. 数据库查询(4单位时间)
3. 根据数据库查询结果，准备Web Service调用参数(1单位时间)
4. 发起Web Service调用((16单位时间))
5. 将结果渲染返回给用户(2单位时间)
      

     那么SEDA会使用一条线程处理1.接收用户请求、3.准备WebService、5.返回结果，两条线程处理2.数据库查询， 而5条线程处理耗时最多的4.WebService请求。
     结果表明，当远程调用所花时间不变，而本地操作得到优化时，系统通量也能获得明显提高。

3. Mule 中的SEDA 实例

• Using SEDA to Ensure Service Availability(InfoQ) 

      Mule是SEDA架构的遵循者。每个Component间，用inbound->outBound的Queue异步相连，每个Component可以设置自己的线程池大小，队列长度。

      因此SEDA中的Stag间事件驱动异步链接，Stag内Incoming Event Queue，Thread Pool，Event Handler都有了。

"RadioCarUMO" implementation="radioCar">

    "5" maxThreadsIdle="10" poolExhaustedAction="WAIT" threadWaitTimeout="-1" id="component" doThreading="true"/>
    "6"/>
    
        "RadioCarsQueue"/>
        "org.mulefair.routing.BennyTheGatekeeper"/>
    
    
        "org.mule.routing.outbound.OutboundPassThroughRouter">
             "FairAreaQueue"/>
        
    

   而例子中的InboundRouter BennyTheGatekeeper，则实现了administration controller的角色，本来poolExhaustedAction="WAIT"，而administration controller可以通过计数器，直接refuse需求，将请求转发到alarm queue。

   整个Stag中唯一缺失是动态改变资源参数的Resource Controller，threadpool也不是Dynamically sized Thread Pool，但这似乎不重要了。

    再一次觉得Mule充当Service Container比ESB时还要称职。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

Overview

• Shoal 
• Shoal Overview 
• Clustering with the Shoal Framework(java.net) 
• Shoal JXTA Overview Presentation 
• 作者Blog 

Shoal是Glassfish的群集子项目，和Geronimo拼命整合现有开源项目相反，Glassfish在拼命拆分可独立使用的子项目。

Shoal很好的抽象了集群的两个最重要功能--群集节点管理和共享状态数据，而且，这一切是作为一个类库来提供，可以嵌入到任意的Java应用中。

集群的目标无外伸缩性与高可靠性，实现无外Load Balancer与Failover，而Shoal对这两点实现提供了很好的支持。可关注此项目的发展与应用，也可以基于它来学习一下群集的实现。

集群管理SPI

毫无例外地基于JXTA/JGroups。

• 节点可以加入，退出集群。
• 节点可以收到其他节点加入，退出(由节点主动发布)，怀疑失效，确认失效(由心跳系统发出)的消息。
• 实现了FailureRecoveryAction的节点可以收到虚拟管理器发来的接手某个失效服务器的指示。
• 节点可以群发或一对一发送消息。

基于上面的功能，可以....

• 可以做负载均衡分发器(仍然要自己实现)，根据有效的群集节点来进行分发，节点还可以用sendMessage()接口发送自己的负载情况。
• 可以做FailOver，当系统不是SNA架构时，接手处理的节点会根据指示，完成某些初始化工作，比如从共享内存中获取前任的数据，以保证自己能接手工作。
• 如果共享数据只读或者多数为读，可以不用共享内存，而是各自在本地建立对象，然后通过群集管理SPI的sendMessage函数来通知更新。

状态数据共享SPI

使用专有的API进行读写，基于使用集群内机器循环备份算法。
对比其他分布式缓存方案，是分布式内存方案，共享数据不会基于某种规则失效(如总内存大小1G，先进先出)，也不会自动清空过时数据。

示例代码

完整示例代码 ，启动GMS的代码如下：

GMSFactory.startGMSModule(serverName,
                groupName, GroupManagementService.MemberType.CORE, null);

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

     音箱里放的是《暮良文王》、《相相生》，再看下面的笔记体，虽然实用，但还是数完盘来再数碟，言语无味的很。以后不是这里的地荒得太厉害，就尽量让这些笔记在wiki里安静的呆着吧。

1.资料

• 《Java Transaction Design Strategies》  InfoQ minibook，最好的电子文档，Java事务处于懵懂状态的必读。
• 《Expert One on one J2EE Development Without EJB 中文版》与Spring参考手册中文版  中的相关章节可以看到Spring guys的意见。

2.本地事务与分布式事务

• 本地事务
  完全依赖于DB、JMS自身，，如直接调用jdbc中的conn.commit();这里没应用服务器什么事，所以也不支持多数据源的全局事务。
• 分布式事务
  在JavaEE世界的事务在JTA、JTS规范和XA Sources之上实现。
  JTA是用户编程接口，JTS是服务器底层服务，两者一般由应用服务器自带实现，而JOTM 和JBoss Transaction是专门搞局抢生意的。
  XA Sources其实先于JavaEE而存在，JDBC driver必须有javax.sql.XADataSource接口的实现类，否则所谓二阶段提交就是个伪能力。
  JavaEE除了支持JDBC和JMS外，还引入了JCA模型。JCA可以说是目前唯一可移植的插入JavaEE事务的资源模型，因此像JDO这类框架/Server就是靠乖乖出自己的JCA连接器来参与JavaEE事务的。

3.编程式模型

    手工调用jdbc的connection事务方法和使用JTA接口都属于编程式开发，在EJB中叫BMT(Bean管理事务)。
    JTA最重要的接口就是UserTransaction和它的六个方法-begin，commit，rollback，getStatus，setRollbackonly，setTransactionTimeout。
    程序需要UserTransaction时可以从JNDI领取，不过JNDI名随应用服务器不同而不同。EJB3里可以直接用个@Resource注入。

4.宣告式模型

    前面都是铺垫，这个才是主打的事务模型，如EJB的CMT(容器管理事务)和Sprin。

    其中EJB2.0，Spring1.0在部署描述符和applicationContext.xml中定义，而EJB3.0和Spring2.0则采用annotation。

4.1 事务类型

     这里JavaEE与Spring的定义基本相同：

• Required：如果Context中有事务就加入，没有就自己创建一个。(最常用设置)
• Mandatory：永远加入一个事务。如果当前Context没有事务，抛出异常。(那些不打算自己负责rollback事务的方法，必须加入到别人的事务，由别人来控制rollback)
• RequiresNew：永远新建一个事务。(那些不管别人如何，自己必须提交事务的方法，比如审计信息是一定要写的)
• Supports：如果有事务就加入，如果没有就算了。永远不会创建新事务。(一般用于只读方法，不会主动创建事务，但如果当前有事务就加入，以读到事务中未提交的数据)
• NotSupported：永远不使用事务，如果当前有事务，挂起事务。(那些有可能抛异常但异常并不影响全局的方法)
• Never：不能在有当前事务的情况下调用本方法。（生人勿近?)

      可见，Required是默认的设置，Supports是只读方法的最佳选择。

4.2 事务隔离级别

• ReadUncommited：本事务可以看到另一事务未提交的数据。脏读。
• ReadCommited：本事务只可以看到另一事务已提交的数据。不可重复读。
• RepeatableRead：可重复读。在一个事务内，第一次读到的数据，在本事务没有提交前，无论另一个事务如何提交数据，本事务读到的数据都是不变的。
• Serializable：串行化，同时只有一个事务能读相同的数据。

    级别越低越安全效率也越低。隔离级别需要相关资源支持，如重复读在Oracle里会降级为ReadCommited。Spring里默认的Default级别完全看数据源的脸色行事。

4.3 关于Rollback

    EJB里，想rollback只能sessionContext.setRollbackOnly()，或者抛出EJBException。(EJB3还可以annotation设置某些自定义Exception可以触发rollback)

    在Spring里，同样只会rollback unchecked exception(RuntimeExcption及子类)，而checked exception(Exception及子类)是不会rollback的，除非你特别声明。

   @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW,rollbackFor = {MyException1.class,MyException2.class})

    因此所有在service层方法中用throws定义的Exception，都必须在事务定义中进行rollback设定。(请勿善忘)

    所有在service层方法中c被atch处理了的异常，又希望容器辅助rollback的话，必须重抛一个预定义的RuntimeException的子类。(请勿回望)

4.4 关于Spring

    Spring不希望编程式事务管理。
    Spring也不希望使用EJB CMT--CMT依赖于EJB而无法用于POJO，依赖于JTA全局事务对单数据源场景造成了浪费，而且rollback机制比较麻烦（必须为EJBException或手工setRollbackOnly())。
    因此Spring通过AOP实现了对POJO的整套宣告式事务体系；对jdbc,hibernate,jpa,jms等local数据源和JTA实现了统一的事务管理机制，而且支持本地资源与JTA在配置文件级的切换，而且改进了rollback机制。

   1）一个本地事务管理器：

"transactionManager"
  class="org.springframework.orm.jpa.JpaTransactionManager">
  "entityManagerFactory" ref="entityManagerFactory" />
 

   2）Spring就会把请求都转发到应用服务器的JTA对象上（注意此时数据源也需要改为用JNDI从应用服务器获取)。

"myTxManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>

   3）应用服务器专有的类型的JTA事务管理器：

"myTxManager" class="org.springframework.transaction.jta.WebLogicJtaTransactionManager"/>

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

1.Overview

      数据服务是专门化的Web服务，在Web服务占了很大的地盘。
      因此，有企业服务总线(ESB)，也会有数据总线，两者是SOA下的两大总线，概念与功能上基本能一一对应，都是提供集中、星型的访问服务。
      数据vs信息。数据一般指单体的表，而信息指有业务含义的多个数据表的组合。数据服务的主体一般是"信息"。

2.数据的基本服务接口

     通过元数据定义，在一个或多个数据源中，将一个或多个数据表组合为信息视图，暴露为服务，提供CRUD接口和更新通知机制。

     除了让数据总线直接访问数据库外，数据源还可能是业务系统的WebService/EJB等接口，这一点上极具SOA的意义，业务系统下的数据库极有可能在物理上或逻辑上不允许总线对其直接访问和更新。
    
     1.CRUDSI操作接口 ：

     对信息暴露标准的Create，Update，Delete，Retrive，Search与Information接口。
     除了最传统的WebService接口外，还可能有下面的传输协议与数据格式：

• REST，轻量级面向资源接口，数据服务似乎是REST最贴切的用武之地--层次式URL定位对象，CRUD操作的HTTP原语。
• JSON/POX(Plain Old XML)，尽量简化的数据传输。
• RSS/ATOM Feed，轻量级的信息发布订阅格式。
• IBM/BEA的SDO规范，虽然看上去很美，但由于数据传输的跨平台要求，没有MS的加入等于白搭。
• 虚拟JDBC Driver，支持ADO.net的WebService，尽量减少旧系统改造的成本。

     2.查询语言 ：

• 直接的SQL92语言。
• 针对XML结果集的XQuery。
• 自设计的面向对象的查询语言，JPA的JQL、Salesforce的SOQL、Facebook的FQL等，能更好的表达信息视图中的对象嵌套关系，如post.comments。
• Google Base的简单按属性匹配查询--Fillter模式。

     3.数据更新通知机制 ：

• SalesForce的带时间窗参数(beginTime,endTime)的服务端查询接口，如id[] getUpdated(objectType,beginTime,endTime)。
  优点-最为简单；缺点 -实时性低，要达到高实时性时资源损耗严重；
• 客户自行实现接收通知的Web Service，供服务端调用。
  缺点--客户需要实现Web Service Server，而服务端需要自行实现订阅，可靠性保障等消息中间件功能。
• 使用跨平台的消息中间件  ，客户通过MOM的客户端接收消息。而且封装屏蔽底层消息中间件的存在，只向用户提供有限的API。
  优点-效率高，且对客户端要求低。缺点 -免费又服众的跨平台中间件难觅。

     4.接口粒度 ：

       可以每个业务实体一个接口，下属SCURDI操作；也可以使用同一个操作接口，如使用REST定位实际对象类型。 

       REST的"层次式定位"比单纯的"数据类型"更适合复杂的数据环境。

       无论是最后是采用SOAP还是REST格式，采用RPC风格与强数据类型都会频繁增加或改动接口。

     5.权限规则引擎 ：

        在表级、列级权限控制的基础上，还需要灵活的规则引擎来实现可定义的行记录级的权限控制。

     6.业务级封装

        在规范数据接口之上，可以封装可重用的业务级接口。

3.数据的分散式部署

      在上面的基本服务提供了基本的分散数据源的集中统一访问点(但不支持整合)之后，还可以： 

• 分布式实时联合视图 

     数据联合模式   ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

• 将数据最终整合存放 

     数据整合模式  ，支持连接于数据总线上的数据服务进行纵向的整合。

     比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

     整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

4.其他更强悍的需求

• 全文索引：支持相关性排序、模糊搜索，或者多个关键字搜索的搜索。
• 数据分析：支持数据挖掘，仪表板报告等。
• ETL。

5. 轻量级的数据服务

• ATOM/APP,GData   ATOM/APP协议与Google,Microsoft的扩展实现。
• FaceBook的Data Store API Beta版  
• snaplogic   RESTful的python 数据整合框架，支持db,webservice的整合。

6. 其他实现项目

6.1 BEA Data Service Platform

• AquaLogic Data Services Platform   
• SOA中的数据，第1部分：将数据转换成信息(dev2dev)  
• 逻辑数据服务 - "SCRUDI"设计模式(dev2dev)  
• 使用数据服务进行数据集成(dev2dev)  

    支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

6.2 其他

• JBoss DNA   ( 深入JBoss MetaMatrix  ) ，类似BEA，JBoss收购后还没发布。

• LongJump Daas(Database-as-a-Service)  

7. 其他参考资料

• 信息服务模式，第1部分：数据联合模式  ，第 2 部分: 数据整合模式  ，第 3 部分：数据清理模式  (IBM DW) 
• 在SOA中整合企业数据(InfoQ)  

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

ESB是什么

• ESB综述1：定义ESB  、ESB综述2：ESB使用案例   (InfoQ)
• 探索企业服务总线 part1(IBM DW)  ，part2  
• Defining the ESB   (DDJ)
• 《Enterprise Service Bus》  ,O'Reilly 2004

    ESB就是一个服务的中介，形成服务使用者->ESB服务Proxy->服务提供者的生物链，中介的作用在不同应用中各有不同：

• 解耦中介 ：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。
                ESB平台实现协议转换 (WebService，Http，JMS...)，消息转换 (转换、充实、过滤)，消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。 
• 服务中介 ：ESB平台作为中介提供服务交互中的基础服务。
                ESB平台实现SLA (可靠性保证，负载均衡，流量控制，缓存，事务控制，加密传输)，服务管理监控 (异常处理，服务调用及消息数据记录，系统及服务的状态监控，ESB配置管理)，统一安全管理 (这个有点理想主义)。
• 服务编排 ：多个服务进行编排形成新的服务。
                ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或 代码级编排)。

       缺点就是天然的额外中转性能消耗，中央ESB的性能瓶颈和高可用性问题。

ESB实现

开源ESB实现

• Mule   ，很多时候更像一个Service Container，OpenSource界暂时第一。
• WSO2  ，Axis2 背后公司的作品。
• ServiceMix  ，关注于JBI的实现。
• JBoss ESB  ，  Sun OpenESB   没有关注。

开源轻量级ESB

• Apache Camel  ，一个嵌入式的Router类库。
• Spring Intergration   ，相当清爽轻量的Spring Style的Router。

商业ESB

• BEA AquaLogic  ，作为ESB概 念比Mule纯粹，同时使用JMS作为message flow的底层，在Weblogic上实现HA，群集和监控管理界面。但路由编排再次走了图形编程+XML Context(XQuery)的老路，相当鸡肋。
• IBM(Message Broker, Websphere ESB，DataPower),
  

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

    以前介绍过一个搭建私服的简朴但很笨的办法--将雷锋同志下载好的.m2/repository目录整个上传到任意的Web服务器中。其实世上多的是专业的maven私服搭建器，见TheServiceSide的文章--Setting Up a Maven  Repository。

    我用的是Artifactory，忽然间觉得，Java的服务应用啥时候终于变得这么好用了，什么都不用装，不用配，双击artifactory.bat，自己就会启动Jetty Web服务器，典型的拆箱即用。

    10分钟入门到开动

• 双击artifactory.bat，启动默认配置的Artifactory服务。
• http://localhost:8081/artifactory/，用admin/password登录进管理界面看看。
• 修改自己项目的pom.xml，增加私服定义
  
      <repositories>
          <repository>
              <id>artifactory</id>
              <name>your local artifactory</name>
              <url>http://localhost:8081/artifactory/repo</url>
          </repository>
      </repositories>
  
      <pluginRepositories>
          <pluginRepository>
              <id>artifactory</id>
              <name>your local artifactory</name>
              <url>http://localhost:8081/artifactory/plugins-releases</url>
              <snapshots>
                  <enabled>false</enabled>
              </snapshots>
          </pluginRepository>
      </pluginRepositories>
• 正常运行项目的maven命令，向artifactory索求jar。如果artifactory已经下载了就会直接返回给你，还没有的就会去那几个repo官方站下载。进入到artifactory的管理界面，不断刷新Browse the repository，会看到仓库不断丰富的情况。

另外，官网服务器上还没有的一些jar，也可以通过管理界面很方便的deploy到Artifactory中。

最后你团队里的artifactory服务器不能直接连外网，需要使用HTTP代理服务器的话，见http://www.jfrog.org/sites/artifactory/latest/configuration.html

建议那些愿意为开源作实事的站点，在带宽充裕的服务器上，用Artifactory搭一个jar仓库吧，SpringSide就可以直接连上去下载jar了:)

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Java EE 5.0 规范的笔墨在EJB3.0与Web Service上，随着万众期待的Struts2.0揭开面纱，Java在Web应用开发上便变得沉闷乏味起来。

Servlet 3.0

Infoq 中文站：Sun向JCP提交了Servlet3.0规范

Infoq 英文站：Sun Submits Servlet 3.0 Specification to JCP

Sun，IBM，BEA，Oracle，Apache，RedHat，Interface21加上Hani Suleiman和Jason Hunter作为初始的专家组，Jetty的Greg Wilkins作为支撑成员。

Grizzly, Tomcat and Jetty 会对Comet API Review. Struts Shale, DWR, Spring Web Flow, Wicket会对可插拔Web Framework进行Review，看起来挺民主的。

Comet

    又一个新词，服务端在事件发生时主动向客户端推送--比如股票价格，聊天室信息，比客户端定时轮询服务器，在模型上高得多。但这种HTTP的PUSH的方式实际上有着重重困难如长连接的资源消耗，否则也早大规模实现了。
    Cometed with Jetty ，Advanced IO and Tomcat 6.0  ，Glassfish的Grizzy子项目 ，三个项目在NIO的基础上分别用自己的方法作了支持，而Non-blocking input/output，Delay request handling/response close，Blocking - Non-blocking notification是Servlet 3.0的统一要求。

    Comet实现的新选择 (dlee)
    Real-World Comet-Based Applications(Javaone2007)

REST

     REST作为最轻量级的Service方案(轻的，谁都会写的Service方案--REST与JSON)，本来需要框架辅助的东西就不多。如果硬说有，就是URL Mapping，并分拆URL中的参数，以及结果集的转换。Cetia4就是作类似的东西，但在又冒出一堆的REST框架来之前，Servlet3.0先规范一下无疑是好的，真的被无数MVC框架吓怕了。

其他方向

• Ajax继续发展：Dojo，Yahoo，Spry，Scriptaculous，GWT。
• Mashup：Web2.0 与Portal的发展进入Mashup时代。Blueprints for Mashups: Practical Strategies, Tips, and Code for Designing and Building(Javaone2007)
• Feeds (RSS/Atom)继续发展：Yahoo pipes, Google Data，尤其是Atom,IETF的feed format 与publishing protocol, not only for blog。Project有ROME、ROME-Propono、Abdera。
• Scripting：在Server端用Script如Javascript编程。Sun的Phobos项目，Project Phobos: Server-Side Scripting for the Java Platform(Javaone2007)

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Overview

• Mule 
• Mule ESB笔记(花钱的年华) 
• Mule Training(MuleConf2007) 
• Exploring ESB Patterns with Mule(java.net) 
• Mule: A Case Study(TSS) 
• Evolutionary integration with ESBs(InfoQ)  

      Mule的运作能力非常强，商业的支持公司Mulesource.com，给大家贡献代码的MuleForge.org，2007年大会MuleConf2007，CXF的作者，SaleForces的CXO......

Features

• *企业服务总线的主要特性：*Pluggable的传输层，转换器，路由器三者是ESB的公共核心功能，同时Mule还是《Enterprise Intergration Patterns》与 SEDA (Staged Event-Driven Architecture)的遵循者。 
• *企业服务总线的其他特性：*事务、安全、异常管理 ，JMX管理架构。
• *Service Container：*Mule作为一个ESB，并不纯粹。UMO的角色很灵活，既可以是什么都不干的Bridge Componet成为真正的ESB，也可以是业务POJO，让Mule成为一个Service Container。 作为Container，有多通信协议，有SEDA，有JMX监控，也不错。
• *流程编排：*Mule and BPM, BPEL  ，  因为Mule的不纯粹的Bus，对于组合服务它并没有像BEA那样提供统一的流程编写语言，如果使用每个节点inBound-outBound-inBound的定义会看得很郁闷，与而jBPM结合未知。但它提供了使用UMO(POJO)在代码级进行服务编排的可能。
• *Cluster：*群集是它暂时还不支持的死穴，而BEA，ServiceMix都使用JMS的底层，用JMS群集来实现负载均衡，如果系统失效，JMS会回滚，将任务交给另一个消费者。而Mule使用vm queue来在每个节点间流动，也支持XA，也可以设置在shutdown时持久化到文件。Wiki中的计划 Cluster功能，有像BEA、ServiceMix那样跑JMS底层，有使用TerraCotta的实现计划。

架构

可以看出Mule的架构分三大块，传输层一块，POJO一块，还有一块运行时管理模块。

Transport Provider

Transport 是ESB最苦力的部分，Mule支持了WebService(Axis,XFire,CXF)/REST、Ejb/Rmi、Email、Jdbc、Tcp/Udp、Xmpp、VM、Ftp、File、Quartz，还有一些Transport如vfs、IBM MQ，藏在某个sandbox代码分支或者muleforge.org中。

名词：Provider由Message Receiver/Dispatcher，Connector，Adapter组成。
Message Receiver/Dispatcher负责具体收发，Connector负责与外系统的连接，Adapter负责转换协议特殊的数据格式，取得一些协议相关参数，比如http的Content-Length。Endpoint 定义了Transport+地址，如jms://topic:myTopic 

• Transport Guide 
• Writing Transports 

Filter、Router、Transformer

在mule里各种模式通常只是一个名词，要把《EIP》摆在手边，参考其描述与用例。

• Router
  动态的、宣告式的、基于内容的路由、基于规则的路由、BPEL、过滤、分解、聚合、重排
  http://mule.codehaus.org/display/MULE/Message+Routers 
• Filter
  http://mule.codehaus.org/display/MULE/Filters 
• Transformer 转换、包装、扩充、规范、压缩、加密、编码
  http://mule.codehaus.org/display/MULE/Transformers 

UMO Component

• Entrypoint Resolver，消息->UMO方法的解释与调度。
• 对象容器，基于Spring。
• UMO对象池，基于Apache Common  Pools。
• Interceptor ，默认有log和profile.  
• Writing UMO   

Misc

• Loan Broker示例讲解  Loan Broker是ESB最常用的示例，JavaZone2005上对Mule
• Mule 2 and Beyond 、Mule Roadmap Discussion 、Mule and Spring 、Mule and OSGi  Mule未来计划的会议PPT。
• Enterprise Service Bus HOWTO 

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

1.REST

1.1 缘起

    N年前，一说到跨平台的服务方案，大牛们就想到"Socket Server"，小兵们就一直退，退到会议室的墙角。
    几年前，一说到跨平台的服务方案，连客户都会想到"Web Service"。
    现在，是个人都可以，在几分钟里，使用REST风格把一个服务的客户端和服务端写出来。

1.2 初见 

    REST首先是一个词，然后代表了一种服务提供模式。嗯，圣贤说，任意服务协议，都可以拆成传输协议，服务模式，数据格式三维表达，那REST就是依赖http作为传输机制，request-reponse模式，数据是预先协商好的任意格式。

    结果，任何语言的客户端，随便用一个http库访问某个URL，将请求信息写成XML或JSON或纯字符串，放在POST实体中。服务端也任意的实现一个servlet甚至jsp/asp/php，接收客户端发过来的请求，返回XML/JSON/字符串的结果就完了。

   So Easy，心里是不是立刻就想到了实现的方式。Java里用Apache的HttpClient  发送一个POST请求。