| 编辑推荐: |
本文介绍了SCA的主要目的和一些基本的概念，并展示了一个最为简单的服务组件例子。
来自于csdn，,由火龙果软件Anna编辑、推荐。 |
|
概述：
目前业界主要的软件厂商都在大力推广面向服务的架构（Service Oritented Architecture，SOA）的概念，但是对于很多客户来说，SOA的概念还是显得相对抽象的。为了使客户能够更加简单的实现向这种面向服务架构的转变，IBM在推出一系列WebSphere新产品的同时，提出了一种新的服务组件模型。这是一种全新的、跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的组件类型，比如POJO,
EJB, 流程组件，人工交互组件等都可以通过一种标准的接口来封装和调用。结合SDO的数据模型，这种服务组件的编程模型可以大大的简化客户的编程，提高应用的灵活性，这就是面向服务组件的架构（Service
Component Architecture，SCA）。目前IBM 对SCA的支持是在最近推出的WebSphere
Process Server（WPS）中，但是以后该服务组件模型将作为一个IBM软件重要的编程模型被应用到底层平台当中。本文将介绍SCA编程模型中的基本概念，并以一个简单的例子来说明它的一些基本用法，期待能够抛砖引玉，并为读者以后深入了解SCA打下基础。
1.1 SCA的起源
基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法，但是往往对于不同语言我们有不同的组件模型，从而需要不同的调用方式。比如在J2EE技术领域，我们就有EJB，POJO，JDBC，JMS等，这对于开发人员来说是一个极大的挑战。为了给这些不同的接口提供一个统一的调用方式，IBM提出了WSIF
（Web Service Invocation Framework，具体请参考http://ws.apache.org/wsif/
），并将它贡献给Apache组织。WSIF作为Web Service领域的一个规范，提供了一种基于Java
API统一调用各种服务的能力。但是WSIF没有形成一个基于组件的架构模型，因此IBM在此基础上推出了一个面向服务的组件模型（Service
Oritented Architecture, SCA）。这个模型不但解决了统一调用的问题，还提出了一个基于组件的构建模型，并提供了许多面向企业计算的QoS能力。因此，从技术的角度来说，SCA是WSIF的延续和扩展。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。
1.2 SCA中的基本概念
服务组件模型（SCA）中提出了一些新的概念，比如服务组件，模块，共享库，导入和导出等。下面将分别解释这些服务组件中的基本概念。
1.2.1 服务组件
服务组件是SCA中的基本组成元素和基本构建单位，也是我们具体实现业务逻辑的地方。我们可以把它看成是构建我们应用的积木。我们可以非常容易地把传统的POJO，无状态会话BEAN等包装成SCA中的服务组件。
SCA服务组件的主要接口规范是基于WSDL（Web Service Description Language）的，另外为了给Java编程人员提供一个比较直接的接口，SCA的部分服务组件也提供了Java接口。因此，使用服务组件的客户端可以选择使用WSDL接口或Java接口。
服务组件提供给别的服务调用的入口叫Interface（接口）。而服务组件本身可能也需要调用别的服务，这个调用出口叫Reference（引用）。无论是接口还是引用，其调用规范都是WSDL或Java接口。SCA服务组件的接口模型请参考图
1：
图 1： SCA 服务组件接口模型
WebSphere Process Server 充分利用了SCA的这种组件架构，并在产品中提供了一些与业务联系比较紧密的组件，比如业务流程，人工任务，业务状态机，业务规则等。这样用户就可以直接利用这些服务组件，构建自己的业务流程或其它业务集成的应用。在WebSphere
Process Server V6.0.1中，服务组件及SCA在架构中的作用如图 2所示：
图 2： WebSphere Process Server V6.0.1的架构环境
我们可以从图 2 中看到服务组件架构在WebSphere Process Server中的基础地位，也可以看到各种与业务相关的服务组件或技术相关的辅助服务组件的关系。关于WebSphere
Process Server的体系架构这里不展开论述，具体请参考developerWorks专刊，2005年第三期的文章――WebSphere
Process Srever V6体系结构概述。
SCA服务组件与传统组件的主要区别在于：
1． 服务组件往往是粗粒度的，而传统组件以细粒度居多。
2． 服务组件的接口是标准的，主要是WSDL接口，而传统组件常以具体API形式出现。
3． 服务组件的实现与语言是无关的，而传统组件常绑定某种特定的语言。
4． 服务组件可以通过组件容器提供QoS的服务，而传统组件完全由程序代码直接控制。
1.2.2 服务模块（Module）
服务模块（简称模块）由一个或多个具有内在业务联系的服务组件构成。把多少服务组件放在一个模块中，或者把哪些服务组件放在一起主要取决于业务需求和部署上灵活性的要求。模块是SCA中的运行单位，因为一个SCA模块背后对应的是一个J2EE的企业应用项目。这里之所以说是"背后"，原因是我们在开发工具WID（WebSphere
Integration Developer V6.0）中，通过业务集成透视图看到都是SCA级别的元素。但是当你切换到J2EE透视图你就会发现这些SCA元素与实际J2EE元素之间的对应关系。因此，在WID中构建一个模块就相当于构建一个项目。另外，由于模块是一个独立部署的单元，这给应用的部署带来很大的灵活性。比如，只要保持模块接口不变，我们很容易通过重新部署新的模块而替换原有的业务逻辑，而不影响应用的其它部分。
由于一个模块中往往会包含多个服务组件，那我们如何来构建这些服务组件之间的相互调用关系呢？在WID工具中，我们只要简单地通过接口与引用之间的连线，就可以指定它们之间的调用关系而不需要写一行代码。另外，我们可以在这些连线上面设定需要的QoS要求，比如事务，安全等。
1.2.3 导入（Import）和导出（Export）
用户实际的应用经常是比较复杂的，因此实际的应用通常需要多个模块才能满足要求，而且这些模块之间又往往存在相互调用的关系。
另外模块中服务组件除了调用别的服务组件之外，也需要调用已有的一些应用，或者是让一些已有的应用来调用模块的服务，而这些应用可能不是基于SCA架构的。为了解决上述问题，在模块中我们引入了两个特殊的"端点"，一个是导入（Import），它的作用是使得模块中的服务组件可以调用模块外部的服务。另一个是导出（Export），它的作用是使得模块外部的应用可以调用模块中的服务组件。
由于涉及到模块内外的调用，因此需要指定专门的绑定信息。这些绑定信息包括了目标服务或源服务的调用方式，位置信息，调用的方法等。目前，在WebSphere
Process Server V6.0中，导入端点提供了四种绑定方式，包括：JMS绑定，Web Service绑定，SCA绑定和无状态会话BEAN的绑定。导出端点提供了三种绑定方式，包括：JMS绑定，Web
Service绑定和SCA绑定。对于SCA模块之间的调用，我们可以非常方便的把绑定方式设置为SCA绑定，但是对于非SCA模块与SCA模块之间的调用我们只能选择其它绑定方式。
1.2.4 共享库（Library）
当我们在构建了多个模块的时候，如果有一些资源可以在不同模块之间共享，那么我们可以选择创建一份可以在不同模块之间进行共享的资源，而不是在不同模块中重复创建。共享库就是存放这些共享资源的地方。共享库可以通过与模块类似的方式在WID中创建，但是共享库包含的内容只有：数据定义，接口定义，数据映射和关系。与模块最大的区别使共享库不包含服务组件，因此也就不包含业务逻辑。从包含的功能来看，我们可以把共享库看作是模块的一个子集。当一个模块需要用到共享库中的资源的时候，我们只需要使模块依赖于共享库即可。从部署的角度，一个共享库会对应一个JAR包。在部署的时候，模块所对应的J2EE企业应用会会自动包含所依赖的共享库JAR包。这里特别要注意的是，这里的共享库概念与WebSphere应用服务器中的共享库不是一个概念，它们之间没有任何联系，因此不要混淆。
1.2.5 Standalone Reference
模块中的服务组件是不能直接被外部Java代码使用的，为了外部的Java代码，比如JSP/Servlet使用模块中的服务组件，WID工具在模块中提供了一个特殊的端点，叫做Standalone
Reference。这个端点只有引用（Reference），而没有接口（Interface）。只要把这个端点的引用连接到需要调用的服务组件的接口，外部的Java代码通过这个引用的名称来调用相应的服务组件了。具体如何调用请参考后面例子的实际代码。
至此，与服务模块相关的主要概念已大概介绍完了，它们之间的关系如图 3 所示：
图 3：服务模块总览图
1.3 同步调用和异步调用
我们知道，常见的方法调用都是同步调用，这种调用方式是一种阻塞式的调用方式，即客户端（主调用方）代码一直阻塞等待直到被服务端（被调用方）返回为止。这种调用方式相对比较直观，也是大部分编程语言直接支持的一种调用方式。但是，如果我们面对是基于粗粒度的服务组件，面对的是一些需要比较长时间才能有响应的应用场景，那么我们就需要一种非阻塞式调用方式，即异步调用方式。
SCA编程模式提供了三种方式的异步调用，它们分别是：
1． 单向调用方式。
2． 延迟响应方式。
3． 请求回调方式。
单向调用
单向调用方式是最为简单的异步调用方式，在这种调用方式中，客户端发出请求之后就不再关心服务端的情况，包括是否执行成功，返回值是什么等等。我们可以用下面的图
4示来描述这种单向调用方式：
图 4: 单向调用
单向调用方式是一种不管调用结果的方式，但是在很多情况下我们是需要知道调用结果的。我们需要知道调用是否成功，需要知道调用的结果，就算调用失败我们也希望知道错误代码等信息。在这种情况下，延迟响应和请求回调就是两种能够让我们知道调用结果的方式。
延迟响应方式
延迟响应方式是指客户端在发出调用请求之后继续执行，但是经过一段时间之后，客户端再调用相应的方法去检索返回结果，并通过参数指定如何根据调用的结果而执行进一步动作。由于是异步调用方式，因此，在第一次发出调用请求的时候，服务端需要返回一个称为票据（Ticket）的对象。这个对象会作为第二次发出检索结果请求时的一个参数。显然，这个Ticket对象的作用与WEB编程的SessionID非常类似。我们可以用图
5 来表示延迟相应调用方式：
图 5：延迟响应调用方式
请求回调
与延迟响应方式类似，请求回调方式也能得到服务端的响应，但是不同的是这个响应是由服务端通过回调方式来触发的，而不像延迟响应方式由客户端来主动检索的。请求回调方式的原理与许多编程语言中的回调机制类似，不同的是这里实现的层次比较高一点。我们可以用图6来表示请求调用方式：
图 6：请求回调方式
1.4 SCA客户端的两种调用方式
从接口的角度，SCA的客户端编程模型有两种方式：
1． 静态调用方式
2． 动态调用方式
静态调用方式
静态调用方式是一种类型安全的方式，也是在一般Java编程中最为常见的方式。所谓类型安全指的就是在编译的时候就做类型的检查，而不是等到运行的时候发现类型错误问题。说明示例如下：
在SCA客户端编程中，静态方式就是直接拿到实际实现的接口类型，也即直接拿到Java接口。
动态调用方式
与静态调用方式相对，动态调用方式是一种非安全的方式。它的优点是调用非常灵活，但同时带来的不利之处是部分问题在编译的时候是发现不了的，只有等到运行的时候才能发现。说明示例如下：
像上面例子所示，在动态调用方式中，客户端通过invoke方法的字符串参数的方式来指定具体要调用的方法名称。很显然，在这种方式下，如果方法名有误是不能在编译时发现的。
关于动态调用方式另外要注意的一点是，在这种调用方式下，所有参数传递都是通过DataObject的方式，即SDO的方式。哪怕实际参数只是一个字符串，也需要包装成一个DataObject的方式。
接口类型与调用方式
实际上客户端采用哪种调用方式是与接口类型有密切的关系。当提供的接口类型是WSDL类型的，那么客户端的调用方式只能是动态调用方式。由于WSDL是SCA模型中主要的接口方式，这样就导致动态调用方式在SCA编程模型中非常普遍。但是如果提供的接口类型时Java类型的，那么客户端的调用方式可以是动态调用方式，也可以是静态调用方式。
1.5 SCA的第一个例子――HelloWorld
与学习一种语言一样，在初步了解一些基本概念之后，您是不是迫不及待的想自己动手写点东西了？让我们一起来写一个"SCA版"的HelloWorld。我们需要的开发环境就是一个WebSphere
Integration Developer V6.0（WID），与IBM的许多其它的开发工具类似，这也是一个基于Eclipse
3.0的开发工具。下面简单描述一下WID与IBM其它开发工具如Rational Application
Developer（RAD），Rational Software Architecture（RSA），WebSphere
Business Modeler等工具的区别。如果采用基于角色的开发方式，我们一般可以把集成项目的主要开发人员分为下面四大类：业务分析人员，集成开发人员，软件架构师，J2EE/JAVA应用开发人员。他们的主要职责、技术要求和推荐使用的工具可以参见下表：
由上表可知，WID是一个主要针对集成开发人员的工具。除了专门的集成功能之外，WID工具也包含了RAD中的大部分功能。为了便于集成应用的测试，这个开发工具集成了一个测试环境，即WebSphere
Process Server V6.0的运行环境。
这个例子的主要目的是帮助大家进一步理解前面描述的那些SCA基本概念。在HelloWorld应用模块中，我们会构建一个用Java实现的SCA组件，其接口为HelloWorldInterface.wsdl，其实现代码为HelloWorldImpl.java。为了使SCA模块外部的JSP文件可以调用这个SCA组件，需要一个Standalone
Reference。在模块外部，我们构建一个index.jsp文件通过Standalone Reference来调用HelloWorld服务组件，并在页面上把调用结果显式出来。整个HelloWorld应用的基本图示如下：
图 7： HelloWorld 应用
1.5.1 构建的基本步骤
下面给出创建HelloWorld例子的基本步骤：
1． 创建模块。打开WID，切换到Business Integration透视图，新建一个模块，名称为HelloWorld。
2． 创建接口。通过点击HelloWorld模块左边的"＋"号展开，选择"Interface"，然后通过右键创建一个接口，名称为HelloWorldInterface。图示如下：
HelloWorld接口包含一个sengMessage操作，输入为一个名为message的字符串，输出一个名为status的字符串。可以通过点击接口编辑器上方的按钮来添加一个操作。通过和分别来添加输入和输出参数。图示如下：
3． 创建服务组件。双击打开HelloWorld模块的图形化编辑器，然后在控制面板上把Java组件图标
拖拉到编辑器中即生成一个Java服务组件，并把名称改为HelloWorld。如下图所示：
通过点击 按钮为HelloWorld组件选择一个接口，即我们前面定义的HelloWorldInterface。
通过双击上图中的HelloWorld组件，WID会自动生成HelloWorld组件实现类的基本框架HelloWorldImpl.java。如下图所示：
上图中高亮处显示的代码行就是我们可以给sendMessage方法添加业务代码的地方。比如，我们可以输入：return
message + ". It's our first SCA example!";
4． 创建standalone reference。在工具栏中把 图标拖拉到编辑器中即生成一个standalone
reference。如下图所示：
然后把Standalone Reference端点与HelloWorld组件连接起来。工具自动会为Standalone
Reference创建一个匹配HelloWorld组件接口的引用。这里要注意的是，向导在自动创建Standalone
Reference的引用时会弹出一个窗口询问需要创建一个Java接口类型的引用还是WSDL接口类型的引用。不同类型的接口会使得我们的客户端代码（在本例中是一个名为index.jsp的JSP文件）需要采用不同的调用方式。下面会分析两种不同类型的实现。
5． 生成JSP代码。如果我们在前面的引用接口类型中选择的是WSDL接口。那么Standalone
Reference的属性如下图所示：
我们可以看到，引用的名称为HelloWorldInterfacePartner，接口为名称为HelloWorldInterface这个WSDL类型的接口。
如果我们在前面的引用接口类型中选择的是Java接口。那么Standalone Reference的属性如下图所示：
我们可以看到，引用的名称为HelloWorldInterfacePartner，接口为名称为world.hello.hello.world.interface_
.HelloWorldInterface这个Java类型的接口。具体JSP代码参考下面的客户端代码分析部分。
6． 检查生成的项目。如果把WID切换到J2EE透视图的导航视图中，我们可以看到与HelloWorld模块对应的J2EE项目。J2EE企业项目为HelloWorldApp，其包含EJB项目HelloWorldEJB，Web项目HelloWorldWeb，J2EE客户端项目HelloWorldEJBClient。另外一个是名为HelloWorld的Java项目，这个项目的内容最终会以一个JAR文件的形式被HelloWorldApp应用使用。上一步中所提到的JSP文件需要在HelloWorldWeb项目中生成。具体如下图所示：
1.5.2 JSP客户端代码片断分析
那么如何在JSP页面中来调用我们的HelloWorld服务组件呢？按照前面的介绍，我们需要通过Standalone
Reference来调用。那么我们如何才能得到这个Standalone Reference的引用呢？这里涉及到SCA编程模式中很重要的一个概念，那就是ServiceManager。ServiceManager是一个SCA环境的核心类，全名为com.ibm.websphere.sca.ServiceManager。这个类的作用主要就是能够让客户端去定位一个服务提供方。一般调用的方式是通过ServiceManager的locateService(String
serviceRefName)方法。拿到服务之后，客户端就可以调用服务中所提供的方法了。（熟悉J2EE编程的人员可以联系对比JNDI的Lookup方法。）下面分别根据Standalone
Reference引用的接口类型来分析主要JSP代码片断。
当接口类型是WSDL接口的情况
1．首先需要在JSP中导入相关的类，主要如下：
<%@ page import= "com.ibm.websphere.sca.ServiceManager"
%>
<%@ page import= "com.ibm.websphere.sca.Service"
%>
<%@ page import= "commonj.sdo.DataObject"
%> |
2．生成ServiceManager对象，并拿到相应的服务。
ServiceManager
serviceManager = new ServiceManager();
Service service = (Service) serviceManager.locateService
("HelloWorldInterfacePartner"); |
这里locateService()方法中的参数是standalone reference的实际名称。从某种程度上我们可以把外部的JSP/Servlet的Java代码看成是Standalone
reference的实现，这样来理解服务组件之间的相互调用。
3．调用服务的方法。
String msg =
request.getParameter("message");
DataObject resp = (DataObject) service.invoke ("sendMessage",msg); |
由于我们这里使用的是WSDL接口类型，因此返回结果是以DataObject的形式存在。
4． 显式得到的结果。
| <%=resp.getString("status")%> |
通过调用DataObject的getString方法，我们拿到实际的返回结果，名为status的字符串。
当接口类型是Java接口的情况
1．首先需要在JSP中导入相关的类，主要如下：
<%@ page import= "com.ibm.websphere.sca.ServiceManager"
%>
<%@ page import= "com.ibm.websphere.sca.Service"
%>
<%@ page import= "world.hello.hello.world.interface_
.HelloWorldInterface" %> |
2．生成ServiceManager对象，并拿到相应的服务。
ServiceManager
serviceManager = new ServiceManager();
HelloWorldInterface service =
(HelloWorldInterface) serviceManager.locateService ("HelloWorldInterfacePartner"); |
由于Standalone Reference的接口变成了Java接口，因此这里返回的服务可以直接造型成HelloWorldInterface类型。
3．调用服务的方法。
String msg =
request.getParameter("message");
String resp = service.sendMessage(msg); |
由于我们这里使用的是Java接口类型，因此调用的方式就是正常的Java接口调用。
4． 显式得到的结果。
由于静态调用方式得到的就是实际定义的类型，因此这里字符串的显式比较简单。
具体实际项目的代码请参考本文附的项目交换文件包。
1.6 结束语
本文介绍了SCA的主要目的和一些基本的概念，并展示了一个最为简单的服务组件例子。从上面的讨论我们可以看到，SCA不但解决了统一调用的问题，而且提供了一个服务组件架构。这个服务组件架构将在构建面向服务的架构中起到举足轻重的作用，并在IBM的许多产品中会有所体现。
|
