dev2dev 首页 > 资源中心 > 技术文章
《流动城市——SOA策略、方法及实施案例》
编辑推荐：《流动城市——SOA策略、方法及实施案例》是BEA中国SOA专家组齐力撰写的一本小册子。他们作为国内SOA的先驱，将自己对SOA整个理论体系的理解、切身的业务发展感受和案例实施经验，毫无保留地呈现出来，希望与更多正在学习或者从事SOA相关工作的同行分享，是一本值得好好研读的指南。
序言
――SOA与城市规划管理
城市规划管理之于SOA，不仅仅是一个比喻，它本身的很多策略就是SOA实施过程中各种策略的指导。
两年前，BEA的SOA专家们开始用城市规划管理来比喻SOA：他们把应用比喻为建筑物；把SOA架构比喻为城市。过去几年的SOA实践经验证明，城市规划管理不仅仅是SOA的一个比喻，事实上，在企业内部实施SOA时所遇到的问题与城市规划管理遇到的问题非常相似。让我们从大家熟悉的丽江古城说起！
“活的古城”与“信息孤岛”
丽江古城规划建立于八百年前，现在仍然生机勃勃，被称为“活的古城”。为什么呢？让我们用SOA的观点来分析一下。
去过丽江的人都知道，丽江古城的核心是水：一条河流分成不同水道流经整个古城，每家门前都有流水，可以用水洗衣、做饭；所有的街道都按照经络学说布置，街区和住户则成为在部署在同一个基础设施上的服务。最有意思的是，作为集市的四方街，采用了自动水冲洗设施，整个古城的地势东高西低，四方街则是中间高、边缘低，因此，每天晚上当人们用挡板把水累积高时，水就可以自动冲洗街面了。
从SOA的观点来看，丽江古城的设计是面向服务的：现代的商业店铺仍然使用着原有的基础设施，流经整个古城水道的水就如同企业应用的数据，变成了一种公共服务；道路、桥梁、水道的整体设计一点也不影响每家每户自己按自己的模式建造房屋，每个住户都在整体规划之下保持了建筑的自主性。不仅如此，他们还通过一些规则来规范公共资源的使用，比如对于水的利用：清晨的九点：所有人在这个时间盛水做饭；下午五点，所有人都在这个时间洗衣服。不难看出，SOA里的松耦合的架构、服务契约、监管规则、基础设施等概念都可以在丽江古城里找到对应物。
不幸的是，对于大多数企业的CIO来说，他们从来没有拥有一个丽江古城式的先期设计。他们面对复杂的企业IT 应用，如同作为北京、上海这样大城市的规划与管理委员会，每天面对着无数盘根错节的管理问题：
如何让城市的新与旧融为和谐的一体？
如何在整体规划的角度下保持不同应用社区的业务自主？
如何在不影响城市正常运行的情况下，逐步建立起一套更为有效的基础设施？
如何打破部门障碍，建立一个全局性的监管运维中心？
无数个“信息孤岛”令CIO们颇感头疼。实施SOA是解决这一问题的良方。不过要想成功地实施SOA，我们尚需要两类专才：一类是规划阶段的企业架构师，他需要拥有城市规划师一样的宏观思维，更为关注在一张蓝图下如何定义具体建筑之间的关系，以及基础设施的设计；另一类是SOA监管专家，他们的工作更像市政委员会，制定城市建筑的规范、管理城市公共资源并负责监控城市的运营政策。这两类专才是以往软件工程体系里面所缺少的。
SOA背后的管理理念
对应于城市规划，我们可以简单归纳出SOA所蕴涵的管理理念。
1．用松藕合的架构平衡不同利益相关者
SOA与之前软件思潮最大不同是它面向业务的设计。SOA的架构理念不仅用松耦合的分层结构隔离了技术，使业务和技术的变化周期可以互不影响，更重要的是，它还可以让不同利益相关者在同一个平台上讨论问题。
例如，用BEA的Workspace平台可以让业务人员、架构师、IT主管、程序员集中起来，让他们可以在同一个平台上交谈；业务流程的设计与实现现在也可以用一种贯通的方式进行讨论与修改。以前，不同知识域的人群由于专业分工不同，因此有各自的思考角度，互相难于理解。现在，那些以前隔着墙打电话的人，可以在这样一个平台上共同交换信息、完成任务。大家都知道，好的应用程序是不可能由不懂业务的程序员开发出来，但以前苦于无法在业务和技术人员之间建立一种共同语言，现在这种语言出现了，它就是“服务”。
2．用契约的方式定义服务之间的关系
服务之间的调用由契约来固定，其实不难理解，契约其实就是市场经济的本质。契约论的最早理论基础来自卢梭的《社会契约论》，西方经济体系就是基于契约架构起来的。
从传统模式向SOA架构转变类似于从“计划经济”向“市场经济”的转变，具体到SOA的设计哲学里，Design By Contract完成了服务之间的调用契约，也为未来遍及整个IT系统的服务网络提供了基础。实施SOA以后的服务调用就像市场上的交易一样，可能是按次收费的，这样才会把服务的生产方调动起来。这种工业化的契约模式，在汽车这样的传统行业里早已通行百年：每种特定的零件都有很多供应商，只要基于标准的契约来设计，安装到整车上都可以保证整体的功能。软件行业的奇特之处在于，尽管软件行业在外人看来是个高科技行业，但这个行业在基于标准的生产方式上还远远不如离散制造业。这个行业充满了孤胆英雄、绿林大侠以及自我为中心的散漫气质。现在SOA要讲契约、讲标准、讲交换，这也许是Design By Contract面临的最大文化障碍。
3．用迭代和团队演进的实施方式平衡长短期ROI
北美有经验的SOA咨询顾问们在谈到SOA实施时的一个口头禅是：“SOA是一个3～5年的旅程，惟一的办法就是循序渐进”。
我们可以把SOA理解为一种混搭的中庸架构，说它混搭，是说它是独立于技术的，说它中庸，是因为它必须与现有的各种系统相融合。SOA改变的不仅是开发方式，而且是管理方式，甚至业务组织的方式，它不仅是个IT战略，还是一个公司战略。在这个缓慢进行的改良主义过程中，如何在每个阶段可以有一些阶段性的回报，是管理者必须考虑的问题。没有管理者会批复一个五年后才能有回报，又需要投入巨大投入的提案。针对每个企业设计一个有针对性的演进路线图，这不是个技术问题，而是一个业务问题。有一个SOA案例是客户在一年半的时间里达到了实施SOA项目的正向投资回报，其中的案例分析精确得像财务报表。只有这样的案例才会给管理者巨大的信心。当然，并不是在所有的情况下都会找到这样的项目，我们需要寻找“SOA友好”的项目。SOA有很多特点，比如，它与业务敏捷正相关、与变化的强相关、与企业集成的强相关以及与企业治理的强相关等。客户必须从业务和IT两个角度来寻找切入点，只有步步以ROI为考量，才能将这个旅程走下去。
4．用集中监管的理念克服组织行为的障碍
只需要用一天时间把SOA的基本设计哲学讲给一个管理学教授，他就会很快发现，SOA的监管与控制都是管理学命题。
推进SOA真正的难题在于组织障碍。比如，每个部门都想享受别人的服务，但自己却不愿意开放自己的服务。在现有的组织架构里，IT部门的工作有时需要靠人脉来解决，但一旦真正开始转向SOA，一些硬性的部门利益冲突就不可能再单纯依靠人脉来解决了。信息的拥有权在当代是如此重要，因此在很多时候，掌握重要信息的部门是不愿意信息共享的。SOA通过建立服务层这种变通的方式来获得各部门的支持，这就像一个建立城市公共设施的课题：如果SOA的目标是在企业内建立一套共享的IT资产管理体系和标准，那么这个工作就不可能仅由IT部门来推动，它需要一个SOA监管委员会，凌驾于所有部门之上，拥有绝对的生杀大权。这在很多企业里，等同于要把分属战国诸侯的资产统一起来，象秦始皇那样统一度量衡。一些国外的评论家认为，中国成为一个统一国家，秦始皇的贡献最大，因为他统一了度量衡、语言、甚至包括车辙的宽度。作为暴君的秦始皇给人的印象不好，但建立的标准人人在享用。政治学中有个词描述这个概念叫“政治所必要的恶”，就是这个意思。整治竖井式的部门应用，看来没有追求一致的狠手不行，这被称为制度保证。
在本手册的以下章节里，我们将详细阐述和讨论SOA的规划、建模、实施、运维、监管等问题，希望这些讨论有助于SOA的成功实施。
| 全文目录 |
| 序言 －－SOA与城市规划管理 |
| SOA切入点 -- 后ERP时代的信息架构 |
| SOA规划 -- 策略、原则、架构路线图 |
| SOA建模 -- 多视角的设计蓝图 |
| SOA实施 -- 一致的工程实施体系 |
| SOA运维 -- 监控，指标与反馈体系 |
| SOA监管 -- 成熟度与组织监管模型 |
| Q&A |
| 案例剖析 |
| 案例集锦 |
| 附录 BEA SOA产品结构图 |
 点击下载完整文档--SOA策略、方法及实施案例
作者其它文章
|
