使用Enterprise SOA中文版的步骤
- 书名：Enterprise SOA中文版—— 面向服务架构的最佳实战
- 作者：(美)Dirk Krafzig， Karl Banke，Dirk Slama著，韩宏志 译
- 来源：清华大学出版社
- 出版时间：2006年07月
- ISBN:7-302-13029-9
- 定价：48元
-----------------------------------------------------------------------
冯强/文
前言：CSDN推出的在线读书栏目，真的是好，并不是因为省了买书的钱（毕竟和拿着纸制书的感觉是不一样的），主要是没有太多时间去淘书，而且本地有没有太新的IT书籍。为了备忘，随时抄录和总结一下。我只会记对自己的新知和感兴趣的内容，请大家谅解。我自己的评述，将用红字标出，特此说明。
1.1敏捷性帮助企业摆脱烦恼
Nicolas G. Carr 2003年在Harvard Business Review上发表了一篇题为“IT doesn't matter”的文章，认为“IT将成为一种无处不在的物品，像电网或铁路一样稀松平常。”虽然这在当时引起了不小的争议，有人不认同他的看法，但“企业IT是必不可少的物品”一说的确有它的道理：当今的企业高度依赖于IT基础结构，以支持几乎所有的业务流程，如制造、发布、销售、客户管理和记账等。经济全球化营造了一个激烈的竞争环境，业务流程不断变化：企业必须敏锐观察市场条件的变化，并迅速调整策略，来适应这些更改；企业IT部门必须根据公司策略的变化，快速有效地调整执行策略的主干——公司IT系统。
当今的企业软件陷入进退维谷的境地，在企业软件开发中，总遇到“不敏捷”和“效率不高”两大难题。由于“不敏捷”，企业不能依赖IT基础结构来快速满足业务需求的变化，缺乏有效应对市场需求的能力。由于“效率不高”，企业软件开发的成本过高，投入的资金往往“得不偿失”。我们来具体分析一个典型的企业软件系统。在系统使用初期，生产效率和敏捷性都令人满意，处于“绿色区域”，此时的系统拥有很多新功能，也能较快、较有效地满足“更改请求”。但是好景不长，在初期系统实现就绪，并执行了一些更改请求后，系统适应更改的能力显著下降，随着时间的推移，维护难度越来越大。如图：
对于这个图，我有不同看法，系统上线初期，并非是生产效率和敏捷性的“绿色区域”，真正实施过系统的都知道，系统上线后有一段痛苦的磨合期，不仅仅是IT方面的，更多的来自业务层面，业务人员操作习惯和抵触，新系统种种小问题的纷纷暴露和解决过程等等。
1.3 企业软件架构的重要性
根据热力学第二定律：“任何闭合系统都不能自我增加内部有序度。”即“有序化”系统的任何行为都会增加它自身的“无序”(熵)。这个定律在很多方面也适用于企业软件，也就是说，必须保持“外部干预”，以提高“有序度”，确保开发工作的有效性。在企业软件中，架构师扮演着外部影响者和控制者的角色。对于各个软件项目，他既要使单个项目达到策略目标，又需要站在整个组织的战略性高度分析问题。他必须平衡各种要求，并使企业软件环境内部保持恒久的“有序度”。“企业软件架构”是架构师最有力的武器。功能的更改和扩展会增加系统的复杂性，降低效率。软件架构师则“重构”当前解决方案，不断降低复杂性，增加系统敏捷性，如图：
图：软件架构师通过重构来抵消不断增加的系统复杂性
在日常使用架构时，普通事件会增加企业的复杂性，许多独立事件也会对企业产生重大影响。这些事件包括：大幅改变现行管理范围、支持产品过期、在联合或并购过程中新增了大量基础结构片断。在出现这些事件时，必须及时对架构实施大手术，以保持架构的简易性和可维护状态。联合或并购经常会产生“土崩瓦解”的结果：联合后，简明财务表找不到了，并购后，原始系统的能力消耗殆荆这些事件的出现通常是随机的，因此，必须长期保持企业架构的可维护性和可更改性。
1.4 企业软件架构的要求
企业软件架构与企业的内部组织、流程和业务模型密切相关，它不同于其他软件架构(例如机器人或视频游戏引擎等由少量高素质域专家控制的系统的软件架构，它必须完成一些非常特殊的要求。为提高IT敏捷性和效率，企业软件架构必须具备以下特性：
(1)简单性。企业架构必须简单易用，以保证关键人员之间能有效沟通。如前所述，很多人都要参与到企业软件的规范制定和构建上，例如职能部门的IT协调员，以及技术架构师。这些人的角色不同，对软件有不同的看法，掌握的技术集也可能不同。很多IT协调员有丰富的业务领域知识，却对技术一无所知。相反，技术架构师精通技术，却对垂直业务知之甚少。所有参与者都必须能够根据各自分工(例如，在业务级别指定新功能，并实现和维护之)，理解和管理架构。构架的简单性，应该是从宏观来看的，但为了实现后面的灵活性和可维护性，在某些细节上会形成复杂化的情况。这些需要软件构架师来评估，也体现了构架的价值。
(2)灵活性和可维护性。
(3)可重用性。 今天下午的CRM例会上讲开发时，我还提到了代码重用的问题。
(4)将功能和技术分开。
1.5 “企业构架”和“企业标准”的关系
SOA不是一项技术，也不是一项技术标准，而是一个高级概念SOA独立于标准，提供了架构蓝图。架构蓝图切开、分块和组合企业应用程序层，将组件创建和表示为SOA中的“服务”，服务技术上独立于业务功能，却与业务功能直接相关。SOA允许在本地级别构建应用程序组件，也允许在全局上集成这些组件。从本书后面可看到，SOA不支持特殊运行时协议如SOA或IIOP，不全局强制执行技术标准，也不基于严格标准和规范。如图1-3所示。
图1-3 在20世纪80年代、90年代，EDM和ESB是应对企业计算挑战的流行方法
EDM=Enterprise Data Model,企业数据模型
ESB=Enterprise Software Bus,企业软件总线
（未完待续）
本文地址：http://www.45fan.com/a/question/68495.html