【IT168 专稿】
编者按：
《WebSphere很庞大，但依然可以灵活，就看你怎么做》，这是本次WebSphere征文大赛中一篇参赛作品的标题。这个标题让人不禁想到一本书名《谁说大象不能跳舞？》。
《谁说大象不能跳舞？》是前任IBM董事长郭士纳亲笔写就的自传，是郭士纳亲历的IBM管理传奇。IBM长期以来执计算机世界之牛耳，被视为美国科技实力的象征和国家竞争力的堡垒。1993年，郭士纳刚刚接手IBM时，这家超大型企业因为机构臃肿和孤立封闭的企业文化已经变得步履蹒跚，亏损高达160亿美元，面临着被拆分的危险。
20世纪30年代，IBM主机系统的成功奠定了IBM的至高地位，IBM真正成为IT业的全球大腕。围绕自己的主机系统，IBM建立了庞大的软件开发、咨询、销售、服务体系。s/360是电脑历史上的里程碑。但是，s/360的实施远非规划那么容易达到。在著名的《人月神话》中，参与s/360开发的作者暗示，s/360的开发就像落在史前焦油坑里的怪物，硕大无比而无法收场。
而个人电脑时代的兴起和互联网时代的到来，20世纪90年代早期，IBM真正是千头万绪、问题重重、暮气沉沉。媒体和专家都在给IBM出谋划策：为了生存下去，IBM撤分成更小的单位，似乎更适合生存和成长。在这样的背景下，郭士纳临危受命，成为IBM的掌舵人。
而在郭士纳看来，大，很重要，因为规模就是杠杆。深度和广度可以容纳更大的投资、更大的风险以及更长久的对未来的投入。这不是大象是否能够战胜蚂蚁的问题，这是一只大象是否能跳舞的问题。如果大象能够跳舞，那么蚂蚁就必须离开舞台。
在郭士纳的带领下，IBM经受考验，浴火重生，成功转型为今天世界上最大的IT服务公司。
作为这只大象组成的一部分，IBM WebSphere同样秉承了这一特征：大。如果提问WebSphere家族共包括多少类产品线，多少种产品数，恐怕大多数的IBM WebSphere部门员工也答不上来。面对着迷惑的用户，也许这篇征文的标题能够道出WebSphere的心声：我很庞大，可是我很灵活。就像依然能够起舞的大象，我是庞大却灵活的WebSphere。
征文大赛一等奖：WebSphere从相识到相知
征文大赛二等奖：随“机”应变的架构—— 基于Websphere BTT和WEMP的手机银行
征文大赛三等奖：漫谈WebSphere应用服务器之事务
WebSphere很庞大，但依然可以灵活，就看你怎么做
一提到IBM WebSphere，相信绝大多数经历过的人都会感觉很庞大，就像航空母舰一般，功能很全，同时也会感觉很笨重、很难用。其实，任何事情都不是绝对的，WebSphere是很庞大，但依然可以灵活，就看你怎么做。这篇文章是最近写的，但内容却是一年半前做的事情，没关系，不影响主题。这篇文章过后，也许你也会多少改变对WebSphere的看法。
WebSphere Message Broker是IBM的应用整合中间件，是IBM WebSphere业务整合解决方案的重要组成部分之一，是IBM构建企业服务总线（ESB）平台中功能最多，支持消息格式、协议最多的一款产品，就让我们从Message Broker开始吧。
基于IBM WebSphere Message Broker平台，利用其提供的基本功能组件，可以实现企业服务总线（ESB）。我们可以将服务挂到ESB上，供其他组件调用，并且要通过ESB中介协调服务之间的不适应性，包括数据格式、传输协议等。一般的ESB解决方案可以做到这些功能，但是，存在着一些问题。比如：中介过程存在着硬编码、只能通过开发环境修改中介逻辑或消息定义、维护后需要重新部署、对于相似的中介过程要创建多个消息流等问题。这些问题都制约着ESB基础结构的灵活性，直接影响到企业IT架构能否及时响应变化。所以，有必要研究并实现一种解决方案，解决这些问题，使得ESB中介过程的创建及维护更加的规范、迅速、灵活。
在基于WebSphere Message Broker做过几个项目后，逐渐的分析、总结、归纳了一种ESB的解决方案，先称之为“元数据驱动、可配置的ESB解决方案”吧。
这个方案的核心理念是：将中介过程做成统一的“流水线”模板，各处理“单元”通过动态的提取中介逻辑元数据来创建及管理中介过程实例。中介流程处理内容包括数据内容解析、格式验证、转换、传输协议的转换、数据的路由等。每一种中介过程都对应着一套中介逻辑，包括总体配置信息、消息转换配置信息、路由信息等配置文件。
ESB中介过程的消息流不再是某两个具体服务之间的中介，而是多个中介过程统一遵循的一个模板，这个模板会根据各个处理单元对应的不同的元数据进行中介，产生不同的ESB中介过程实例。
摒弃通过Message Broker对消息格式的定制和开发的模式，改用“元数据”的方式承载各种消息格式。ESB中介过程中需要的一些逻辑数据，都是存储在元数据中而非存储在Message Broker的消息流定义或消息集定义中。也就是说，这些中介逻辑数据不是被硬编码到中介过程中、并且不被部署到Message Broker的运行环境中，所以，当修改这些元数据时不存在重新部署的问题，对于ESB来讲，这些元数据的变化是透明的。整个解决方案正是基于这些元数据来进行消息间的动态中介的。
最核心、最简单的描述就是：“动态”、“元数据”。通过Message Broker中的ESQL或者Java计算节点，我们可以解析请求消息的内容，通过消息内容，在运行时动态的提取出中介逻辑，包括消息格式转换信息、路由信息等。通过transformation节点，根据消息格式转换配置信息，利用XSLT进行消息格式的转换。通过route label节点，根据路由配置信息，将消息分发到不同传输协议的端点。而所有的元数据（中介逻辑配置信息文件）都存储在WebSphere Service Registry & Repository (WSRR)中，在Message Broker中，利用endpoint lookup节点访问WSRR获取元数据配置信息。可以支持多种主流的传输协议（Web Service、MQ、JMS等），提供相应的消息输入、输出节点，最终实现N*N的中介方式。可以形象的比喻，中介过程就是一个“做菜过程”的“流水线”，步骤都是“准备原材料”、“添加调味品”、“烹制”、“出锅”等基本过程，根据“菜谱”的不同，做出来的菜肴就会不同。中介模板就是“流水线”，元数据就是“菜谱”。
另外，提供基于Web页面的管理配置方式，而非在开发环境下再编码的方式对ESB中介过程进行改动和维护。主要是对元数据的维护，包括元数据的创建、修改、删除等操作，这样，极大的提高了ESB中介过程创建和维护的灵活性和方便性，使得整个ESB基础结构可以更加灵活的应对变化。
这还不是一个成熟的解决方案，只是用来提出一种构建及管理ESB的理念。“动态”、“运行时”、“元数据”、“可配置”，这些关键词都是构建灵活的企业应用不可或缺的。SOA的核心思想在于“服务”。“服务”们独立、可组装、可服用，构建应用就像“搭积木”，这些都是正确的思想，没有问题。但我们不应忽略了SOA另外的承诺，“IT基础能灵活、迅速的适应业务应用的变化”，这才是最有价值的地方，如果应用的改变导致IT层面的“在开发平台中改code”、“宕机”、“重新部署”等现象的发生，那很抱歉，SOA没有做的比“前辈”更好，或者说SOA在“忽悠”，应用灵活不是这样定义的。如何在已构建的企业界架构上，以最小的代价灵活的响应业务的变化，是SOA应该大力做的事情。企业级应用档次的高低不仅在于使用了什么样的产品，更在于设计的是什么样的基础架构，一种好的架构风格，可以构造一个良好的应用生态环境，而“动态”、“运行时”、“元数据”、“可配置”正是我们应该持有并遵循的思想和理念。
基于WebSphere家族的N多产品，这么一个大而全的平台，加上一些正确的指导思想和理念，相信IBM在企业级应用领域一定会提供更为先进、优秀的解决方案。WebSphere很庞大，但依然可以灵活，就看你怎么做。
