引导企业客户采用SOA.docx
- 文档编号:8027373
- 上传时间:2023-01-28
- 格式:DOCX
- 页数:12
- 大小:30.75KB
引导企业客户采用SOA.docx
《引导企业客户采用SOA.docx》由会员分享,可在线阅读,更多相关《引导企业客户采用SOA.docx(12页珍藏版)》请在冰豆网上搜索。
引导企业客户采用SOA
尽管SOA(面向服务的体系结构)的概念进入中国已有一段时间,但国内用户至今对SOA的认识仍不够清晰,导致SOA的市场需求并不明朗。
就目前国内的现状来看,对于SOA,更多的企业仍处于观望的态度,有很多的疑虑。
据调查,表示对SOA关注的企业用户为数不多,其中有15.9%的流通行业,而在制造行业仅有8.6%。
SOA推广应用认识的误区
国内SOA应用的这一尴尬局面,很大程度上是由于认识上的误区影响了SOA的推广应用。
认识的误区主要表现在三方面:
首先,认为SOA是万能的,可以应用于所有的场合。
其实情况并非如此。
SOA并不能代替已经在公司内部存在的那些被良好集成的应用系统。
通过合理的部署,SOA系统可以改善原有的IT系统,使得原有的那些应用系统更具有柔性。
通常情况下,复杂的IT构架对SOA的需求更加迫切,并且SOA需要与外部复杂的IT环境交互,并快速地应对频繁发生的业务变化。
其次,认为构建了SOA架构,就不再需要应用整合技术。
其实,SOA并非一蹴而就。
虽然SOA使系统整合更容易,但是企业仍然需要核心的整合技术,例如转换、挖掘、流程整合、适配器等等,使它们成为架构和规划中的组成部分。
企业先要对需求进行一次全面的评估——不仅仅局限于IT,而是面向整个企业。
实现SOA可能需要耗费几年的时间。
第三,认为构建了SOA,就不需要IT人员的参与,业务人员照样可以把服务连接成新的业务流程。
这种想法没有考虑服务的实现仍得由人编写实施服务的软件,系统也仍需要有经验的IT专业人员把业务工作流转换成顾及企业级性能、安全、资源使用和可靠性的具体实施方案。
其实这些误区的产生是由于对SOA的三个应用层面理解的偏差所致。
譬如开发者大多对如何建立SOA应用感兴趣,因此他们关注更多的是SOA中应用程序的体系架构方面。
而WebSerivces管理工具的卖主一般认为SOA主要是有关基础组件体系结构的。
同样,用户群体会认为SOA是用于企业业务应用结构的。
对于国内的用户来讲,接受SOA,难的并不是技术,而是SOA理念的灌输,以及对企业文化的重新改造。
SOA与传统的应用体系结构不同,SOA更多地是针对变化而设计的,基于SOA的系统能具备更大的弹性,而且能够实时地根据企业的变化,调整自己的结构,以满足企业变化的需求。
SOA的一个中心思想就是让企业应用能够彻底摆脱面向技术的解决方案的束缚,以轻松应对企业的商业服务变化和发展的需要。
中小企业的SOA
要走出应用的误区,SOA的构建无疑显得异常重要。
通过以服务为中心而不是以应用为中心来组织企业IT建设,SOA为企业提供了一系列关键的好处:
能提高生产力,提高对业务和IT的灵活性和响应速度,允许IT更快地提供服务并更好地适应业务的需求,以及允许业务更快地响应并提供更好的用户体验。
但怎样才能成功实施SOA呢?
从用户的角度看,SOA有助于企业实现资产重用、灵活的管理和更快的开发与部署。
在当今的业务环境中,变化无时无刻不在,快速响应客户需求、应对市场机遇和外部威胁的敏捷性比以往任何时候都更显重要。
SOA能帮助用户随需应变,代表了企业信息化的最高境界。
当然,也会有很多人认为SOA只是大型企业才会用到的一种架构和方法。
其实不然,SOA不只是大企业所独享的,中小企业也一样能拥有。
因为中小企业也是生态链中的一部分,他们并不需要整合自己,而是要把自己建立在一个开放的平台上,以帮助自己能参与到大的生态商业系统中。
那么,企业应该如何构建SOA呢?
其实,实施SOA需要企业改变以往对待IT系统的观念,学会从新的角度看待IT系统。
SOA不仅是技术问题,更是企业战略和业务方面的问题。
因此,企业要将不同的系统、不同的应用统一到一个大的框架之内,企业基础平台的选择就显得尤为关键。
平台选择得好,企业可以很方便地实现应用系统的集成,达到事半功倍的效果。
企业在选择基础平台时,一定要关注平台所支持的标准及所拥有的功能。
因此,尽管SOA不是一剂灵丹妙药,也不适合解决所有的问题,SOA真正在国内的大规模应用普及还需要克服众多障碍,但是,我们相信随着SOA的应用得到了正确的认识,SOA成为软件业的下一个大趋势将是不争的事实。
SOA有哪些基本原则?
了解SOA是为了解决什么样的问题,我们先来了解一下SOA有哪些基本原则。
粗粒度
在SOA中服务粒度有两种相关的意思,即服务是如何实现的,服务使用和返回了多少数据或多少消息。
细粒度服务执行了最小的功能,发送和接收少量的数据。
粗粒度服务执行了较大的业务功能,并交换了更多的数据。
原则:
细粒度服务是供粗粒度服务或组合服务使用的,而不是由终端应用直接使用的。
如果应用是使用细粒度服务建立的,则应用将不得不调用网络上多个服务,并且发生在每个服务上的数据量较少,因而会对对系统整体性带来影响。
所以,粗粒度服务的用户不能直接调用他所使用的细粒度服务。
同时,由于粗粒度服务可能使用多个细粒度服务,因此它们不能提供粒度级的安全和访问控制。
松散耦合
松耦合的系统特点是灵活,而应用到SOA中的目的就是将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。
服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。
这是服务实现能够在完全不影响服务使用者的情况下进行修改。
大多数松散耦合方法都依靠基于服务接口的消息。
基于消息的接口能够兼容多种传输方式(如HTTP、JMS、TCP/IP、MOM等)。
基于消息的接口可以采用同步和异步协议实现。
可重用部件/服务
如果完全按照可重用的原则设计服务,SOA将可以使应用变得更为灵活。
可重用服务采用通用格式提供重要的业务功能,为开发人员节约了大量时间。
设计可重用服务应该是与数据库设计或通用数据建模类似的最有价值的工作。
基于标准
WebService是目前实现SOA应用的一项基本的,适用的技术,它为服务的访问提供了一个被广泛接受的开放标准。
JBI(JSR208)是SUN推出的基于Java的SOA标准,随着在JSR208中被定义,它也成为了把服务容器组装为合成应用的标准。
ServiceComponentArchitecture(SCA)和ServiceDataObjects(SDOs)标准是IBM和BEA所推出的SOA标准,并在ApacheGroup建立了ApacheTuscany项目。
在我看来,标准之争并不是关键所在,但就JBI和SCA/SDO标准而言,JBI的应用范围更严格,可能最终会成为更大的标准中的一部分Java实现。
SOA面临什么样的问题?
﹡繁杂的应用和协议
﹡繁变化的服务需求
﹡管理
﹡监控
﹡网络瓶颈
﹡标准的缺失
﹡困难的跨团队变更管理
﹡这些问题都比较好理解,也不是只有采用SOA才能解决问题的。
但是作为典型的SOA应用,以上的情况都是必须面对的,也是SOA系统函待解决的。
SOA的应用场景是怎样的?
适用场景
1.集成成本持续增长,而并未因为可提供真正投资回报(ROI)的新业务机会而得到缓解。
2.兼并和收购是企业扩大市场份额和获得新发展机会的业务模式的核心。
3.解决方案要求对来自异构系统和编程模型的业务功能进行集成。
4.业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。
5.全球经济的影响要求企业事半功倍地开展业务,而且有必要依赖业务合作伙伴提供非核心业务功能。
6.就提高收益而言,与业务合作伙伴协作的效率对企业十分关键。
7.企业业务资产的价值在减少,因为不能对其进行评估,以在最初用途之外的其他地方使用。
8.企业员工的效率出现了问题,因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。
9.企业的业务充满了机会型的业务工作。
10.企业从头开始开发新应用程序。
(SOA应当作为定位将来的新应用程序的缺省架构模式,当然,业务条件有其他限制时除外。
)
不适用场景
1.企业只将小部分IT预算用于集成项目。
2.企业的大部分流程都是手动的或以文档为中心的,自动化的机会几乎为零。
3.企业的大部分应用程序开发都使用相同的编程模型。
4.企业的操作由一个或两个客户关系管理(CRM)和企业资源规划(ERP)应用程序管理,几乎没有集成要求。
5.企业的现有技能库与实现支持SOA的基础结构所需的技能库之间存在重大差异。
6.未发现可从SOA提供的功能受益的业务需求或机会。
7.新业务服务的可用性将对现有的收益流带来负面影响。
8.企业依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。
9.企业的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。
应用分析:
SOA项目成功实施的十个步骤
对于每一个面向服务的架构(SOA)的成功故事,在某个部署阶段都会有一个陷入困境的SOA项目。
对于每一个面向服务的架构(SOA)的成功故事,在某个部署阶段都会有一个陷入困境的SOA项目。
人们普遍认可的一个理论是,50%的IT项目是不成功的,这突出了SOA项目的成功与挑战。
当然,这会让人们对着手实施SOA战略产生极大的畏惧心理。
在企业高级主管和IT更加密切地使技术与业务需求保持一致的基础上,SOA仍是他们的首要议事日程。
SOA迅速消除了与IT项目相关的大量失败统计,已经显示了有据可查的投资回报率,业已证实的SOA的成功使全球SOA商机增长到603亿美元。
这与2005年估计为346亿美元的市场潜力相比,增长了75%。
此外,预计2008年SOA市场继续攀升54%,达到1430亿美元(Gartner)。
SOA战略能够快速实现投资回报,这将推动该市场继续进一步增长。
事实上,快速实现投资回报的商机之多可能达到惊人的地步。
例如,许多组织未意识到在独立的部门和应用中存在大量的重复流程,以及这些重复的流程使他们付出了多少成本。
当您审查由于多余职能部门和重复工作所造成的成本和收入损失时,您就开始察觉到集中服务而不是管理多个存在竞争关系的重叠职能部门所具有的价值。
有一些观望者可能会问:
“以前的方法都失败了,SOA怎么能够成功?
”以及“我如何避免变成别人的统计数据?
”
这些问题很有说服力。
简言之,之所以能够实现成功的SOA战略,是因为标准、最佳实践和管理模式最终走向成熟,使重用变得切实可行。
根据定义,SOA是一种架构,同时也是一种可帮助应对紧迫业务挑战的IT方法。
尽管每个企业都有着不同的业务需求,每个行业都面临自己独有的挑战,但有一些共同的问题导致了SOA的失败。
最常见的10个问题是:
1.确保高级主管的支持:
在说明将如何确保公司的SOA取得成功之前,要准备好演示其它企业的SOA征程的成功与失败,并清楚地表明您将如何效仿经过验证的实践,以及如何避免陷阱。
2.调整阵容:
消除障碍并让高管支持SOA的难题在于调整您的组织采用新的工作和思考方式。
要做到这一点,需要为每个业务环节识别和招募至关重要的拥护者,他们将支持甚至极力宣传在SOA问题上所做的努力。
3.统一视图:
消除目前分散在企业的对信息的多个视图,以便仅看到对业务的单一、全面和一致的视图。
4.重用等于重新有用:
识别并维护现有Web服务的存储库,以避免重复。
您可能会对企业不同部门已经做了如此多的工作而感到惊讶。
5.整合孤岛:
尽管从理论上来看,目前许多IT机构都在寻求整合,避免多余,实现现有IT投资价值的最大化,但实际上,大量工作依然放在努力维护共存的不同IT系统上,而非用于整合。
捡芝麻而丢西瓜的做法对于SOA毫无用处。
6.着眼全局:
请记住,SOA是一种体系结构,而不是拙劣地捆绑到一起需要强力配合的单点产品。
真正的SOA采用基于开放标准的方法构建,需要经历四个战略阶段:
建模、组装、部署和管理。
7.借助企业服务总线:
ESB提供可用于整合SOA内的服务所需的许多连接基础设施。
SOA和ESB配套使用,有助于减少复杂的接口数,使您能够专注于核心业务问题,而不是维护IT基础设施。
8.循序渐进:
当在整个企业部署SOA的思想占有压倒性的优势时,要记住,最佳方法是在部署过程中不断测试并改进——首先从部门开始,然后慢慢扩展到整个企业,以便识别问题,并向存储库中添加最佳实践。
9.避免权宜之计:
切记,您不仅仅是为几天或今年构建SOA。
SOA是一种调整IT与业务需求保持一致的企业全局方法,必须支持当前以及将来的业务需求。
例如,一定要包括对移动和无线设备的支持,以及确保具备足够的灵活性来支持下一步重大发展。
10.防止偶然性的SOA:
许多企业可能发现,他们拥有良好的Web服务存储库,这些资源将构成SOA的大部分,虽然他们并不认为SOA始终都采用Web服务。
须牢记的是,SOA必须超越Web服务的范畴,以支持所有的业务流程。
此外,SOA还必须提供灵活、可扩展和可组建的方法,以便重用并扩展现有的应用以及构建新的应用
因此,如果您对于今年启动SOA项目犹豫不决,就将使技术与IT需求更好地保持一致作为新年决议,并联合开发人员来提高收入,降低企业的成本。
遵循这十个步骤,您将踏上SOA成功之路。
与传统的信息技术(IT)项目相比较,当提到需求收集和需求处理的时候,面向服务的体系结构(SOA)项目面临着更严峻的挑战。
来自领先公司的文章和研究材料讨论了缺乏正确的需求是如何导致IT项目失败的。
作为一名IT项目经理、构架师或者开发人员,您可能具有直接对这些问题进行处理的第一手材料。
由于不完整的,错误的或者经常变更的需求,有相当数量的项目超出了他们的预算,而且并没有在规定时间内完成。
到了最后,技术已经并不重要:
如果一个项目具有最高效体系构架,比如它使用了SOA,利用了所有标准技术的,架构是非常健壮的,并且它性能远超过所有人的期望,但这个项目并不满足最初的业务需求,那么这个项目也是在浪费时间和资金。
获取需求需要一套独特的技术,这些技术是艺术与科学的结合。
比如,您不能逃避人为的因素——人们有时候会改变他们想要什么东西的想法。
假设您想要获取百分之百的需求或者期望需求不会变更是不实际的。
一个优秀的业务分析师会与系统的用户一起工作,并向他们建议正确需求的价值。
分析师已经证明了用户参与到这个过程是极其重要的,并且应当让用户对任何的变更或者疏忽担负责任。
这就好比“如果您输入的是垃圾,那么输出的也一定是垃圾”——如果您由一个不良需求开始,那么最终的产品肯定是毫无用处的。
本文是由三个部分组成的系列文章的第一部分,这个系列专门讨论SOA实现的需求过程。
本文集中讨论了SOA项目技术方面的内容,以及您怎样对这种项目的技术需求进行定义。
这个系列的第2部分将讨论,服务作为您的SOA不可缺少的一部分,我们如何对它进行需求定义并为它创建用例。
第3部分研究了如何为SOA的持续管理获取需求。
贯穿这个系列,我们将利用IBM®Rational®RequisitePro®作为需求工具来获取这些需求。
您应该从哪里入手?
我将不会对SOA的基础或者SOA实现路标的不同方法进行深入探讨。
您可能正在阅读这篇文章,因为您的组织已经有了一个明确的SOA路标(或者正处于被的定义的过程中)。
或许您已经确定了一个路标上的起始点,并有一个投资项目来构建最初的三到五个服务。
在这个阶段您需要确定两种类型的需求:
您服务的需求以及支持这些服务的技术需求。
这篇文章集中讨论了后者:
技术需求。
我将在第2篇文章中谈到业务需求。
但是等等——您可能会问,业务需求不是应该首先出现吗?
我更希望先谈谈业务需求,但是绝大多数SOA计划由IT团队领导的,而不是被与IT团队协作的业务团队领导的。
IT团队往往能够在业务团队之前获取新的技术。
他们开始提出一些关于治理、支持、成本模型等等的问题。
在技术的方向上,他们开始谈论统一描述、发现和集成规范(UDDI)存储的问题,技术框架构建服务的问题,企业服务总线(EBBs)问题等等。
我很少见到IT团队谈论关于选择业务服务以及进行概念验证(POC)的问题。
他们挑选一个服务,然后主要精力集中在技术上。
他们讨论这个POC要用什么技术、用什么样的扩展标记语言(XML)标准、使用什么平台、用什么ESB等等问题。
从此处开始并不是不正确,我曾见到过一个SOA的项目,后来进展缓慢或者延期一直到下一个财务年度末,因为IT团队对于SOA所展示的某些方面不能达成一致。
因此我们也这里开始,然后转移到服务的业务需求上来。
对我来说,从这里开始的另外一个原因是这个由三个部分组成的系列逻辑流程。
这篇文章概括了所有的技术讨论,接下来的两篇文章将集中讨论业务,首先讨论最初的服务,然后讨论那些服务的维护和扩展。
________________________________________
SOA路标需求的技术可交付产品
您怎样为您的SOA项目获取技术需求?
假设您已经确定了您准备最初展示的三到五个服务作为您SOA项目的一部分。
警告
有三件事情我要告诫大家:
UDDI、ESB和框架的标准开发工具。
您可能认为这超出了本文的范围,但我有我的原因。
UDDI是一个非常大的概念。
然而,在您首次SOA展示中,您可能只有很少的服务和一个相关的定义明确的消费者基础。
在这个场景中,使用UDDI有点小题大做了。
ESB也是一样。
我们假设您需要构建几个服务并运行它们。
只要您使用了动态的绑定(也就是说您对端点不使用硬编码),您就为这些服务的可操作方法提供可见性,这时使用ESB同样小题大做了。
最后,您也许要求标准话您企业的开发框架和工具。
如果是这样就太好了。
如果不是,也不要以SOA作为借口来这样做。
您可能会疏远一些构架师和开发人员。
只要您的服务能够使他们对服务级别的要求达到一致,潜在的技术是没有问题的。
这对您最初的服务和SOA展示来说就是真理--尽管对这种标准化也可能存在其它正当的理由,比如,离岸外包、减少开发和维护成本、新资源的学习曲线等等。
您应该使这些与SOA保持独立。
首先您必须能够支持少数几个服务。
为了做到这一点,您需要定义:
•运行方面的服务级协议(SLA)
•支持方面的SLA
•服务的执行需求
•部署需求
一旦这些初始的服务存在于产品环境中,您就可以对您的SOA的其它技术需求进行形式化了。
这些包括以下几点:
•长期SOA的整体运行战略
•管理服务发现,供应以及交付
•面向服务开发的最佳实践和模式
•运行方面的SLA
•支持方面的SLA
这时就应该开始为建立您SOA的真实企业规模考虑ESB、Web服务管理平台以及其它的技术问题了。
获取技术需求
获取技术需求从不是一件很容易的事情。
比如,如果您问别人他们需要系统的应答速度有多快,他们会回答,“尽可能快。
”从技术上说,这个需求不会有什么帮助。
在一个SOA例子中,获取技术需求变得更加困难。
您要能够为您的服务确定运行级别:
应答时间、启动时间,当前用户的平均数量等等。
此外,您还必须定义服务级别:
与修复严重程度为2或者3的服务缺陷相比,修复严重程度为1的服务缺陷需要多长时间,构建一个新的特性或增强需要花费多长时间,以及更多的问题。
从这些服务的消费者获取这些需求毫无疑问更多的是艺术问题而不仅仅是科学方法的问题。
科学在于为问题定义正确的答案。
艺术是让您的消费者以一种具体的方式来回答那些问题而不是得到一些含糊的答案。
获取需求的工具
当然您需要一个需求存储库。
RationalRequisitePro是一个非常好的选择,这是因为您可以利用RationalSoftwareArchitect和Rational套件中的工具在整个设计和实现阶段将需求与设计紧紧联系起来。
(查看参考资源部分,可以获取更多关于RationalRequisitePro的信息。
)
一个技术构架师或者一个技术分析师必须与您最初服务的消费者进行沟通,并开始获取这个信息。
您的SOA项目的成功很大程度上取决于您的团队准确、真实地获取这些需求的能力。
比如,您的需求是您的系统支持每秒一百万次的点击和两秒以内的响应时间。
满足这个运行级别的时间和所需资金的总数可能会破坏您的项目的成功,对于一个SOA项目领导者,您需要从小规模着手并逐渐成长。
另一方面,如果这个服务的确需要极其高的运行级别,您需要为您最初的SOA选择一个或者一套不同的服务。
其它的需求
SLA和运行级别协议(OLA)是两套最困难的SOA技术需求,因为任何人都希望这个服务能够尽可能的快速响应,达到24/7,来支持无穷大数量的用户等等。
为这些服务开发定义良好的参数是十分困难的,在构建这样的服务的时间和成本上达到平衡更是难上加难。
一旦您拥有了业务需求(在第2部分讨论)、SLA以及OLA,您就可以开始您的实现和部署需求。
正如前面所提到的那样,在这个阶段您不必因为技术、框架、工、,产品或者甚至是许多的标准而延迟进展。
简易地开始,利用SOAP和Web服务描述语言(WSDL)作为基础标准。
采用.NET®或者Java™技术——无论您的企业是否已经选择它们作为一个标准或者在这方面有更多的经验。
选择刚刚好的最小数量的开发工具。
从开发的角度来看,如果您选择了.NET您就应该利用IIS。
然而,如果您选择了Java技术,就可以使用一个简单的应用服务器,比如Tomcat或者Geronimo。
在这个阶段您甚至不需要Jboss,更不用说WebLogic或者IBMWebSphere®。
然而,如果您的企业对于特殊的开发容器有标准限制(WebSphere、WebLogic或者其它),采取各种办法来与它保持一致。
构架师必须有前瞻的思维,以小规模开始,但是头脑中必须一直保持着一个宏伟的蓝图。
在开始时使用任何简单的工具或者您当时所拥有的构架。
当这些服务成熟以后,您就可以对您的SOA定义全面的技术需求。
您将会有更多的经验知识来更好地决定您的最终构架、基础结构需求、工具和产品需求,以及您想要采取的各种标准得级别。
您所选择的服务应该能够在更大程度上帮助您做出抉择。
________________________________________
总结
在这篇文章中您很少关注对最初SOA项目的技术需求的学习,而更多关注的是从哪入手进行需求获取过程。
SOA提供了很大的远景。
然而,为了达到这种远景,您应该从小规模开始。
从一开始就尝试在整个范围接受SOA将延迟您的项目,并将使成本增加以至于您的CIO在证实它对业务的价值时出现麻烦。
您甚至需要在下一个预算财年中冒些风险来开展您最初的SOA项目.
SOA项目和获取SOA得技术需求与能力成熟度模型(CMM)非常相似。
一旦开始,就应在级别1的CMM中审视自己。
不要试着去解决级别为4或者5的问题。
集中精力于短期的SOA展示上,并在脑子里保持宏伟的计划。
下一篇文章将对您最初的SOA服务的业务需求进行讨论。
它阐述了如何获取这些需求以及利用RationalRequisitePro作为工具来完成这项工作。
然而,使用任何工具都要有这种思想和概念,您可以利用Microsoft®OfficeWord或者任何形式的需求存储库来获取相同的信息。
SOA技术发展至今,越来越多的人已经深入理解了这一架构风格,进而开始思考如何在实际企业环境中实施SOA。
这样就涉及到一个具体的技术问题,究竟应该选择什么技术编程模型来搭建这样一个服务计算环境?
作为SOA的系列图书之一,本书立足于技术底层,试图指引读者理解构建SOA的基础编程模式
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 引导 企业 客户 采用 SOA