SOA 的实际应用

在过去几年间，面向服务的体系结构（Service-Oriented Architecture，SOA）受到了极大的关注，带来了软件开发和业务敏捷性的新时代。不过，仅仅 SOA 本身并不能解决世界的 IT 问题。我们仍然需要可靠而有效的软件工程实践，因为管理落后的 SOA 实现和其他体系结构方法一样会出错（如果不是更糟糕的话）。本文将从实际的角度看待 SOA（技术和业务两方面），并将提供一个实际的案例研究，说明通过成功的 SOA 实现带来的好处。

撩开神秘面纱

关于 SOA，目前并没有统一的定义，但为了实现灵活性和业务敏捷性的体系结构目标，确定了以下这个得到广泛认可的抽象定义：

定义 SOA 的体系结构风格描述一组模式和指导原则，以创建松散耦合的基于标准且与业务相结合的服务，由于描述、实现和绑定之间实现了关注分离，这些服务能够提供更高级别的灵活性，以响应业务威胁和机会。

按照达尔文的优胜劣汰观点，SOA 是之前的分布式体系结构风格（如分布式组件对象模型（Component Object Model，DCOM）、Common Object Request Broker Architecture (CORBA) 和 Enterprise JavaBeans (EJB)）的自然进化，但其中又融合了各种标准（特别是基于 XML 的标准），以提供更好的互操作能力。另外还特别明确地强调业务一致性，而这在之前的体系结构中并没有占到主流地位。SOA 通过这一点为业务流程驱动的开发提供了理想的平台，可让业务分析人员完全参与到软件开发生命周期中来，而这就是它的一个重要优势。

不过，直接采用 SOA 并不能保证项目成功（ESB 并不是企业的尚方宝剑！），有些项目根本就不应该采用 SOA 方法。我们都听到过人们谈论各种不好的体系结构和失败项目，然后说“SOA 应该能够解决这个问题”。但是，就像我们很可能会创建笨拙庞大的基于 Java™ 2 Platform Enterprise Edition (J2EE) 的体系结构一样，我们也很容易用错 SOA。如果 EJB 的早期实现失败了，其原因应是有些架构师并没有真正地了解技术的限制（亲历过由于某种数据库搜索而导致应用程序将数百个在容器管理的持久性 [CMP] 实体 Bean 加载到内存中的情况的人应该清楚我所指的是什么）。但就 SOA 而言，这并不简单。对服务采用类似的全权委托理论已导致了对每个应用程序功能调用都内部使用 Web 服务的应用程序的出现——不再是完全的性能解决方案！

本文转自：IBM developerWorks 中国

请点击此处查看全文。http://ibm.csdn.net/ISN_J.aspx?action=JMP&pointid=2475