WebLogic 9/10分布式协议栈

      WebLogic首先是一个分布式（Cluster）中间件，然后才是一个J2EE中间件。对于大部分人来说，他们可能过于注重在J2EE支持特性上，将WebLogic与其他比较中间件（JBoss以及Oracle AS相提并论），而忽略了在分布式协议栈与J2EE之间的权重关系。

      实际上，我们很难将分布式与J2EE分离，如果仅仅比较J2EE feature，可能我们无法拉开与其他中间件的差距，甚至，公众认为WebLogic已经在开源技术支持仍落后于JBoss。

      但从另一个角度，WebLogic为了支持一个新的J2EE，它考虑的不仅仅是J2EE规范，而是如何在当前我们的分布式协议栈上更好地支持此规范。

      举一个生动但没有证据的例子，比如JBoss为了支持JDBC 3.0，需要投入了200个工时去完成此特性；则对WebLogic来说，可能是1400个工时。为什么呢，因为WebLogic分布式协议栈比JBoss复杂很多，因此同时带来了实现某J2EE feature的复杂性。

      我们的协议栈是工业级，JBoss是面向中小企业级别，因此，理解WebLogic的强大之处，请关注分布式而非J2EE。

      在技术的层面，我更倾向于接受Ed Pozarycki所定义的协议栈，即: Socket->RJVM->RMI->Cluster

      以下是WebLogic核心在启动的时候，加载的四个对应于上述协议栈的服务。

      <!--[if !supportLists]-->l <!--[endif]-->weblogic.socket.SocketMuxerServerService

      <!--[if !supportLists]-->l <!--[endif]-->weblogic.rjvm.RJVMService

      <!--[if !supportLists]-->l <!--[endif]-->weblogic.rmi.internal.RMIServerService

      <!--[if !supportLists]-->l <!--[endif]-->weblogic.cluster.ClusterService

      SocketMuxerServerService是负责根据操作系统的类型以及支持NatvieIO决定创建何种类型的Muxer，WebLogic会选择以下的SocketMuxer的一种进行加载:

      <!--[if !supportLists]-->weblogic.socket.JavaSocketMuxer
      <!--[if !supportLists]-->weblogic.socket.NTSocketMuxer
      <!--[if !supportLists]-->weblogic.socket.PosixSocketMuxer
      <!--[if !supportLists]-->weblogic.socket.DevPollSocketMuxer
      <!--[if !supportLists]-->weblogic.socket.EPollSocketMuxer
      当一个SocketMuxer被加载之后，它会建立监听线程，然后定期地分派工作，比如一个新的Socket请求进来了，是SocketMuxer去决定由当前哪个Socket线程去为之服务。SocketMuxer最终把Socket读写任务交给了MuxableSocket（接口）去完成。

      RJVM架构于Socket层之上，引入RJVM主要原因是：WebLogic集群是以JVM为单位，而这些JVM本身需要与集群的其他JVM进行通讯，比如，每个WebLogic实例上的Servlet/EJB与其他WebLogic实例上的Servlet/EJB本身存在复杂的状态同步。正如Rod Johnson在《J2EE Without EJB》中提到的，“EJB分布式对象是EJB存在的唯一价值”，而这种价值正是依赖于RJVM技术。

      个人认为，RJVM是理解WebLogic分布式系统的最重要入口，RJVM层除了为WebLogic集群中的实例节点提供了统一的标识，还还为集群节点间通讯（T3协议）提供了类似TCP滑动窗口传输技术的特性，优化了JVM间的过度频繁的信息传输。

      RMI（Java Remote Method Invocation），一种高耦合度的远程调用协议，现在已经较少被用于应用系统间的远程访问（取而代之的是Web Services），但在中间件中，RMI依然是高效和实用的。RMI提供的Java对象序列化技术 (Serialization)以及组装和分解技术(Marshalling/Unmarshalling)，都是WebLogic Cluster所必需依赖的。



翻开早期的历史教科书，WebLogic曾经还是一个Cobra ORB（WLE吗?），因此，远程调用上，我们有RMI on IIOP的技术，后来，IIOP由于其复杂与低效等原因，逐渐远离我们，RMI on RJVM是现在我们WebLogic协议栈中最主要的方式。

Cluster，也就是分布式系统最上层面的概念，经常使用WebLogic构建集群，打开Cluster的Debug选项，会看到Cluster节点间的通讯细节，这些细节都能很好地帮助我们理解WebLogic作为一个分布式系统的工作原理。

Cluster不是J2EE规范，各个J2EE中间件提供商都有各自不同的集群实现方式，而WebLogic Cluster亦经过多年的改进，现在成为了至今最为成熟中间件技术之一。

我们可以这样理解，WebLogic的很多J2EE特性和标准都是围绕WebLogic Cluster特性设计，而Cluster本身并非J2EE规范（乃Vendor规范），因此，其他中间件厂商很难短期内复制WebLogic的J2EE特性。

因此，虽然各个J2EE厂家都声称自己支持大部分的J2EE、WS*、SOA标准规范，但是，始终在商业性和扩展性上落后于我们，归根结底，是因为我们有着多年在分布式系统的沉淀和积累，超过几百万个分布式应用场景（Case），数以万计的客户缺陷反馈帮助我们完善WLS协议栈设计（Patch）。

因此，WebLogic，首先是一个分布式中间件；而理解它，需要把握WebLogic协议栈的设计原理；而我认为，WebLogic的分布式协议栈未必是最优秀的，但它很可能是最为成熟和可靠的。

“无分布式，不J2EE”

下文，我们将按顺序从Socket->RJVM->RMI->Cluster去窥探一个分布式中间件协议栈的方方面面。 理解了协议栈，对理解WebLogic是如何去实现诸如EJB、Servlet、JDBC、JNDI、JMS等J2EE基本规范有很大的帮助。

我们的WebLogic的Servlet容器、EJB容器、SOAP容器等基本出自于Adam Messinger大师之手，据说，05年之后，Adam离开了BEA，而在2008年初，他加入到Oracle ，领导着OC4J的开发团队，这确实对于刚刚被Oracle收购的BEA，是一个微妙的事件，但我相信，对WebLogic来说，是一个好消息。

WebLogic的复杂性，来自于分布式实现(Cluster也许是分布式的一种策略而非全部)，对于J2EE行业，Cluster无任何标准、Specification可以参考，甚至，你也不会指望WebLogic、WebSphere这些中间件的实例能够共同组成一个Cluster。

• 开源中间件模式及应用服务器介绍
• 国产中间件：SOA是趋势 个性化寻求突破
• Mule奠基人：JBI偏离了靶子
• IPTV中间件的架构日趋清晰
• 红帽再建中间件产业里程碑