月蚀传说

浮躁让人失去理智
posts - 25, comments - 101, trackbacks - 0, articles - 0
  BlogJava :: 首页 ::  :: 联系 :: 聚合  :: 管理

浅谈SCA

Posted on 2006-10-06 04:24 Dart 阅读(2991) 评论(10)  编辑  收藏 所属分类: SCA

SCA 是由几家国内外知名企业联合制定的,他们成立了一个名为OSOA的组织,SCA 标准目前还在完善阶段,它于 2005 11 月发布了 0.9 版本,目前版本已经到了 0.96 。在 0.9 版本中, SCA 标准就提出了 Java 实现以及 C++ 实现标准,而且在以后的版本中,会陆续加入其他的实现标准,也就是说 SCA 并不是只针对某一种语言的,不同语言或者环境之间通过开放的,标准的技术来实现互操作,比如我们常见的WebService等


SCA
提出的这套基于 SOA 去构建企业应用的编程模型,它的基础思想就将业务功能构造成一系列的服务,并且能够很好地将这些服务组合起来,达到解决业务需求的目的。在构建这些应用时所用到的服务,不仅包含新建服务,而且可以包括已有的业务应用中的业务功能,也就是说, SCA 提供了一套针对服务组合和服务创建的模型。

目前来看,虽然有很多标榜自己是基于 SOA 的产品或者框架,但是大部分还是各自为战,而 SCA 的出现有望统一基于 SOA 思想的框架。 Apache 已经在最近完成了 SCA 标准的实现,各位可以去 Apache 的网站看看。国内的一家 Framework 厂商普元也加入到了 OSOA ,并且也宣布会在 2007 年发布一套 SCA 框架的 Framework

 

SCA 具体的应用目前还不太清楚,不过 IBM 的新版本 Websphere 实现了 SCA 0.9 标准,估计慢慢地会让 SCA 得到更广泛的应用。在这片文章里我想简单谈谈 SCA 中的一些重要概念: Module,Component,ComponentType,Entry Point,External Service

 

Module

Module SCA 构架中重要的组成单元,也是粒度较粗的一个单元。 Module SCA 0.9 以后版本改成了 Composite ,这可能是 OSOA 组织为了更加明确化其含义而进行的一些命名更改。在 SCA 0.96 版本中, Module 具有了属性,这是为了能够更加方便地注入给 Component 属性值而做的调整。总之在 SCA 0.9 以及后续版本中做了一些改进,但是大体的框架没有发生变化,如图所表示:


module_over.JPG



它包括了

Component,Entry Point,External Service Wire 等元素,而这些元素互相之间有一定的关联,上图中没有画出 Wire ,因为 Wire 是专门针对 Service Reference 连接 Component 以及 Entry Point 连接到 Component 的描述,在上图中我已经画出了这几种元素之间的关系和连接,所以也就没有必要专门指出 Wire ,如果需要获得更多详细的信息,可以去 DW 或者 Dev2Dev 查看 SCA 规范。


描述
Module 是通过一个 XML 格式文件进行描述的,下面是该 XML 文件的一个大体格式:


<? xml version="1.0" encoding="ASCII" ?>

< module  xmlns =”http://www.osoa.org/xmlns/sca/0.9”

xmlns:v ="http://www.osoa.org/xmlns/sca/values/0.9"

name
="xs:NCName"   >

< entryPoint  name ="xs:NCName"  multiplicity ="0..1 or 1..1 or 0..n or 1..n" ? > *

< interface .interface-type />

< binding .binding-type uri ="xs:anyURI" /> +

< reference > wire-target-URI </ reference >

</ entryPoint >

< component  name ="xs:NCName" > *

< implementation .implementation-type />

< properties > ?

< v:property-name > property-value </ v:property-name > +

</ properties >

< references > ?

< v:reference-name > wire-target-URI </ v:reference-name > +

</ references >

</ component >

< externalService  name ="xs:NCName" > *

< interface .interface-type /> +

< binding .binding-type uri ="xs:anyURI" /> *

</ externalService >

< wire > *

< source .uri > wire-source-URI </ source.uri >

< target .uri > wire-target-URI </ target.uri >

</ wire >

</ module >

 

ComponentType Component


对于一个
Module 内部来说, Component 是绝对的主力。


要说起
Component ComponentType 就不得不说。


ComponentType
是一个描述 SCA 中服务的元素,它定义了服务以及服务的接口,以及服务对应的属性和服务引用。 ComponentType 是通过一个后缀名为 .componentType XML 文档来描述的,描述如下:


< componentType  xmlns ="http://www.osoa.org/xmlns/sca/0.9" >

< service  name ="MyValueService" >

< interface .java interface ="services.myvalue.MyValueService" />

</ service >

< reference  name ="customerService" >

< interface .java interface ="services.customer.CustomerService" />

</ reference >

< reference  name ="stockQuoteService" >

< interface .java interface ="services.stockquote.StockQuoteService" />

</ reference >

< property  name ="currency"  type ="xsd:string"  default ="USD" />

</ componentType >

 

服务的接口目前分为两种: Java interface WSDL ,这很好理解, Java interface 就不说了, WSDL 想必大家也都知道,通过它的描述我们可以得到一个很准确的接口。服务接口是一个可以扩展的属性,我们可以定义出其他不同的接口类型,当然,前提是所使用的 SCA 必须能识别并支持才行。


服务的属性和服务引用和
Spring 的属性以及引用类似。 ComponentType 描述的这些属性和引用,在 SCA Runtime 中实例化服务时,是需要注入的。属性一般对应的是一些简单类型,复杂类型只能是 SDO JAXB ;而引用则是需要对应的也是一个服务,在实例服务的时候,服务所引用的其他服务也需要一起实例化并注入。(注入的前提是该属性或者引用的 requied 属性为 true ,否则 SCA 就不会注入)。


ComponentType
只是描述性地说明一下服务的的接口以及属性,引用,但是具体该服务对应的实现以及属性的值和引用对应的服务是没有给出的。


Component
就是完成上述 ComponentType 没有完成的工作。


我们可以把
ComponentType 想象成一个 Class ,而 Component 是这个 Class 的一个 Instance

Component 描述了服务对应的实现,服务实现是通过 implement 元素指定的。这里要注意, SCA 中,实现是一个比较广的概念,不仅仅是一个简单的 Java 类实现, Component 所对应的实现和 ComponentType 中所定义的接口一样,是有不同类型的。目前来看, SCA 规范中给 implement 元素定义了只给出了一个 Java 实现: JavaImplement ,在 SCA 的一些其他扩展信息中,提出了 BEPL 实现以及 EJB 实现等。


同样,
Component 也描述了 ComponentType 中定义的属性以及引用所对应的值。 Component XML 描述是在 Module 的描述文件中的,下面给出一个片段:


< component  name ="xs:NCName" > *

< implementation .implementation-type />

< properties > ?

< v:property-name  override ="no or may or must" ?

modulePropertyName
="xs:NCName" ? >

property-value

</ v:property-name > +

</ properties >

< references > ?

< v:reference-name > wire-target-URI </ v:reference-name > +

</ references >

</ component >

 

对于我们刚才提到的服务引用,这里我想罗嗦几句。


服务引用并不是一个调用顺序或者调用关系的描述,它只是指出了服务之间的引用关系,并且能够动态注入而已。很多人认为,
SOA 中服务和服务之间是可以通过业务规则连接起来,然后可以逐个调用,像一个 Flow 一样,其实不然, SOA 更重要的是关注服务,比如 SCA 就很重视对服务的管理,以及将服务接口和实现解偶,服务和服务之间的连接也只是引用而已,并不是调用顺序。用过 Seebeyond (比较早的一个面向服务的框架,已经被 SUN 收购)的人都知道,真正去启动服务编排调用的还是 BEPL 。同样 SCA 中之所以提出了 Component BEPL 实现,也是出于对服务编排调用的考虑。

 

EntryPoint


Module
SCA 中是一个粒度较为粗的单元, Module Module 之间的交互是通过定义在 Module 内部的 Entry Point External Service 进行的,也就是说 Entry Point 是一个 Module 对外提供的接口,而 External Service 是一个 Module 对外访问的出口。


module2module.JPG

 

 

Entry Point 自身是只能定义自己的访问接口,但是真正的具体实现(比如一个 Java Class ),是通过它自身的 Reference 指定的。 Reference 指向的是一个 Component ,这就意味着,该 Entry Point 的调用是直接利用 Component 的实现来完成的。下面是 EntryPoint 的描述片段:


< entryPoint  name ="MyValueService" >

< interface .java interface ="services.myvalue.MyValueService" />

< binding .ws port ="http://www.myvalue.org/MyValueService#

wsdl.endpoint(MyValueService/MyValueServiceSOAP)"
/>

< reference > MyValueServiceComponent </ reference >

</ entryPoint >

 

而一个 Entry Point 既然是对外的接口,那么它就不能像我们访问一个普通 Java 类那么去访问了,所以在对外发布 Entry Point 是需要通过其他的一些辅助技术来完成,比如 Web Service JMS 等,问题在于如何确定该 Entry Point 所对应的这些辅助技术(应该说是某种协议)呢? SCA 规定,一个 Entry Point 需要指出它的 Binding ,利用 Binding 来确定该 Entry Point 具体是需要通过什么协议来进行发布的。

 

Binding


Binding
是一个可以扩展的元素,目前 SCA 0.9 中给出了两种 Binding: SCA, Web Service ,不过我们是可以对 Binding 进行扩展的,前提是所使用的 SCA 容器必须支持扩展的 Binding


一旦
Entry Point 指明了自己的 Binding 后, SCA 容器就应该根据它所指定的 Binding 类型对它进行对外发布。比如 Entry Point A 指定了一个 Web Service Binding ,那 SCA 就必须能将这个服务通过 Web Service 的实行发布出去(不要联想到 UDDI ,这里的发布只是说将这个 Entry Point 制作成一个 Web Service ,能让外界通过 Web Service 的访问方式访问到该 Entry Point )。具体 SCA 如何实现我们不得而知。

 

广告


本人的一个简单的
SCA Container 实现,可以在uxbalto.googlepages.com得到 相关信息,不过页面没怎么加,东西少得可怜。
 

External Service


既然理解了
Binding ,那理解 External Service 就容易许多了。先看看描述片段:


< externalService  name ="CustomerService" >

< interface .java interface ="services.customer.CustomerService" />

< binding .sca />

</ externalService >

< externalService  name ="StockQuoteService" >

< interface .java interface ="services.stockquote.StockQuoteService" />

< binding .ws port ="http://www.stockquote.org/StockQuoteService#

wsdl.endpoint(StockQuoteService/StockQuoteServiceSOAP)"
/>

</ externalService >

 

External Service Entry Point 类似,只是一个是对外发布,一个是要去远程访问而已。我们一旦指明了 External Service Binding 后,在访问该 External Service 提供的服务时,我们就会通过指定 Binding 类型对远程发布的服务进行访问。


其实不难看出,由于
SCA Module Module 之间的交互需要通过这么一种远程发布和访问的方式,可以认为 Entry Point External Service 之间是被调用和调用的关系, Entry Point 发布出去的服务,一般都是由 External Service 访问的。当然, External Service 不一定非要去访问 SCA 容器中的东西,单独的非 SCA 管理的 Web Service 或者其他什么也可以利用 External Service 去访问的。

 

结束语


SCA
规范中还有很多没有在文中提起,比如异步调用,服务的 Scope,SubSystem 等,我会在以后的文章中再和大家一起讨论。


评论

# re: 浅谈SCA  回复  更多评论   

2006-10-06 11:55 by BlueDavy
SCA继承了OSGi的规范的模块化的设计方法,同时为企业应用而增加了屏蔽诸如远程调用这些的具体的技术难度的东西,再加上它继承了SOA的跨语言的特性,使得在企业应用领域它的优势还是很明显的。
SCA的规范的模块化至少对Java界是会有影响的,也许JCP会加快完善Java Module System的相关规范并付诸实现。

# re: 浅谈SCA  回复  更多评论   

2006-10-06 16:13 by pear
真的不知这些东西是用来解决什么问题的。

搂主: 能不能给我推荐一个主要用Web Service实现的实际系统?

现在感觉技术学了,却不知用来干什么,有点迷盲。。呵呵

# re: 浅谈SCA  回复  更多评论   

2006-10-06 17:31 by BlueDavy
最重要是用来实现标准化,子系统由模块组成,模块由组件构成,组件对外暴露或引用服务,这些本来就是系统设计的基本准则,只是SCA希望将这样的设计方法标准化,同时屏蔽一些技术难度细节的东西,使得开发人员能够更加专注于业务的实现.....just so so..

# re: 浅谈SCA  回复  更多评论   

2006-10-07 11:54 by Dart
TO pear:

关于“主要用Web Service实现的实际系统”我不太明白是什么意思,我猜你是想知道WS主要应用吧?如果是那样我认为你可以好好看看Developworks上的文章,对你有帮助

另外,我的这篇文章还是写得太虚,没有给大家比较直观的认识。等我完成了我的SCA容器(Balto)后一定会将官方的BigBank完成,展示一下SCA的战斗力。

技术不是游戏,技术不是拿来玩的,技术的存在一定是要解决当前的存在的生产生活问题的。千万不要认为技术学了没用,学了就一定有用;但是也不要盲目追捧技术

TO BlueDavy:

SCA目前还不完善,很难说以后会是什么样,而且它存在的目的其实很明确:在现在天天呼唤SOA的这样一个历史时期中,几个大厂商推标准,然后其他公司追赶,最后设计成,为以这几家大公司现有产品整合为主的框架也说不定。

SCA是否真能到达“设计开发SOA化”这就很难说了,这需要设计开发人员自身对SOA的理解,不过让SCA达到"设计标准化"还是容易的。

我对OSGi不熟悉,不过由于长期从事Eclipse Plugins开发,多少知道一些。我觉得OSGi中那中“既插既拔”的module管理思路和SCA中的以Module为主要单元的设计还不太一样,OSGi更偏重于对接入模块的动态管理,并不整合它们;SCA则是更加偏重对Module(Composite)之间的交互。

有不对的地方还请多多指教

# re: 浅谈SCA  回复  更多评论   

2006-10-08 09:59 by BlueDavy
@Dart
为什么我会说SCA是OSGi在企业应用的一种延伸,原因就在于SCA和OSGi都有一个非常核心的东西,就是将模块设计、开发、部署标准化,在这方面SCA和OSGi其实基本是一致的,所以在Module之间的交互上,两者的原理也是相同的,都是一种服务交互的机制,只是表现上SCA有所不同,因为SCA的制定目标是企业应用,所以它考虑到了远程模块交互上的问题,这个强于OSGi,所以我觉得SCA很像是OSGi在企业应用界的延伸。
非常有兴趣和你多交流,我的MSN:
BlueDavy@hotmail.com

# re: 浅谈SCA  回复  更多评论   

2007-09-02 20:56 by jackyrong
由于本人公司里存在不少遗留系统,有用java,php,asp,asp.net的四类系统,而且还有不少和合作伙伴的接口程序(之前都是用HTTP来交换数据的),现在而且本人的硕士毕业
论文设计也是做SOA方面的,但目前遇到了一个难题,那就是到底SOA应该如何从开始进行架构设计,如何提炼业务,并且如何将SOA的思想应用到公司的实际系统中,我目前只整理了一下,感觉可以用到SCA/SDO/BPEL/ESB这些东西,ESB打算用MULE的开源,
SCA/SDO打算用APACHE的TUSCANY,但不知道有什么好的架构设计的方法呢?

# re: 浅谈SCA  回复  更多评论   

2007-09-03 15:14 by Dart
to jackyrong:

从什么角度入手去开发一个SOA构架的应用的确是个难题。
我记得IBM的一次SOA会议上提到过,其实做SOA的可以从多个方面入手,一共有好几个方面,我只记得以下2点:
1.从数据入手

基本上就是有点像数据整合的感觉——将异构应用的数据进行整合同步。目前国
内有不少公司做这样的产品,比如东方通的TI在数据同步方面就很强。

2.从连接入手
将一些应用的接口进行抽取,然后利用SCA的标准进行封装(或者直接利用WebServices进行封装),对外发布后提供给其他应用调用。

还有就是你所提到使用ESB,这点上我觉得其实如果你使用SCA来做的话,ESB是不是可以取消掉呢?

上面是我一些不成熟的看法,希望对你有所帮助

# re: 浅谈SCA  回复  更多评论   

2007-10-30 16:40 by yihong
我有这么几个问题想问下您:
(1)Component是不是不能提供服务,是不是必须通过Composite向外提供服务?Composite是SCA里面提供服务的最小单元么,它的上一级是否是Domain,那domain是不是也是一个服务,只是服务粒度比较大而已?
(2)Composite可以被发布为WEB service,那么在SCA里面WEB service处于一个什么样的地位,它属于“非SCA组件”么,在SCA规范里面WEB service能被直接绑定,直接调用么?
(3)在SOA架构里面,ESB是一个非常重要的概念。SCA作为SOA的一个规范,ESB是怎么实现的。我现在所了解的是IBM的WID中可以通过构建Mediation module(在SCA 0.9里面好像module对应现在的Composite)来提供ESB服务。
(4)在SCA里面好像组件能打包,是不是只有Domian才能打包呢?打包有什么作用,Contribution到底是一个什么样的东西?
(5)SOA的概念层次从下到上一般分为:操作系统层、组件层、服务层、业务流程层、和表示层(IBM好像就是这么分的)。具体到SCA,它分别对应于SCA的什么呢?看过LZ写的文章,依我理解是不是“组件层”对应Component,“服务层”对应Composite,“业务流程”对应Domain呢?
(6)LZ的文章把Composite分为三层,是不是TOP-Composite对应业务流程?TOP-Composite与Domain就服务粒度上有什么不同呢?
(7)这个问题还是关于WEB service的,现在很多文章,还有基本所有的工具包括IBM,在实现SOA的时候基本都是用WEB service。虽然IBM声称它的产品支持SCA1.0,但是在实现的时候都需要把服务发布为WEB service。既然SOA可以用WEB service来实现,而SCA又是SOA的一个实现规范,那么SCA和WEB service的关系是什么样的?
(8)我经常看到好多文章题目是“基于SOA的、、、、实现”,还有的是“基于SCA的、、、实现”。后面的提法是不是有问题,比如“基于SCA的物流信息共享平台的实现”。因为从概念上讲,SCA只是一个实现而已.


还有,LZ既然从SCA0.9规范就开始研究,为什么SCA1.0出来后,为什么就不写了呢。LZ的文章道理还是讲得很透彻的。

# re: 浅谈SCA  回复  更多评论   

2007-10-30 16:45 by yihong
不好意思,第5和第6是从其他的一篇文章看过来的,发的时候不小心就发上去了。感觉您的BLOG今年就没更新了,呵呵
如有可能,能否还说说Spring在SCA中的实现

# re: 浅谈SCA  回复  更多评论   

2007-10-31 13:28 by Dart
To yihong:

我很久没有更新blog了,我的SCA Container也已经1年没有更新代码了。我也放松了对技术方面的学习,这可能就是我这个人最大的弱点吧。不过谢谢你的提醒,我想我会重新拾起这些久违的东西。


我胡乱回答一下你的问题:
1:所谓服务就是提供一定功能的实体,提供服务的实体我们可以称之为服务提供者,是这样吧?SCA中,将模型划分成几个不同粒度,其实我觉得都可以看成服务提供者,但是他们的粒度不一样。我觉得Component可能是最小的服务粒度。在0.9中,对外提供服务的话需要使用Composite。你所说的domain应该是从0.96后的版本加入的吧,我觉得它也是服务提供者。SCA把这些同为服务提供者的模型分正这几类粒度,可能是从SOA设计角色考虑出发的——设计人员和开发人员考虑的角度是不一样的。
2:WebService在sca中被称为一个binding,它利用协议绑定的形式进行描述,而进行访问的时候,我们根本就不需要知道它是不是web服务,因为我们都是通过domain去查找出服务代理,然后调用方法的。那在调用过程中,具体如何调用(WebService?JMS?),服务消费者(调用服务的人)是不知道的。
3:你提到了IBM的Mediation module。我也看过那篇文章,不是很懂。我觉得SCA本身就具备ESB的一些功能,它们两者之间有很懂相似的地方。有时候我会把SCA看成一个ESB的实现。如果要加入已有的ESB的话,我想可以通过扩展SCA的Binding来做到这一点吧。
4:对于组件打包这个问题我一点都不知道了,不能回答你了。
5:我觉得SCA应该是囊括了组件层、服务层、业务流程层。组件层可以看成已经发布的Domain或者一些其他的可以利用SCA访问的可用功能组件;服务层就不说了(服务无处不在);业务流程层应该说是BPEL吧,那应该在SCA对应的是BPEL implement 才对,所以说这些所谓“层”对应到SCA模型是不能直接连线的。其实可以这么看,服务层和组建层做为原子业务功能的提供层,业务流程层则是组合这些原子功能的地方。
7:SCA是一种设计,开发的模型指导方案,WebService可以看成组成SCA的一个技术部分。
8:这个我倒无所谓,只是需要明确:SOA是方法论,SCA是一种技术规范。

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


网站导航: