SOA的实现可以分为三种截然不同的方法,除了基于Web Service和WS-*标准的、被称为正统SOA方法之外,还有其他的两种方法涌现出来……
面向服务架构(Service-oriented architecture, SOA)的实现可以分为三种截然不同的开发方法,iTKO公司的首席科学家和创始人John Michelsen说,该公司是专注于面向服务架构的测试产品厂商。
除了基于Web Service和WS-*标准的、被称为正统SOA方法之外,他还看到了其他的两种方法涌现出来,企业级别的利用已有的消息中间件而不是使用Web Service的实现和部门级别的使用REST和Web2.0的实验性的实现。
“我看到人们采用了三种不同的方式来实现SOA并且三者都各有优点,”Michelsen说,他是中立的,由于所有的方法都需要测试工具,他从1999年开始就进行了该测试工具的开发,那时他的工作焦点是被称为组合应用测试领域。在2003年之后,他的注意力将开始固定到了SOA上。
Michelsen说他目前观察到的主要趋势是SOA正在超出Web Service的范畴。
“很多人说让我们SOA一把,接着他们立即联想到Web service,接着从那里继续联想到WS标准,”他说。“所以SOA基本上成为了WS-*类型的Web service的别名了。这种方法是建立一个优秀的核心、定义WS-*的标准、以策略开始、引入注册。这就是Gartner规定的SOA的方法。”
虽然他发现有相当数量的正统的SOA方法,但是其他的替代方法却越来越多的抓住了他的注意力。
“这里有越来越多的趋势表明SOA和Web service并不是互相等同的,”Michelsen说。“SOA是一种架构的模式,你可以使用各种方法来做到。现在有很多SOA游离于Web Service和WS-*标准之外。”
大企业似乎更加倾向于一些主张对已有的技术进行重用的SOA方法,即使它不是最先进的,比如CORBA技术。
“我所见过的在大企业内的很多大型的、最有趣的SOA环境完全不是基于Web service,”Michelsen说。“它们可能是基于CORBA,或者基于ESB。它们也可能是在标准的应用服务器上构建的定制的框架。”
Michelsen主张保持现有的IT架构是SOA哲学中的关键。
“SOA绝不是进行革命,因为根据它的本质它是对现有环境的封装和扩展,所以你不能抛弃旧的东西,引入新的东西,结果看起来SOA是很容易,”他争论。
对于那些已经对像IBM MQ系列中间件之类的东西进行了长期投资的公司,他建议结合已有的系统,从中转型到面向服务的方法。
“我们假设你的关键应用大部分是Tibco或者它们已经运行在了IBM MQ上。我们从这个地方开始改造,并且从这里开始基于服务。我喜欢这样的方法,”Michelson说。“假如某公司已经非常好的使用了一项分布式中间件技术,那么理所当然的继续使用它,并且使用该技术来建立服务。如果他们已经有了使用ESB的经验,并且他们需要做的是重新考虑软件的设计来获得更多的基于服务,但是要使用相同的中间件技术,让我们做我们擅长的工作,并让整个过程慢慢的演化,而不是进行一次革命。”
虽然他说基于现有的技术和经验构建是他最喜欢的SOA方法,但是他还是看到了一些让人启发的工作是通过前沿的Web2.0和REST来完成的。尽管他怀疑Web2.0/REST方法如何进行扩展,但是他还是将其视为部门级IT开始SOA旅程的好方法。
“现在有很多ground-up的SOA是通过Web2.0和REST来完成的,”他说。“我认为它在部门级别站稳了脚跟。我相信当REST用户试图推广到企业范围的时候他们将会遇到一些挑战。有一个快速应用开发环境是很好的,尤其是你在建立前端的时候拥有了和不同供应商的服务协作的能力。Web2.0/REST方法是非常方便的。”
Michelson说,从一个崇尚监管的测试工具开发人员的角度,他还在观察当Web2.0和REST从部门推广到企业范围的时候,基于标准的监管技术和实践将如何与Web2.0和REST进行协作。
“在企业范围中的重用中,在服务侧完全使用REST而引入的混乱(chaos)程度可能很危险,”他警告。“我还没有观察有人在分布式、企业范围内使用REST。我感觉到这是因为它并没有提供真正的方法来标准化。”
但是如果开发人员没有走过头,REST和Web 2.0是在部门级别“很好的方法”,他说,并且他发现采用REST非常有趣。
“使用REST的人数不断膨胀,”他说。“会有很多Web2.0/REST类型的产品不断推出的,像Google的平台Rubyon Rails。”