英语原文共 353 页，剩余内容已隐藏，支付完成后下载完整资料
1 SCA简介
服务组件架构，即SCA，是一个为了创建服务并把这些服务装配进组合应用的技术。SCA解决了一个长期存在的问题，即如何构建由一系列相互联系的部分组成的系统。在SCA 中,这些部分是通过提供执行特定功能的服务进行交互的。服务可能使用不同技术和编程语言实现。例如，一个服务可以用Java、C ，又或者是业务流程执行语言（BPEL）这种特定的语言来实现。服务还可能被配置在同一操作系统进程中，或者分布运行在不同机器的多个进程中。SCA提供了一个框架来构建这些服务，描述它们如何通信以及把它们捆绑在一起。
我们曾经听到过一个对技术框架有趣的定义，该定义在这个背景下提出是非常恰当的：技术框架是一个每个人都想写，但是没有人想用的东西。
事实上，为了以一种创新性的方法来解决应用开发中出现的问题，这个行业充满了各种框架和编程模型。在1990年代，分布式计算环境（DCE）被通用对象请求代理体系结构（CORBA）和分布式的组件对象模型（DCOM）替代。在2000年代早期，Java企业版（Java EE）和.NET取代CORBA和DCOM成为两个主流框架。开源活动也已经成为技术创新的中心，Spring和Ruby on Rails在这活动中成为两个更加流行的框架。
那么问题来了，为什么SCA会出现？现有的编程模型中有哪些问题是SCA想要解决的？SCA的一个技术范围，以及它是由一组不同的供应商提供的事实，导致了我们在一定程度上对这些方面的误解。最开始理解SCA时非常困难。
SCA解决了现有方法的两个关键问题，复杂性和重用。首先，SCA为构建分布式系统提供了一个简化版的编程模型。如今，占主导地位的编程模型已经变得非常复杂。例如，写一个Java EE的应用程序来发布Web服务，执行一些处理，还有把消息系统通过接口集成在其它应用上，需要JAX-WS, JMS, and EJB APIs的知识。这种复杂性并不局限于Java EE：.NET框架也有遭受这种复杂性的趋势。与使用SCA编写应用程序相比，使用.NET2.0框架编写一个相同的应用程序需要理解ASP .NET Web 服务，企业服务和.NET消息这些的API。
相反，如图1.1所示，SCA提供了一个统一的方法构建应用程序，它的通信使用了各种通信协议。
图1.1 SCA提供了一个统一的方法来构建分布式应用程序
剖析：SCA和.NET
如今，不断增加的复杂度不局限于Java EE：.NET框架也遭受这种复杂性的趋势。与使用SCA编写应用程序相比，使用.NET2.0框架编写一个相同的应用程序需要理解ASP .NET Web 服务，企业服务和.NET消息传递这些的API。
微软花了大量的时间处理.NET框架中存在的复杂性。.NET从3.0版本开始集成了一个编程模型来统一Web服务，远程过程调用，消息队列和事务。SCA引入了统一的方法来执行分布式交互。SCA和窗体通信基础（WCF）的应用程序逻辑以相同的方式被调用Web服务，二进制或者消息队列来使用。（见图1.2）
图1.2 SCA和.NET体系结构
这种统一的方法在开发过程中消除了应用程序逻辑借助专门的、低层次的API，从而简化了开发过程。
第二个SCA解决的问题和重用相关。有两种代码重用基本类型：在同一进程（进程内重用）和跨进程（进程间重用）。面向对象的编程语言引入了新的特性使得应用程序在同一进程中可以被分解成更小的单元，这些新特性包括接口，类，多态和继承等。通过依据类来构建应用程序，面向对象的代码可能比用过程式编程语言的代码更容易被访问，被复用和被管理。
在1990年代，ECE、ECOM、CORBA和EJB等分布式对象技术试图对分布在跨越多个进程的应用中使用于进程内的应用相同的复用原理。经过无数次迭代，行业人员明白了运用面向对象设计原理的分布式对象技术，不能不经任何改变就跨进程使用。分布式对象技术经常导致应用程序在体系结构上把客户端和服务提供者紧密连接在一起。这种连接使得系统极其脆弱。更新某一服务提供者的新版本的应用程序常常导致客户端不兼容。此外，这些技术未能充分解决远程通信过程中的偏差，例如网络延迟这种偏差，经常导致系统性能的低下。
然而，尽管分布式对象有这些缺点，这个想法在进程间复用仍然有效：运行在多个客户端的多个进程的代码被组织成可复用而且容易被访问的单元有很大的价值。我们将更详细地解释，SCA为应用程序资源被多个客户端共享提供了基础和逻辑，这是建立在从分布式对象中得到的经验之上。和面向对象语言为了组织和复用进程内应用程序逻辑提供的机制相似，SCA提供了一种装配、管理和控制分布式系统的方法。
为了实现复用，SCA定义了服务、组件和复合体。SCA把应用程序组织成为客户端（尤其是其它组件）提供功能的多个组件。服务可被多个客户端复用。组件相应地也会依赖于其它服务。正如我们将看到，SCA提供了一种机制来把组件连接到这些服务。这是通过一个叫复合体的XML文件来实现的。图1.3显示了一个典型的SCA应用程序。
图1.3 一个SCA应用程序
SCA和企业架构
与Java EE和.NET不同，SCA并不打算成为一个包罗万千的技术平台。SCA并不指定保存数据的机制，也不指定一个为构建用户接口的表示层的技术。相反，SCA与其他企业的技术集成，比如为了在数据库中保存数据与JDBC和Java持久性体系结构（JPA）集成，还有与现今存在的无数的基于Web的UI框架（举几个例子，servlets和JSP，Struts，JavaServer Faces[JSFs]，还有Spring WebFlow）集成，图1.4说明了一个典型的SCA架构，它包含了表现和持久化的技术的使用。
图1.4 SCA使用表现和持久化的技术
在第10章“使用BPEL进行基于服务的开发”和第11章“持久化“中，我们将仔细看看在使用SCA时使用更加流行的持久化和表现技术。
剖析：一种新的标准化方法？
如今，SCA是根据官方安排的过程和程序制定的OASIS标准。在OASIS标准之前，从2005年11月到2007年7月，SCA作为供应商之间合作一部分而被完成，称为“开放SOA”或“OSOS（www.osoa.org）。
不是让官方标准组织做这项工作的一个主要原因是SCA的不成熟和上市时间：标准化组织过于官僚，他们的流程使事情处理起来非常缓慢。这不一定是坏事，特别是对于许多企业必须依赖多年的成熟的技术来说。在这些情况下，稳定性是需要最优先考虑的问题。
相比之下，SCA是一个在快速发展的新技术。因此，协作参与者需要一种可以迅速改变的能力，这种改变有时会破坏与之前版本的规范说明的兼容性。即使粗略地比较发布于2005年11月的0.9版本和发布于2007年3月的1.0版本，也可以很快地看出1.0版本有很多重大的新特性，并且在很多地方进行了大量的修改。
事后看来，这无疑是正确的方法。这个过程引人注目的一个方面是它偏离了被很多之前的规范采用的路线，尤其是Java EE和CORBA，这些规范很大程度上是由官方标准委员会设计的。从这方面来看，SCA和Web服务标准制定之初有很多相同的地方：作为供应商合作的非正式产物先于提交给官方标准组织的正式标准。
鉴于Web服务和SCA都转向采用协作模型先于标准化的这种方法，行业有可能会迎来一个关于如何开发技术规范的转变。尽管这种依据快速迭代的方法确实有好处，但是也有潜在的负面影响。那些潜在的负面影响之一是“烟雾弥漫的房间场景”，也就是几个供应商协力创建标准但是却不考虑真正的用户需求。我们需要等等，看看这种协作的方式是否会变成新技术发展的一种做法，以及它是否表示在开发属于标准主体的完整的技术规范的一种进步。
本章的其它部分提供了SCA的概述，包括它的关键概念。然后，我们不是止步于介绍传统技术，我们会试图阐明那些不容易通过阅读SCA规范本身来收集的内容。特别地，我们将仔细考虑SCA如何与其它技术相关联，比如Web服务和Java EE。我们也将突出SCA背后的设计原理和设想。
与其它技术一样，使用SCA有益处也有一些因为权衡而必须放弃的东西。这是一种适合非常多的场景的一种技术，但是不能肯定地说适用于所有的情况。我们在这一章的目的，并最终通过这本书，是为了让读者理解一些必要的知识，从而可以对何时以及如何使用它做出明智的决定。
剖析：SCA的历史
作为供应商合作的产物，我们可能可以更准确地说，SCA有非常多的“历史”而不只有一个。在OASIS和OSOA之前，众多的规范参与者在SCA的前体中工作，要么是内部项目要么是非正式跨公司的工作组。例如，BEA和IBM在组件模型技术上一起工作了一年多，甚至共同开发代码。其中的一些技术，包括后来演变成SCA核心概念的装配技术。
是什么导致了这些厂商为SCA共同努力？毫无疑问，有很多原因导致了这件事情的发生，但是所有厂商都有一个共同的原因，那就是他们都认识到微软的产品开发模型对于他们·所在的那个市场是不可行的。与微软足够大到可以单方面地明确自己的未来不同，SCA的四大合作方-BEA、IBM、Oracle和SAP，都没有足够的市场份额可以独自指引未来的技术发展方向。为了实现个体供应商的目标，行业达成一致是非常重要的。
在我们两人都被雇佣的BEA的案例中，我们学到的这个教训已经过时。在SCA之前，BEA开发了一个叫WorkStop的专有的编程模型，目的是为了简化Java EE。WorkShop采用了微软规避规范的策略，以利于在引入用户需要的新特性时能够得到采用。如果考虑到Workshop背后的人来自微软，那么这就不足为奇了。
最终，Workshop在通过创新本身获得广泛接受的这个策略上失败了。然而，BEA的案例不是唯一的：行业充斥着失败的尝试从而推动自主框架和编程模型的进步。通过这件事，SCA的众多积极独立的供应商聚集体明白了合作和达成共识的重要性。
概要
SCA是建立在四个关键概念上：服务、组件、复合体和域。理解每个概念的作用是理解SCA的基础。在这部分内容，在更详细地去看如何使用SCA来构建应用程序之前，我们会对这些概念做一个概述。
服务
在SCA中，应用程序被组织成一组服务来执行特定的任务，比如接受贷款申请，执行信用核查，或者执行库存查询。服务这个术语已经被用在这个行业中指代非常多的事物。SCA中的一个服务有两个属性：契约和地址。
服务契约
服务契约是指一组客户端可用的操作，它需要有输入并且一定会有输出。服务契约可以通过多种机制定义。一个简单的例子是使用Java的类，那么接口就可能被定义成为服务契约。清单1.1是一个服务契约的例子，它使用Java的接口定义了两个操作。这个例子中把接口指定为SCA的唯一标记是@Remotable，它能够指示服务可以被远程客户端使用（稍后将做详细讲解）。
清单1.1 一个基于Java的服务契约
@Remotable
public interface Calculator {
float add(float operand1, float operand2);
float subtract(float operand1, float operand2);
float multiply(float operand1, float operand2);
float divide(float operand1, float operand2);
}
在更复杂的情况，服务契约可能在代码被编写之前使用一个专门的结构描述语言来声明，比如WSDL或者IDL。这种自顶向下或者契约优先的开发方法为组织提供了一种在接口服务提供给客户端时维持紧密联系的方法。
在SCA自顶向下开发中最常用的语言是基于XML的Web服务描述语言（WSDL）。就像它的名字所表明的那样，WSDL更常用于定义web服务契约。SCA也是使用WSDL去规定一个服务契约。清单1.2展示了WSDL等价的计算器服务契约。
清单1.2 一个基于WSDL的服务契约
lt;wsdl:definitions xmlns:clc='urn:com:bigbank:util:calculator' xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/' xmlns:xs=http://www.w3.org/2001/XMLSchema targetNamespace='urn:com:bigbank:util:calculator'gt;
lt;wsdl:typesgt;
lt;xs:schema targetNamespace='urn:com:bigbank:util:calculator'gt;
lt;xs:element name='operands'gt;
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[146977]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
