|
从IT的"黑洞"谈起
最近参加了一个IT的高层年会，在会上众多的社会学家、金融专家和IT人士都谈到了IT的黑洞问题。让人们觉得IT似乎已经成为阻碍行业发展，乃至社会进步的障碍。IT的'丑陋面'竞相暴露：
IT部门，实实在在的成本中心
IT正在从支撑业务、引导业务变为限制业务发展
80%-90%的IT预算和IT人力都花在了维护老系统上
新业务的推出都需数月，乃至年计，跟不上客户的需求和市场的反应
难道IT真的成了鸡肋？难道我们可以舍弃IT？我想原因很简单，IT与业务其实就是一对发展中的矛盾共同体，互相依存、促进与平衡：
互相依存。现在一定没有人会怀疑业务离不开IT，如果没有了IT,任何的金融、电信、政务和生产制造业务都将瘫痪；而如果没有了业务的需求，IT也将失去存在和发展的价值。
互相促进。业务的发展要求IT不断地创新，如各个行业对于异地交易（通存通兑、通保通赔）的需求带来了消息中间件的发展；而同样地IT的创新也带来了新的业务模式，互联网的发展毫无质疑地带动了诸如金融业的网上银行、网上证券、网上保险，带动了电信的网上营业厅，甚至于直接影响我们衣食住行的网上商旅、网上商城，带来了许多新的商务模式。
互相平衡。业务与IT既然是一对矛盾体，那么任何一方的滞后或是超前都会带来另一方的"不安"，都会表现为矛盾的激化，都会涉及到现有平衡的打破与再建。
因此，我们看到的其实是如何发展IT的问题，而不是那些耸人听闻的需不需要IT的问题。正是有了这种矛盾的持续存在，IT才会有持续发展的土壤。
传统的开发或是集成，带来了复杂
传统来讲，IT实现业务的方式无外乎定制开发项目或是专业集成项目。也就是为了开发而开发，为了集成而集成。
当立为开发项目时，就根据需要确定集成商、开发商。然后选择相关的开发平台，如服务器、数据库、应用服务器、开发工具等。而在不同的开发项目中很有可能选择了不同的应用商，而采用了不同的开发平台。这样就带来了开发越多，未来集成越是困难。
而在专业集成项目中，由于大型企业的应用必须与一个或多个数据源进行业务数据交互，部分数据源可能就是其他的应用。换句话来说，应用在没有集成的情况下无法进行开发。应用集成会包含一定的应用开发任务，如开发和组装组件，将它们连接到后端系统，实现过程流和工作流，开发用户界面，以及进行测试和调试。而如果在集成项目中只根据现有的各种系统，选择一个集成商，采用一个专门的集成服务器，如门户集成服务器或是信息集成服务器或是应用集成服务器，这样是远远不够得，因为对于在集成过程中新的业务流程所需的再次开发就会捉襟见肘。
传统的三种最通用的应用集成方法是点到点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成，都不十分理想，主要问题在于：
消息总线和应用之间的定制或专有集成。与对等方法相比，EAI 和基于业务流程的集成减少了集成点的数量。但是，三种方法都需要在消息总线和每项应用间进行定制化或专有集成，并且，在每个集成点都需要采用不同的专有数据格式。
消息总线和应用之间的紧密耦合。所有的应用都需要知道与其集成的其它应用的内部工作机制。系统之间的集成是粒度化的，并与消息类型存在紧密耦合关系。传统的 EAI 实现所使用的业务流程管理 (BPM) 工具是专有的。这妨碍了其他优秀标准产品的应用。
程序化而非抽象式的数据访问。大部分数据访问、集成和转换工作（企业信息集成）都留给了开发人员采用人工编码方式来完成。企业IT环境中存在多个不同的数据源，开发人员要有不同的适配器来访问这些数据源、要有转换引擎来重新定义数据格式、还需要进行数据复制以实现数据的物理整合。要实现数据源的集成，开发人员需使用以上工具将集成需求编写到应用中去。尽管以上方法是可行的，但这既没有效率也缺乏灵活性。
所以，当用孤立的眼光来看开发与集成时，矛盾重重。而其实开发与集成已是一对矛盾共同体。任何定制开发的应用都需要去访问别的应用，也需要被别的应用来访问，因此开发离不开集成；而任何集成也都是为了新的应用需要而来，当然会有新的业务流程的开发，所以集成也离不开开发。
结论很简单，如果独立地考虑应用开发和应用集成是毫无价值的。而且传统的应用开发和集成方法不够灵活，未能基于标准。因此，传统方法无法构建能够满足动态企业变化需求的、敏捷的企业IT环境。
SOA融合开发与集成，化繁为简
三种传统的应用集成方法都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。
不同的行业分析家或专家对SOA有不同的定义和理解。Gartner 提出了SOA 这一术语，并定义如下： "面向服务的架构是一种客户机/服务器软件设计方法，其中应用由软件服务和软件服务使用者组成（也称为客户机或服务请求者）" 。SOA 与多数一般的客户机/服务器模型不同，它明确地强调了软件组件之间的松散耦合，以及其独立标准界面的使用。CBDI 论坛如下定义了"面向服务" (SO)，重点强调了服务的提供和管理： "SO 是业务和技术服务的提供、使用和生命周期管理，这些业务和技术服务是自描述、松散耦合和以技术中立的方式来实现的。"SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。
不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA、DCOM、EJB 和 RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。
SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 SOA 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。
SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web 服务接口，这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA 可以将系统和应用迅速转换为服务。SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能，所以基于SOA的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。
与传统的企业应用集成架构的主要区别在于该系统使用基于标准的服务，并包括过程/数据服务、编排和组合。基于标准的服务成了应用间的集成点。服务的编排和组合增加了服务的灵活性、重用性和集成性。
下表强调了分布式组件架构和 SOA 的区别：
表1：分布式服务与面向服务的架构比较
| 分布式组件架构 |
面向服务的架构 |
| 面向功能性 |
面向流程 |
| 设计目的是为了维持现状 |
设计目的是为了适应变化 |
| 开发周期长 |
交互式和重用性开发 |
| 成本为中心 |
业务为中心 |
| 应用阻塞 |
服务协调 |
| 紧密耦合 |
敏捷的和可适应的 |
| 同构技术 |
异构技术 |
| 面向对象 |
面向消息 |
| 需深入了解实施细节 |
对实施细节进行概要抽象 |
与传统方法相比，SOA具有以下更多优势：基于标准、松散耦合、共享服务、粗粒度和联合控制。
服务是网络中可用的软件资源。服务提供者通过标准机制提供服务，服务使用者通过网络有计划性地使用服务。服务代理发布服务所在位置，并在使用者请求服务时定位服务。服务使用者和提供者的角色不是惟一的；服务提供者也可以是使用者，反之亦然。
提供者在服务约定中以标准语言描述其服务，并向代理发布服务。客户从服务代理处（或登记处）查询所需的服务，并接收有关服务访问的约定和信息。随后，客户或使用者便可绑定到服务，并可与提供者直接通信。
服务实现包含了服务的功能或业务逻辑。对于服务使用者来说，服务实现应该是一个"黑匣子"；用户没必要知道服务的功能实现细节。 有五种类型的服务：
1. 数据访问-允许对不同数据源进行统一访问
2. 组件-提供对打包应用服务的访问，如ERP
3. 业务-提供使用一个以上打包应用或定制应用功能的复杂服务
4. 组合-使用以上三种类型的服务来创建包括新功能和现有功能的新服务
5. 共享的或企业基础架构服务?-?消息日志之类的低级服务，其重用性使快速创建新的高级服务成为可能
在SOA的架构下，不管是数据访问、组件访问还是业务访问，都是对于服务的访问，并可在此基础上组合和共享。企业就此有了标准的服务规范和接口，计算环境变得简单了。
BEA WebLogic，构建SOA的“服务仓库”
企业基础架构服务或共享服务为 SOA 增加了很大价值。共享服务由于自身的功能和位置特点，通常是在逻辑层实现的。这些特性由共享服务层实现，该层在逻辑上由几个服务层组成。
让我们再来看看部署及其后续工作：
部署
部署模型的选择需要依赖于网络架构，同时还取决于应用、运行和管理需要如何从逻辑和物理上进行分离。而以上这些通常是由企业的IT策略决定的。BEA提供了联合部署或独立部署的灵活性，因此可以选择任意的部署模型来支持IT策略。可以按层（表示、集成、流程和数据）分离应用，也可以从经营和管理来分离应用。这样可以实现最佳的控制和灵活性，但额外的硬件服务器和软件许可也确实增加了成本。采用WSM产品增加了需要在同一服务器中部署的组件数量，或增加了所需管理的服务器数量。
运行、经营和管理（OA&M）
但是，SOA将开发和OA&M分离开来，这显著减少了不同类型用户所使用的接口数量。采用基于策略的计算模式，绝大部分控制交由OA&M人员来操作。这意味着他们可以采用WSM产品的用户界面，而非WebLogic控制台。
这样在BEA的WebLogic框架之上，不断地构筑业务需要的各种标准服务，实实在在地形成一个“服务仓库”。按需服务，最终实现企业的商务自主！
|