站内搜索: 请输入搜索关键词

当前页面: 开发资料首页J2EE 专题案例研究:从独立网站和B2B接口到SOA

案例研究:从独立网站和B2B接口到SOA

摘要: 以前Sprint公司每次都使用一次性方法来连接部门,客户和合作伙伴到它的主机系统。 四年前,这个电信提供商开始尝试一种更模块化的方法,然后在面向服务的架构中使用这些可重用的组件。 Sprint公司发现,当集成或者启动新项目的时候,使用SOA可以避免大量重复开发。
Sprint公司运用面向服务的架构合理化底层结构

摘要
以前Sprint公司每次都使用一次性方法来连接部门,客户和合作伙伴到它的主机系统。 四年前,这个电信提供商开始尝试一种更模块化的方法,然后在面向服务的架构中使用这些可重用的组件。 Sprint公司发现,当集成或者启动新项目的时候,使用SOA可以避免大量重复开发。

版权声明:任何获得Matrix授权的网站,转载时请务必保留以下作者信息和链接
作者:lennoncao
原文:http://www.javaworld.com/javaworld/jw-09-2005/jw-0912-idgns-soa.html
译文:http://www.matrix.org.cn/resource/article/44/44210_B2B+SOA.html
关键字:B2B;SOA

早在四年前,Sprint的IT员工已经朝着面向服务的架构前进了。 只是他们还不知道而已。

当开发人员最初把Sprint的后端系统暴露为可重用的组件的时候,Web服务的概念仍然还没有被很大程度的验证。 以前,他们通过一系列的独立站点和B2B的接口来连接公司的部门,客户和合作伙伴到他们的主机系统。 作为一个有着超过10,000个公司的客户群体的全美最大电信提供商之一,这样一次性的方法无论如何是不能支撑很长时间的。

四年前,一个本地的电话服务业务部门开始开发一些Java应用,这些应用包括一些基本功能,如登陆和密码重置,以及一些客户任务,如服务订单和账号更新。 在认识到模块方法的好处后,其他业务部门迅速参照着做。 不幸的是,这样导致了多重的,并行的Web服务开发工作。 Sprint的开发人员重复的创建了同样的模块,浪费了开发的时间和费用。

"我们有大量不同的平台和技术,因为为了满足业务和客户的需求,每一个设计都得到了发展," Sprint业务服务(SBS)部门企业中心的Web服务程序经理Edmund Vazquez 回想道。 "我们常常会规划核心功能。 而不鼓励重用核心底层架构的组件。"

为了合理化Web服务的部署,SBS决定创建一个统一的架构,这个架构提供识别,开发和管理服务。 一个坚实的SOA基础将让SBS把服务分解成可重用的组件,这样将减少整个开发的工作量,尽管这样也需要对业务需求和服务需求有清晰的认识。

为了管理SOA和上面开发的服务,SBS创立了两个独立的IT部门。 一个关注整个架构和策略,另一个着重服务自身的开发和集成。 这样保证架构维护和应用的一致性,而开发团队只是关心他们自己的具体业务逻辑。

当然,转变不是一夜完成的。 按照Vazquez的说法, 这不用这么做。 "采用SOA最好的方法是采用,实现和部署,也可以这样增量迭代进行,只要你做好前期规划,"他说。

可管理性的建立

架构上,SBS定义了三种服务: 原子,聚合和组合服务。 原子服务可以暴露一个单一的API,而且通常是一个自然事务。 聚合服务可以包含有调用顺序的原子服务,就像一个Java类调用其他类一样。 另外,组合服务则需要编制和编排。

一个组合Web服务实现了一个工作流程,可以包括多个原子或聚合Web服务,其中包含管理数据流程。 在一些情况下,SBS用Vitria EAI(企业应用集成)平台在Web服务层次上来实现组合服务流程, Vazquez 说。. B2B部署中,SBS也用BPEL(业务流程执行语言)编制服务。

现在回顾起来,Vazuez说实行原子路线是最佳的选择,即使因为时间都花费在把功能分解成基本的组件上,而导致初始开发时间变得更长。 这样做可以让开发人员创建更多的可重用组件,当清楚整个顺序的服务是可重用的时候,能够轻松的构造聚合和组合组件。

相比较而言,Vazquez回想起早期的一些Web服务由于太过于特定,导致没有其他人能够使用它们。 "它们在技术上叫Web服务,实际上只是一些应用而已,"他说。

对于服务之间的消息传递,SBS依靠基于Infravio公司的X-broker平台的WSM(Web服务管理器)来实现,它可以处理原子和聚合服务,还可以提供Web服务注册。

SBS用EJB封装器把主机应用封装成"虚拟服务",使用SOAP,WSDL和XML Schema暴露应用的功能。 这样表示满足两点需求: 当提供给贸易伙伴一个基于标准的方法来使用服务时,它可以保障EJB内部业务逻辑的私密性,Vazquez 说。

因为SBS服务供应商和客户使用了更广泛的技术,系统支持几种数据交换标准。 扁平文本文件和基本的XML是最常用的选择。

"我们对特殊类型的领域使用特殊的XML标准,例如TML,eTom,ngOSS以及其他被电信行业协会开发的标准,"Vazquez说。 "在所有标准中,这儿最大的挑战是在贸易伙伴之间标准的采用率。"

Vazquez解释,在电信行业中,对XML特殊扩展是普遍的,因为客户数据和语音沟通经常会横跨多个网络和服务提供商。 "但是我们不能在定义标准企业XML Schema方面做的太多,"他补充说,功能的多样性和客户的差异性使得开发这样的XML Schema标准变得太笨重。

标准和实践

"因为SBS有一个世界级的IT服务研发团队,他们积极的研究和监控最新标准,"Vazuez说,"在一些情况下,我们直接控制我们的集成商负责保障我们的互操作性。" 原因是复杂的: 越来越多的类似WS-*的标准被提出并批准,组织面临逐渐增长的开发负担,以及与外部用户兼容的更大风险。

举例来说,SBS使用WSDL1.1,因为这是Infravio平台支持的,相对与WSDL2.0,Infravio更愿意支持它,因为"WS-I组织对它做了更多的兼容性测试,"Vazquez说。 "目前我们真正关注的标准仅仅是SOAP,WSDL,WS-Interoperability和WS-Security,"他补充说,这些才是广泛被应用和采用的技术。

因为厂商对标准解释的差异性,以及随着时间的推移,厂商将可能对支持的标准有差异,Vazquez预计维护贸易伙伴间的互操作性将变得更困难,这样将导致标准的采用更保守了。 在必要的时候,他说,SBS将创建多个服务的版本,每一个都支持不同的标准,而不是尝试开发能够支持多个标准的单一服务。 否则,他说,为了确保多种技术之间的互操作性而带来的复杂性,将否定基于组件的Web服务平台所带来的好处。 同样的,为了保证开发工作的易处理,SBS尝试用Java开发Web服务,以及用EJB开发遗留系统的封装器,以维护J2W(Java到Windows)的兼容。

因为需要强大的互操作性,公司通常使用BEA WebLogic作为EJB封装器的应用服务器,但是由于特殊的应用或事务的组合,在一些区域也使用IBM WebSphere应用服务器。 "我们的想法是用Web服务层来隔离底层技术平台,不管它是WebLogic,WebSphere还是主机系统,"Vazquez说。

Web服务的使用可以帮助减少劳动强度以及外部客户访问SBS系统的沮丧。 在使用WSM之前,SBS不得不重新配置每一个受影响的服务器的防火墙,以允许对每一个独立客户的访问。 使用WSM后,Vazquez说,直接被外部客户访问的方式被去除了,因为这样需要配置每一个服务的防火墙。 相反,SBS限制用户访问在DMZ中的代理服务,然后由代理服务再调用在SBS网络中所需的服务。

长期的平台

当Sprint公司认识到需要一个最新Web服务的统一架构时,它已经有了SOA需求的关键部分: 紧密的集成业务逻辑和应用开发。 在历史上,Sprint公司是一个面向过程的公司,Vazquez说,业务开发团队已经习惯指定他们自己的应用需求,他们常常坐在开发人员身边一起工作。

"我们有四个过程设计工具,"Vazquez说,Sprint公司已经有了需要有效部署SOA的过程导向。 他相信,当SOA在两年前开始的时候, Sprint公司已经为快速的增长做好了准备。

今天,SOA让Sprint以两种方式使用服务: 直接或通过一个外部基于Web的接口给客户使用,这并不需要客户有集成他们自己的Web服务的能力。 依照SBS的管理服务架构师Jeff Lentz的说法,他们直接使用Web服务,客户将获得最大利益,因为这种方法允许他们在自己的应用中封装Sprint的服务。 这样简化了数据集成,也免去了员工们学习新接口和处理方法的必要,同样如果他们通过网站访问服务就必须学习。 因为大多数客户仅仅时刚开始开发他们自己的Web服务平台,而Web接口就意味着Sprint公司获得了直接的投资回报。

更多而言,Sprint在实施SOA方面的深谋远虑将帮助它迎接下一个更大的挑战。 Sprint和它最近收购的子公司的Nextel的联合, "更好的事情是内部服务的使用能够加速我们合并中遗留系统的迁移,"公司Web Presence总监 Gayle Sweeney说。

SOA方法的灵活性意味着SBS不再需要每次都重复开发,这确实是一个在集成或者启动新项目的挑战。 在企业IT混乱无序的世界中,如果Vazquez能够肯定一件事情,那就是他将没有这些缺点。 "在一个拥有70,000员工的企业里,我们总是在发现新的应用,"他说。
↑返回目录
前一篇: 为何不让SOA变得简单?
后一篇: Servlet 2.5的新特征