gembin

OSGi, Eclipse Equinox, ECF, Virgo, Gemini, Apache Felix, Karaf, Aires, Camel, Eclipse RCP

HBase, Hadoop, ZooKeeper, Cassandra

Flex4, AS3, Swiz framework, GraniteDS, BlazeDS etc.

There is nothing that software can't fix. Unfortunately, there is also nothing that software can't completely fuck up. That gap is called talent.

About Me

 

SCA:实现SOA的编程模型[zhuan]

SCA提供了实现面向服务的架构(SOA)的一个编程模型。
面向服务的架构已经在软件开发领域存在很多年了。但是当一些组织试图去定义最佳的实现和管理技能的时候,为一个特定组织开发一个SOA的细节却是难以捉摸的。在这篇文章里,我将介绍SOA的一种实现方式——服务-组件架构。

 SOA在概念上来说是关于松耦合的行为。业务和系统功能作为大的独立服务被展现,使得它们以不同的方式在业务流的组合中被使用。这是一个简单的描述,但实现起来就相当的复杂了。任何使用EAI和分布式技术的人都能回忆起在一个企业里兜售业务功能的困难。

SOA原理是抽象的,独立于实现技术。从开发角度来看,定义SOA构成是有帮助的,它使得工程师可以无须求助于技术规范来用具体术语讨论开发实现。为了这个目标,开放面向服务的架构(OSOA)组织发布了服务组件架构(SCA)规范1.1(www.osoa.com)。

SCA已经被IBM,BEA,Sun,Software AG,IONA,SAP,和Oracle以及其他一些公司开发很多年了。可以在IBM,Rogue Wave,Oracle,Tibco,Apache Software Foundation(Tuscany)和Eclipse Foundation(SOA Tools Platform)获取实现。

 SCA编程模型

SCA编程模型主要通过提供一个服务的开发,集合,部署的方法,来关注SOA的工程细节。为了和SOA原理一致,SCA通过元数据驱动,语言独立和容器 独立来支持异构的实现。只要一个从SCA规范到技术的映射可以被定义,SCA就能被实现。于是,SCA被和多种语言和容器绑定;最近的一个C语言规范以及 形成草案。

目前,SCA映射已经存在于Java,C++,RubySpring,和BPEL及其他语言中。另外,SCA绑定也在web服务,JMS,JCA和其他通信机制中存在。SCA的目标是减少SOA的概念原理到可以在一个具体上下文中讨论的具体元素集合。

SCA的好处有:

·使用组件和组合简化SOA实现
·使用松耦合的组件和参考来支持敏捷特性
·通过一个综合的调用模型支持事件驱动的行为
·将开发和集合分开,允许技术不可知的组合

建立服务:程序集(Assembly)模型

程序集模型描述了服务是如何被定义和配置的。

组件是SCA模型的核心,可以用支持SCA的任何语言来实现。一经定义,组件可以使用属性来声明配置,这将在接下来的实现中映射到accessor和mutator。

下面的是一个XML声明的组件。
//例1:组件声明

(a)
<component name="AddServiceComponent">
<implementation.java class="calculator.AddServiceImpl"/>
</component>
(b)
<component name="CalculatorServiceComponent">
<implementation.java class="calculator.CalculatorServiceImpl"/>
<reference name="addService">AddServiceComponent</reference>
</component>

  引用使得组件可以调用其他服务。引用在部署时或运行时被解析。例1(b)显示了一个例子引用。

组合是组件的群。根据声明,一个组合可以被作为一个服务或者新的组件使用。因此,SCA模型支持递归程序集。

如果你通过将服务元素包含在组合声明里,那服务本质就是组合。和组件类似,组合和服务可以通过属性来声明配置。就像你可以从SCA程序集的元素声明里看到的一样,已有的程序可以通过将应用建模为一个组件,组合或者提供一个可调用的程序接口而添加到架构中来。

布线(Wiring)

组件连接是通过布线来完成的,也就暗示了需要定义组件之间的源/目标信息。和其他SCA元素一样,布线细节可以被声明设置。SCA布线不需要元和目标是 一个相同的类型(比如Java到WSDL的接口就是可接受的),只要考虑到了诸如远端性,回调支持,容错,和异常处理等的兼容性。例3(a)是一个简单的 布线实例。

//例2:引用声明

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="CalculatorComposite">
<service name="CalculatorService">
<interface.java interface="calculator.CalculatorService"/>
<reference>CalculatorServiceComponent</reference>
</service>
<component name="CalculatorServiceComponent">
<implementation.java class="calculator.CalculatorServiceImpl"/>
<reference name="addService">AddServiceComponent</reference>
...
</component>
<component name="AddServiceComponent">
<implementation.java class="calculator.AddServiceImpl"/>
</component>
...
</composite>

//例3:(a)引用中的直接布线(b)和一个web服务绑定的引用

(a)
<reference name="stockQuoteService"
target="StockQuoteMediatorComponent"/>
(b)
<reference name="HelloWorldService">
<interface.java interface="helloworld.HelloWorldService"
callbackInterface="helloworld.HelloWorldCallback"/>
<interface.wsdl xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance" interface=
"http://helloworld#wsdl.interface(HelloWorld)"
callbackInterface="http://helloworld#wsdl.interface(HelloWorldCallback)"
wsdli:wsdlLocation="http://helloworld wsdl/helloworld.wsdl" />
<binding.ws endpoint=
"http://helloworld#wsdl.endpoint(HelloWorldService/HelloWorldSoapPort)"
location="wsdl/helloworld.wsdl" />
</reference>

为了简化开发,SCA支持“自动布线”。只要应用是明确的,容器就应该能在运行时布线组件。

Binding

SCA模型通过绑定支持服务之间的通信,这在很多技术中存在了。为了和规范一致,所有的实现必须支持一个SCA服务绑定和Web服务绑定。绑定是被服务 和应用使用的。服务使用绑定来定义它们如何被调用;引用使用它们来声明它们如何调用一个服务。例3(b)是一个使用web服务绑定的例子。

服务质量:策略框架

为了关注服务质量(QoS)和非功能化的需求,SCA模型提供了一个策略框架。策略可以用来定义安全,可用性和交易,以及其他需求。策略可以和每个组件关联在一起。服务和应用可以拥有多个策略来允许不同方式的访问。策略框架的主要元素是Intents, Profiles和Policy Sets。

Intents是在一个组件实现上的QoS限制的抽象描述。比如,消息需要是加密的。一个用“confidentility”命名的Intent可以如例4(a)中被定义。

//例4:(a)Intent声明;(b)Profile声明

(a)
<intent name="confidentiality" constrains="sca:binding">
<description>
Communication through this binding must prevent
unauthorized users from reading the messages.
</description>
</intent>
(b)
<sca:profile intents="sec.confidentiality rel.reliability"/>

Profiles是Intent名字的聚合。一个Profile中应用的Intents被映射到Policy Sets中的实现。例4(b)是一个Profile声明。

Policy Sets和Intents实现相关。它们在程序集模型里声明技术相关的元素限制。例5是一个和Confidentility Intent相关的Policy Set。这个例子使用了intentMap元素,表明一个给定的Intent的另一种实现。
//例5:使用一个intentMap和WS-PolicyAttachment的Policy Set

<policySet name="SecureMessagingPolicies"
provides="confidentiality"
appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<intentMap provides="confidentiality"
default="transport">
<qualifier name="transport">
<wsp:PolicyAttachment>
<wsp:AppliesTo>
<wsa:EndpointReference xmlns:myStore="..." >
<wsa:Address>http://myStore.example.com/acct
</wsa:Address>
<wsa:PortType>
myStore:myPortType
</wsa:PortType>
<wsa:ServiceName>
myStore:InventoryService
</wsa:ServiceName>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wsp:PolicyReference
URI="http://myStore.example.com/policies.xml" />
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
...
</wsp:PolicyAttachment>
</qualifier>
<qualifier name="message">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject for
"message" alternative" -->
...
</wsp:PolicyAttachment>
</qualifier>
</intentMap>
</policySet>

Policy Set包含了一个技术的规范,包括绑定,源,目标的细节。如果被要求使用一个公用密钥体系,Policy Set可以包含一些加密方法,信任关系和密钥存储的信息。WS-Policy和WS-PolicyAttachment是最好的Plicy Set声明的格式。然而,支持其他语言(比如XACML和所有权语言)是可能的,依赖于容器实现。

Intents通过组件元数据连接到组件上。例6给出了一个对服务声明的对连接认证和可靠性intents。

//例6:连接在服务上的Profile


<sca:service name="mySpecialService">
<sca:interface.wsdl portType="..." />
<sca:profile intents="sec.authentication rel.reliabilty"/>
</sca:service>

在写此文时,Policy Sets和Intents是包含在一个全局定义文件里的,它被通过Intent或Profile引用到一个程序集描述器文件。

数据访问:服务数据对象

  服务数据对象(SDO)并不是SCA模型合适的部分,但却是最好的SCA数据架构。SDO基于非连接数据图的概念。SDO架构保持了数据对象的树或图,可 以通过API访问。这个架构允许强类型和弱类型数据模型,因此支持静态和动态的数据访问机制。SDO架构并不对相关的查询语言进行假设。为了分开程序代码 和数据访问代码,架构鼓励使用数据访问服务(DAS)来操作图 (incubator.apache.org/tuscany/das_index.html)。通过增加元数据,SDO也支持运行时数据图的查看。既然 架构在理念上已经和XML同时设计,它也提供了丰富的操作XML的机制。事实上,为了实际使用考虑,一个SDO的数据结构最好是XML文档。在写此文时,SDO规范是2.1版本。

总结

SCA尝试基于SOA的概念去创建一个简单,强壮的编程模型。它的价值存在于概念的简单,程序集和QoS的声明式方式。通过集合时间和运行不行和松耦合 策略,SCA无须组件的先验知识来创建一个服务。这反过来也使得服务组件和结合开发者可以单独工作。和SDO结合,一个厂商中立的SOA方案是可能的—— 模型设计者从早先的模型中看到了其弱点——通过提供一个干净的程序集和QoS的区分。如果Apache Tuscany Project是一个SCA生存能力的验证,那么一个直接(尽管不是必须简单)的SOA实现是被保证了的。

posted on 2008-03-11 13:03 gembin 阅读(293) 评论(0)  编辑  收藏 所属分类: SCASOA


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(6)

随笔分类(440)

随笔档案(378)

文章档案(6)

新闻档案(1)

相册

收藏夹(9)

Adobe

Android

AS3

Blog-Links

Build

Design Pattern

Eclipse

Favorite Links

Flickr

Game Dev

HBase

Identity Management

IT resources

JEE

Language

OpenID

OSGi

SOA

Version Control

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜

free counters