接触WebLogic有段时间了，一直想写下一点什么。WebLogic唯一的界面就是AdminServer的Console，它做为一个Web界面的应用存在，协助管理WebLogic的各个组件。WebLogic的基本工作单位是Domain，虽然是一个虚拟概念，没有实体对应，那是因为WebLogic是纯Java实现运行在JVM上的进程，不会跟操作系统混淆。

每个WebLogic的Domain下会有很多Server，其中只有也近仅有一个是Admin Server，其他的都称作Managed Server，每一个Server都是单独的WebLogic Java实现的Instance，会独立的运行在它自己的JVM上，所以当有多个Managed Server在运行时，它们未必要在同一台机器，有各自的Address和IP，还有各自的控制台界面和Log System。

Server一般都必须配置拥有对应的Machine，这里的WebLogic Machine也是一个虚拟的概念，理论上我们希望WebLogic Domian会和真正的网络域对应上，也希望WebLogic Machine能和真正的物理机器所对应上。但由于一切都只是运行在JVM中而已，所以Domain和Machine也就在实现上虚拟化了。

如果希望通过Admin Server来管理在不同Address和Port上的Managed Server，就需要借助与Machine所绑定的NodeManager来帮忙，在Machine上配置NodeManager服务并启动之后，AdminServer可以给它发送请求，继而通过NodeManager来与绑定Machine上的Managed Server通信控制Server的启动到停止的一切生命周期。这里的原理其实就是JVM之间的通信，所以会用到RMI和序列化等Java技术。

WebLogic的任意个Server可以组成一个集群Cluster，这个集群等于很多JVM的集合体，互相之间认证后基本是相互透明认识的，可以协同实现负载均衡来完成企业级服务的响应。集群里不推荐加入Admin Server，因为它一般被保留做后台内部管理用，真正的Web服务都布署在Managed Server上，当一个集群的所有Managed Server都布署了某个Web应用时，它们可以通过JVM通信来实现灾难恢复。比如当前对外提供服务的是Server 1，许多用户正在访问它，Server 1所在的物理主机断电瘫痪了，此时无论是用户的Http Session或者正在持有提供服务的DB Connection，都可以通过对象序列化来传递给集群上的其他Server并由该Server继续为用户提供服务，当然不通过序列化在JVM之间传递的话也可以通过持久化对象到数据库中，其他Server再从数据库中把对象拿出来反序列化回来。

理解Java Socket的工作原理的话就能明白WebLogic集群重点是每个Server的Address和Port，只要有了这两个属性就可以找到彼此照应的兄弟。从这个意义上来讲似乎WebLogic的集群是非常容易配置和使用的。不过要深入理解WebLogic与其他中间件的区别并体会WebLogic到底有多么强大的话，就比较难了。因为WebLogic为了更好的提供分布式服务实现了强大而复杂的分布式协议栈，这些内部协议都集结了BEA几十年分布式的经验精华而成，比TCP/IP更简洁精炼。似乎都可以到达一种内部专利的级别了，另外，也正是得意于从头到尾的纯Java实现，才可以不考虑平台去完整的实现整个分布式服务的流程。

今天就先说到这了，还有很多细节有待挖掘，handle WebLogic, still a long way to go!