SCA就定义了这么一套通用的解决方案。SCA起先是由一组开发厂商（包括BEA、IBM、Oracle、SAP等）创建的，现在归OASIS所有。SCA规范给出了如何创建组件和如何将这些组件装配成一个完整的应用程序的定义。SCA应用程序中的组件可以由java或其他语言来开发，也可以用其他技术，比如BPEL或Spring框架技术。不管采用何种组件开发技术，SCA都定义了一套通用装配机制来说明这些组件是如何组装成应用程序的。
每个SCA应用都是由一个或多个组件(component)构成的。在一个简单的应用中，组件(component)也许是运行在单一进程中的java类，他们通过彼此暴露出来的java接口进行交互。再复杂点的话，java类也许运行在不同的机器上，通过相同的通讯机制来进行交互。再更复杂些，应用也许包含了一些由java实现的组件，另一些是由C++实现的，甚至用BEPL定义的，并且所有这些组件都广泛分布在各个机器上。所有的这些情况都存在一个共同点：必须要有一个定义组件(component)并描述他们如何交互的方法。在一个渐增式面向服务的世界里，这些交互都被建模成服务，并清晰地从提供的功能里分离出了实现细节。
要做这些，SCA定义了组件的通用概念。它也指定了组件(component)是如何装配成更大的构件(composite)的。下图展现了如何由３个SCA的组件(component)组成一个简单的构件(composite)的。
构件(composite)是一个逻辑结构：它的组件能运行在一个单一机器上也能分布在多台机器的多个进程中。一个完整的应用程序也许就由一个构件(composite)构成，比如上图演示的，或者也可能由若干不同的构件(composite)构成。这些组件也许是用相同的技术开发的，也可能不是。如图所示，SCA应用也许由非SCA技术的软件访问，比如JSP,Webservice客户端或其他的什么技术。SCA应用程序的组件也能访问数据。其中一种访问方式就是使用SDO，它(SDO)也许会用到标准的java数据访问技术，例如JDBC或Java5的JPA(Java Persistence API)。SCA组件也能用JDBC,JPA或其他技术。SCA规范并不强制规定。
非常典型地，SCA构件在一个相关的配置文件中描述，这个配置文件的后缀名为.composite。
该文件为XML格式，配置语言称为SCDL（全称:Service Component Definition Language――服务组件定义语言）。SCDL来描述构件所包含的组件，同时指定他们彼此之间的相关性。以上的例子的SCDL配置如下：
<composite name="ExampleComposite" ...>
<component name="Component1">
...
</component>
<component name="Component2">
...
</component>
<component name="Component3">
...
</component>
</composite>
组件和构件是SCA应用的基本元素。他们都包含在一个更大的结构中，该结构称为“域”(domain)。所以要理解SOA就要理解domain。
域
关于SCA创建者的一个隐式的假设是在给定的环境会安装一组SCA产品，一般来说某个产商会提供运行时环境。比如，假设一个大公司的一个部门选择了某个特定的SCA提供商。这个部门很可能就要把他们所选定的SCA提供商的SCA运行时环境安装到机器里。这不是不切实际的假想，因为它反映出公司是如何购买和安装J2EE产品的。这些SCA运行时环境也许由相同的组内成员来管理。那么这整套系统――包括厂商的运行时技术和管理――就构成了一个最简单的“域”这个概念。
域在SCA中是非常重要的概念。来看看为什么，虽然我们知道SCA允许创建分布式应用，但它并没完全定义在不同机器上的组件是如何交互的。所以，这些组件之间的通讯能够用不同的产品来实现。(在下面SCA的实现这节描述了，SCA运行时允许第三方创建容器，这个容器能挂载到支持特定技术的运行时环境中，比如BEPL 技术)。
域能包含一个或多个构件，每个构件都包含了多个运行在一台或多台机器上的一个或多个进程中的组件。下图给出了一个例子：
这里展示的“域”包含了三个组件三个构件。图中上半部所显示的构件由五个分布在两台机子中跨越了三个进程的组件构成。图中下半部所显示的另外两个构件，都运行在一台机子上，分布在三个独立的进程中。组件与组件之间，不管是在同一个进程中，或进程间还是机器间的通讯方式都会因每个不同的SCA厂商而定义不同。但不管怎么定义，构件都不能跨越“域”的界限。
多厂商的关于创建分布式应用的方式没有固定的定义，同时应用中的组件交互的方式也没有定义。理解了这个，我们就意识到SCA创建者的主要目标是代码的移植性和开发者开发方式不会受到不同SCA实现的影响。同时创建能跨越“域”的构件也许有一天能成为可能的，不能跨越“域”的规定并不是SCA第一版的目标。限制组件在一个单一的域中允许更有效的优化。在一个域中，SCA开发者的工作是相当简单的，比如，能避免由于多厂商应用配置的复杂性。
不要被搞糊涂了。虽然SCA 构件运行在单一的厂商环境中，它还是可以与它自己域外部的应用程序进行通讯的。SCA组件能通过使用交互性协议比如Webservice来开放自己的可访问性接口。如下图：
这个例子展示了两个SCA域，每个域都在两台机器上。一个域使用了X厂商的SCA运行时环境，而另一个用了Y厂商的SCA运行时环境。每个域内的这些组件和构件彼此之间的通讯都是各自厂商的方式，SCA并没有强制交互应该如何进行。要进行域之间的通讯或与非SOA应用的通讯，组件都允许通过Webservice或其他一致的交互机制。事实上，SCA应用与其他的处于不同域内的SCA应用的交互看上去就跟与非SCA应用的交互一样；在域外SCA是不可见的。
理解组件(component)
组件是SCA应用程序的原子，因此SCA组件行为上要保持一致性以便他们能装配。理解SCA要从理解这些基础的应用程序构件块开始。
以SCA的说法，组件是一个实现的实例，该实现是可以配置的。实现是提供组件功能的代码，比如可以是java类或BPEL过程(process)。用SCDL表达的配置信息定义了组件是如何与外部世界交互的。理论上来说，SCA组件能够用任何一种技术实现。当然不管是用什么技术，每个组件还是要依赖一些通用抽象集的，包括服务，引用，属性和绑定，用这些来描述自身与外部世界的交互方式。这一节就描述上面提到的通用抽象集。
服务、引用和属性
从外部来看，SCA组件是一个简单的东西。然而不管是用什么技术创建的组件，他都有下图所示的基础部分。
每个组件一般都实现一些业务逻辑，并将他们做为一个或多个服务公布出去。图中是用绿色箭头表示的服务，提供了一些能让组件客户程序访问的操作。服务如何来描述则依赖于实现组件所采用的技术。比如，Java实现的组件也许用Java接口来描述服务，而用BPEL实现的组件也许用WSDL（全称：Web Services Description Language――Web服务描述语言）来描述服务。
在给自己的客户提供服务的时候，组件也许还会依赖于同一域中其他组件或域外软件所提供的服务。为了描述这个，组件能通过引用定位它所依赖的服务。上图紫色箭头，每个引用都定义了一个包含当前组件需要调用的操作的接口。
这些服务和引用的核心概念是值得斟酌一番的。用服务去建模组件提供给客户的功能越来越普遍了。最近，显式地定义引用也更流行了，它有些优势。首先，正式地表达了组件的依赖关系能帮助开发者认清代码间的关系，开发者喜欢它。显式的引用还允许依赖注入(DI)。DI这个苦涩的短语有一个简单的含义：改变原来要求开发者自己写定位一个组件所依赖的服务的代码，现在SCA运行时能定位该服务了。少写代码是很好的，因为这样可以不用修改任何lookup的代码而更容易地实现从一个运行环境到另一个运行环境的移植。
除了服务和引用外，组件还能定义一个或多个属性。每个属性都包含一个值，该值在组件初始化的时候可以从SCDL配置文件中读取。比如，组件会通过属性得知自己运行的环境，从而定制自己的行为。
绑定
服务和引用都是用于组件通讯的。通过设计，组件根本不需清楚通讯是怎么进行的。这个就是绑定所做的工作。下图给出了SCA中的绑定的好处。
绑定确切地说明了SCA组件和其他软体之间的通讯是如何来进行的。根据通讯对象的不同，组件可能有也可能没有显式地指定绑定。如图所示，同一个域内的与其他组件通讯的组件，不管他们是在不同的进程中，还是在不同的机器上，都不需要任何显式地指定绑定。运行时环境会决定会用到什么绑定，从而把开发者从这些繁杂的事务中解脱出来。
然而，为了与域外通讯，不管是不是运行在某个其他域的SCA应用，组件的创建者（也许会是部署组件的人）必须指定通讯的绑定。每个绑定都定义了用于与服务或引用通讯的特定协议。每个服务或引用能有多种绑定机制，允许通过不同的方式与不同的远程软体进行通讯。
因为绑定把组件的通讯从组件的功能中分离出来，所以他们让组件的业务逻辑与通讯细节剥离开来。这是源自试图将通讯和功能混合在一起的老技术，简化和应用的设计和开发。
一个例子：SCA的JAVA组件模型
SCA组件的基本抽象很简单：服务，引用，属性和绑定。然而，抽象还不够。必须有一种告诉我们如何去抽象这些从而创建出组件的方法。
一些已有的技术已经和SCA组件的抽象很匹配了。比如，Spring框架提供了对服务、引用和属性的显式支持，所以可以将这些直接映射到SCA的理念。因此，利用Spring创建SCA组件的规范定义内容并不多。类似的BPEL也对SCA组件的抽象提供了某些内置的支持。例如，BEPL的Partnerlink（伙伴服务）这个概念就能映射成服务和引用。而要求使用属性的扩展，通过使用BPEL来创建组件的SCA规范也非常短的内容，不超过12张纸的内容。
即使BEPL和Spring都是创建SCA组件的可行候选技术，但都不是以SCA的理念来创建的。那么为什么不设计一个用于创建SCA组件的基础编程模型呢？这就是SCA的Java组件模型做的工作。下一节将描述SCA组件是如何使用这种新的编程模型来创建的。
在此之前，为什么SCA的创建者要选择去发明另一个新的java编程模型呢，这个问题值得我们去思考。一个主要的动机就是面向服务方法的需要。当前的Java业务逻辑编程模型，比如EJB,并不是将服务看做是一种基础设施的。因此，Java EE 5的技术完全没有与SCA的组件理念匹配上。同时也因为绑定将通讯细节从业务逻辑中分离出来，所以基于SCA的Java组件模型支持各种不同的通讯方式。依次，使用SCA的新组件模型能明显简化开发。
定义服务
不象老的J2EE 技术，SCA的Java编程模型依赖于annotation而不依赖于API调用。这种方式使得创建基础服务非常容易。事实上，对于一个给本地客户提供的服务，根本没有什么要求，一个Java接口和类就行了。然而对于远程客户访问的服务必须象下图那样指明相应的annotation的接口
import org.osoa.sca.annotations.Remotable;
@Remotable
public interface AS
{
int add(int a, int b);
int subtract(int a, int b);
}
public interface MD
{
int multiply(int a, int b);
（阅读次数：）
共3页: 上一页 1 [2] [3] 下一页
收藏
推荐
评论(0条)
