java060515/
共102个网摘 [
1 2 3 4 ]
下一页 |
访问java060515的个人空间
java060515收录，使用标签：SOA，时间：2008-7-17 15:25:03 | 相关网摘，我也收藏
需求不断扩大、厂商重点投入、用户理解加深，商业智能(BI)软件应用的“躁动”日渐强烈，它已成为企业必备的关键工具，同时在企业中的需求也迅速增长。
据调查，BI将不再被视为一种独立应用在企业里实施，它将与现有各种的复杂架构相融合。例如一些企业用户渴望BI能成为他们工作的一部分，与公司门户和企业搜索紧密集成，并且内嵌到企业业务流程及其它应用中，最后通过移动设备来访问。
但在企业实践过程中，CIO们发现BI很难应对多种应用、平台和数据源，不能进行及时有效的管理，因此他们认为最好的方法就是SOA来简化集成BI。
专家说，SOA架构所独有的特点能充分满足企业在BI解决方案上高效、可靠，灵活的需求，可以协助企业挖掘出BI部署的价值。针对SOA的特点，专家具体分析如下：
1.利用SOA基于标准的开放式架构集成BI解决方案和其他程序
SOA是基于标准兼开放的，他们为企业提供了BI解决方案所需的灵活性，协助他们调整现有的IT基础架构，避免了功能重复。一套基于SOA的BI解决方案可以在任何网络服务器上运行，并与现有的路由器和防火墙相匹配。统一的API也确保了解决方案能够轻松与其它程序集成。
2.SOA架构灵活、位置透明 符合BI数据和用户分散的特点
企业通过SOA可随时调整现有的基础架构，可以在现有的硬件、数据库和应用服务器上运行任何基于SOA的软件。同时，SOA也具备了位置透明的特点，即能够在网络上的任意位置定位服务。这类灵活性完全符合BI数据与用户的分散属性。譬如IT人员打算紧靠大型数据中心来提供查询服务，以避免在处理请求时所产生的延时。而通过位置透明的服务，IT人员就能采取最有效的部署战略，根据用户、数据与基础架构的具体情况来优化解决方案的绩效。
3.SOA的点对点与松耦合性使BI数据集成
企业在部署了SOA架构后，任何一种服务都能进行完整的容错，任何要求均可通过系统服务器上的同类服务来处理。在解决了单点故障问题后，IT人员会对BI部署更具信心，继而在用户社区建立信任，并由此扩大BI的过渡范围。
这种点对点服务具有松耦合的属性，即无需了解其它服务在做什么，运行在哪里。商业逻辑被剥离到底部架构之外，从而保障了数据源的轻松集成。比如那些打算在数据处理高峰期保持稳定与可靠性的IT人员可以根据点对点服务来调整开发与测试环境，在满足服务等级承诺的同时，无需投资额外的硬件。
4.基于界面与粗粒度服务使SOA和BI完美结合
基于界面的SOA能让各服务之间进行通讯。通过使用SOAP和XML来进行服务互动，交换数据、参数与处理结果。随着从移动设备到企业搜索工具等对BI访问能力要求的不断提高，通讯协议的可用性和开放式API的重要性也在逐步抬升。
粗粒度服务也是SOA与BI一拍即合的主要原因，它将服务定义在了商业层面，而非应用层面。这有效降低了网络流量，并简化了集成。粗粒度服务允许跨越各种流程和应用对这些服务进行循环使用，因此它是有效部署解决方案的关键要素。
此外，粗粒度服务对BI的信息访问方式也有着举足轻重的作用。对用户而言，他们需要的是以最快的速度获取解答，不管该解答是来自于标准报表还是特殊查询，也不管信息是通过BI应用、移动设备，还是其它应用来访问。因此，在相应的层面建立通用服务是实现这一点的关键，这样就可避免在服务之间进行多次传递而提高延时。
粗粒度服务同样也是企业BI灵活性的一大保障，为了在多种环境中提供广泛的BI访问能力，并让所有用户可用，就需要部署一套能对变革做出快速反应的架构。
通过针对所有基于目的的BI功能建立一套常规的粗粒度服务，BI解决方案就可以对新需求做出快速反应。部署得当的SOA基架能确保新技术的快速可用，而无需作为一种单独的解决方案来进行建立及维护。
该技术专家说，企业应当将基于SOA的BI解决方案视作为成功的重要条件。借助SOA基于标准、点对点和统一、开放式API的特点来让IT充分利用现有的平台、操作系统、硬件和安全控制。这种开放性也意味着需要部署及维护的活动组件将会减少，从而为公司营造一套有效、可靠，兼灵活的绩效解决方案。
对IT人员而言，SOA所带来的高效可转化为易于部署、维护和变革。而对企业来说，用户可以在多种平台上访问数据源，基础架构的变更不会严重影响到他们获取信息的能力。解决方案可以更快地建立并运行，商业用户可以访问更多的信息，同时不会受到后台变更的制约。
作者: 徐蕊, 出处:IT专家网
http://cio.ctocio.com.cn/pinglun/200/8219700.shtml
java060515收录，使用标签：SOA，时间：2008-7-17 15:21:06 | 相关网摘，我也收藏
作者: 清茶, 出处:IT专家网
Software AG公司副总裁Bjorn Brauel说，推出SOA不仅仅是利用技术。SOA是用于推动商务流程管理(BPM)的一种建筑风格。
Brauel说，虽然拥有构建应用程序的方法和标准并不是一个新概念，但是，我认为，SOA是没有前例的，因为它是观念、方法和技术的融合。
要取得经营的灵活性和敏捷性，商务流程管理模型、自动化和变化等要根据机构考虑业务应该如何发展的思路进行处理，而不是根据IT功能进行处理。从IT的观点看，这就意味着提供灵活的基础设施去管理流程，对这些变化做出反应。
Software AG公司亚太和日本地区高级副总裁Paul Henaghan对于定义SOA的问题谨慎地指出，部署一个带有符合SOA原则的服务能力的ERP解决方案并不能解释为整个机构范围内的SOA应用。
Brauel赞成这个观点。他说，SOA不是你购买的产品，而是你所做的不断改善工作流程的一部分，这是符合机构目标的。SOA也许在开发Web 2.0服务为用户提供更丰富的在线体验方面还能发挥重要作用。
Brauel称，首席信息官们在实施SOA时应该小心的一个陷阱是设法为SOA制作一个商务实例。显而易见，SOA本身是没有商务实例的。首席信息官们应该从商务流程管理的角度向机构的其他股东解释SOA。
他强调指出，首席信息官们需要围绕商务流程管理建立SOA结构，采用一个直观的SOA路线图，首先定义一个为期三个月的商业计划作为实现更长远目标的第一步。这将保证机构的股东能够更迅速地看到商业价值，如SOA流程产生的节省成本的效果，而不用等待三年之后才看到投资回报的例子。
Brauel说，虽然长期的关键业绩指标(KPI)还不能立即看到，但是，考虑到这个企业正在把现有的资产重新用于自动化的流程，三个月之后衡量短期的关键业绩指标是非常有可能的。以此为起点，这个路线图就能够预测更长远的关键业绩指标。
Brauel表示，自由与治理之间的平衡对于服务开发是非常重要的。
太多的自由意味着允许工作人员在任何时候为自己开发服务，不用考虑其他机构股东需求。这将导致以内部为重点的观点。这个观点认为可能提供商业价值的服务组件不用与机构的其他人共享。
另一方面，太多的治理能够显著抑制工作人员的创造性。他们将想办法绕过规则和条例。Brauel补充说，提供正确水平的治理包括正确地定义目标，以及指示进行整个机构范围内的协作，同时允许服务开发方法的灵活性。
此外，Brauel解释说，在平衡SOA的自由与治理方面，激励措施是很重要的。不应该根据编写代码的行数奖励工作人员，而要根据他们创建和共享了多少个能够让机构的其他人重新使用的服务进行奖励。
Brauel指出，各个地区的首席信息官的观点是有区别的。在美国，首席信息官们议事日程的重点是商务流程管理，而不是SOA。另一方面，欧洲的首席信息官们主要关心IT部门的效率提高。因此，他们在考察商务流程管理之前首先用SOA的观点开始新的项目。
Henaghan说，由于预算紧张，亚洲的首席信息官对于新的IT计划没有那样高的热情，因此，他们要设法尽可能多地从现有的基础设施中获得商业价值。因此，他们把更多的重点放在商务流程管理方面。
Henaghan强调指出，虽然SOA也许会发展，甚至将来会叫不同的名字，但是，把观念、方法和技术融合在一起开发新服务的SOA的基本原则是不会改变的。
Henaghan说，Software AG公司要在2010年达到10亿欧元的年销售收入。我们将与客户进行合作，帮助他们重复使用现有的IT基础设施以创建新的服务。
他指出，亚太地区(包括日本)为该公司提供了巨大的商业机会。虽然我们在亚太地区一直是积极的和成功的，但是，我们到目前为止在亚太地区还一直没有达到我们的美国和欧洲业务的市场普及程度。
Henaghan解释说，亚太地区商务流程管理软件市场还不太成熟，大多数企业仍在进行“教育讨论”，而不是与商务流程管理领域的厂商积极地合作。
http://soa.ctocio.com.cn/xwpl/498/8220998.shtml
java060515收录，使用标签：SOA，时间：2008-7-7 11:29:37 | 相关网摘，我也收藏
作者: 东缘, 出处:IT专家网
业内人士对微软本星期发布Hyper-V技术和微软介绍的其SOA进展情况留下个深刻的印象。除了“绿色技术”之外，你在技术领域很难找到第二个这样热门的领域。人们普遍认为微软在Hyper-V技术方面做得很好，但是，在SOA方面完全没有抓住要领。
为什么呢? 这也许是定义的问题。微软也许没有把“它”当作SOA。分析师认为，他们得到的信息是SOA实际上是Web服务集成，并且认为这是一个两年的旧新闻。人们一直指责微软执行“MOA”(面向微软的架构)。也许这是微软保留自己的机会的权利。这个机会就是以较小、更专业的竞争对手做不到的方式把自己的庞大资源集成在一起。
但是，ZapThink公司的Ron Schmelzer失望地指出，微软对开发人员的能力和需求的深入理解使它不愿意最大限度地发挥自己的潜力应用SOA，把SOA当作一个忘却的平台或者位置。
微软连接系统部门产品管理经理Burley Kawasaki最近解释说，SOA不应该是技术推动的。SOA应该是机构的业务需求推动的。我们的方法肯定会受到关注和批评。这些批评一般都声称微软的SOA战略是围绕Web服务发展的和缺少高极性。
Kawasaki继续解释说，的确，微软并不害怕坚持说Web服务仍然是服务部署的关键。开发人员感兴趣的是更快地开发应用程序。你对他的说法有问题吗?他用了同样多的时间谈了对所有其他股东的好处问题。
这些信息归纳起来是这样地，Kawasaki顽固地定义SOA是为了实施一个灵活的商务解决方案而采用的暴露、组合和消费方法，而不是创建一个可使用的服务。微软的“现实世界SOA”方法是听从了一些客户劝告的结果。这些客户要把SOA应用到当前的商务流程和问题中，而不是创建一个勇敢的新世界。分析师不喜欢这样。尽管分析师们从来不赞扬微软的“技术创新”，但是，他们现在需要微软在SOA方面的技术创新。
这会发生吗?Clive Longbottom在IT-Director.com网站发表一篇好文章深入讨论了微软与SOA和微软与虚拟化的问题。他感到有些困惑。但是，我们终于能够发现一些新东西。
通过Oslo软件把SOA和虚拟化结合在一起，微软能够把目前IT领域的两个最重要的技术联系在一起。这肯定是机构正在寻找的东西。这是根据SOA功能创建动态混合应用程序栈的方法。然后根据动态虚拟镜像在动态应用服务器栈上配置这个动态混合应用程序栈。
业内人士称，微软的虚拟化和SOA解决方案的进入点也是相同的，都是小企业，而不是大企业。微软没有与大企业厂商展开直接的竞争，特别是拥有SOA的厂商。据说微软甚至不想侵入IBM或者BEA/甲骨文的巨大的SOA市场。微软打算用商品价格的工具打入普及率不高和长期被忽略的小企业市场，并且从那里开始发展。
业内人士称，微软将利用其OEM和渠道关系用Hyper-V和相关的管理平台猛攻中型企业市场。第一个版本Hyper-V缺少容错和高可靠性功能，使它很难成为大企业的选择。但是，对于首先把重点放在整合方面的小企业来说这个软件还是不错的。
http://soa.ctocio.com.cn/xwpl/378/8204378.shtml
java060515收录，使用标签：SOA，时间：2008-6-30 11:19:46 | 相关网摘，我也收藏
作者: 东缘, 出处:IT专家网
机构中IT角色的转变已经引起了SOA技能需求的高速增长。IT部门的工作与10年和20年前相比几乎完全不同了，从而产生了IT专业人员需求的变化。
IBM负责全球联盟和学术计划的副总裁Mark Hanny说，20年前，我们要拜访许多公司，要去办公楼后面的房间里。那时的IT部门与公司的战略没有联系。IT现在是业务战略的核心部分。许多机构都围绕IT重新建立自己的业务战略。
Hanny说，你看看现在，IT无所不在，从生命科学到环境工程和宝洁公司。未来的企业领导人将来自于IT。
然而，发现未来的IT业务领导人比听起来要难得多。随着7000万美国的婴儿潮(1946至1964年)一代(占IT员工队伍的大部分)逐渐进入退休年龄，这种滚雪球效应和年轻的工作者对IT职业不感兴趣不仅令学校感到为难，也使IT行业领导人为难。
Hanny说，有一个遗憾的说法是没有IT工作岗位，IT工作岗位都外包给印度了。但是，这并不是事实。现在对IT技能还有很大的需求。
IBM认为最大的需求之一是SOA专业人员，因为企业需要能够把业务功能灵活地集成在一起的IT专业人员。据市场研究公司AMR Research分析师今年2月发表的研究报告称，全球各地投资SOA项目的企业数量在过去的一年里增长了一倍，从而创在克数不清的SOA工作机会。
专门从事劳务市场数据搜集和研究的技术公司SkillProof的总裁Henning Seip说，四年前，在职务空缺中根本就找不到SOA。现在这样的职位空缺非常多。
AMR Research的报告称，各个行业都有SOA的工作机会。接受调查的受访者表示他们至少在一个项目中使用了SOA技术。59%的受访者在零售行业。54%在电信行业，42%在金融服务行业。金融服务行业的SOA开支是最多的。
Seip称，我们谈论的这项技术的帮助是，如果你不能实现工作流程的自动化，你就不能取得成功。商务流程建模是我们在美国的最新的工作领域。这个工作岗位几年前是不存在的。
http://soa.ctocio.com.cn/xwpl/325/8185325.shtml
java060515收录，使用标签：SOA，时间：2008-6-30 11:18:41 | 相关网摘，我也收藏
作者: Stella, 出处:IT专家网
建立在面向服务架构(SOA)上的Web应用程序将极大的提高IT效率和业务灵敏度。SOA 建立起了数据和协议方面的统一标准，以使得现有的内部和第三方应用程序模块或服务能够有效的重复利用，并可以进一步重新组合进业务应用程序。但不幸的是，在SOA迅速促进业务应用程序实施的同时，这些应用于生产的程序也大大增加了其性能管理的复杂性――这在很大程度上降低SOA应用所能实现的优势。如果没有有效的方法来监控应用程序的性能、迅速找出症结所在并加以解决，那么SOA应用就很有可能成为死亡之路(dead on arrival ，DOA)。
在实施SOA有几个方面的原因导致IT很难管理应用程序的性能：
造成低效的共同要素：一个SOA应用程序所提供的服务，其水平受到网络中该SOA应用程序所需性能的服务水平限制。为了达到最大限度的灵活性，服务甚至可以由第三方供应商提供，并有可能在不同的计算平台上运行。这使得IT从实际操作上不可能界定出服务构件的性能特点，更不可能完全控制那些影响程序交付和执行的众多机动部分。服务的重新利用还意味着通用服务中所存在的性能缺陷也在程序应用中被复制过来，产生了无法预计的故障。这样以来，就很难从数量上确定服务水平是否超过终端客户的期望或至少达到服务水平协议(SLA)中规定的性能目标。
联动实验效果：对于一个通过Web发布的SOA应用程序来说，要确认其服务的发起和交付时存在哪些问题同样是非常困难的。问题根源可能存在于交付机制中任何一个“机动部分”，比如客户的个人电脑、网络、数据中心、服务组件和/或第三方服务提供商的服务或基础架构。在这样一个复杂的环境中，没有一张“嫌疑列表”足够巨细无遗列出所有的可能性。
繁杂的网络环境：在处理这些通过Web发布的应用程序或基础架构时缺少一种可预见性或事先确定的步骤去实现操作，也进一步使得诊断SOA应用性能问题的任务变得更加复杂。在客户端或服务器端的计算环境中，一个目录查询是经由定义的网络分段，并由安装在固定服务器上的ERP应用程序加以支持;而在SOA环境中的目录查询可能经由网络动态的进行，并且由多个虚拟或实际服务器所在基础架构的多层逻辑中加以支持。第三方Web服务需求也能传输给提供商的基础架构从而从提供商自身开始说明详细目录。这种复杂的组合需要涉及非确定性的操作路径，这使得改造或诊断整体应用性能的问题变得十分困难。
为了应对如上的这些挑战，使得SOA应用不至走上死亡之路(DOA)，IT需要两种能力为其所用。首先，IT必须能够像真正的用户那样监控应用程序的性能，因为这是唯一能感受到所有服务组件的环节要素所在。除此以外，如果发现服务水平受到影响，他们必须能够迅速的追踪不利操作，查明引起性能下降的问题根源所在。如果能系统的利用这些能力，IT就能够：
· 通过发现性能瓶颈与缩短问题解决时间来提高服务水平。
· 排除不必要的评估会议和毫无成果的改造尝试，降低操作管理的成本和失误几率。
那么现存的终端用户在实现其应用程序满足IT需求的同时应该如何监控其技术交付从而避免应用程序走上死亡之路(DOA)呢?让我们看看对于监控技术在应用于SOA性能管理的调查情况：
· 嗅探器或是其他的包捕获程序即可很容易的评估出在传输规则下包响应的来回时间，但是对于那些传输路径并未通过在网络中安装了这些程序的关键点的交易则无法判断出准确的响应时间。拿Mashups应用做一个例子：关键的数据项目由第三方应用程序提供，旁路的嗅探器会安装在网络服务器前端。在数据中心，基于SOA应用的基础上嗅探器依旧会遗漏掉Web服务而是更多的监测到来自服务器端或是第三方的服务。
· 服务器监测工具只能针对其所监测的局限范围做出事务处理时间响应的报告。举例而言，流行的J2EE应用程序服务器端监测工作只能对安装了这个应用程序服务器的范围内做出事务处理响应时间的判断。直接由Web或是第三方服务所提供的事务处理服务没有涉及到应用程序层面则无法被J2EE监测工具直接管理。
· 传统的网站性能监测服务可以准确的监测到SOA应用程序是否可行。但是它并不能就性能做出一个有经验可参考的报告提供给真正的使用者，或是给出一份针对问题的精细记录信息从而完成纠正性的完善。
· 纯粹的SOA管理产品可以帮助IT部门从相互依赖的各种服务中建立起有效模型，从而提供有限的事务处理方式的信息，但是这样的产品往往会忽视整体基础架构的良性发展。最关键的是它无法对最终的性能表现做出预判并给予最终用户以经验指导。
在提供“真实”可行的信息以管理SOA的性能方面，这些遗产工具不仅在所收集的性能数据类型上不够完善，在收集数据的来源方面也存在缺陷。至关重要的是要界定应用程序性能在被终端用户感应到的反应时间，而不是服务器、网络J2EE、数据库或其他局限范围内的度量。毫无疑问的是，终端用户体验是唯一重要的事情。此外，在mashup应用程序中，网页是由多个服务器或第三方数据中心来支持的，当应用程序通过内容传输工具执行的时候，程序在内容都已经到达浏览器的时候也许都还没有组合起来。结果，唯一衡量SOA应用性能好坏的有效方法就是直接从真实用户的浏览器来测量。
为真实用户确保实时监测和事务处理追踪能力可以避免SOA一步一步走向死亡之路，IT部门需要在其SOA性能管理工具中拥有如下的三个整合基础功能：
有效监测：“没有度量标准就没有管理”。SOA管理的第一步是要找到一个界定SOA应用程序是否满足服务水平要求的定量的方法。换句话说，“正确的应用反应(数据、页面、行动等等)是否在合适的时间内传输给了正确的用户?”有许多质量保证技术来确保正确的应用程序反应的交付。而且，多数组织都具有必要的安全措施来确保信心传送到正确的人手上。但是，确保信息在正确的时间内通过复杂的基于网络的SOA基础架构传达给终端用户却又是另外一回事了。具有能力对真实用户体验应用性能进行非干扰性的监测是绝对必要的，原因有二：一是因为这是唯一办法来准确监测SOA应用程序服务水平保障和报表真实用户感受到的问题;二是因为它创造了进行流程改进和提高应用程序反应时间的关键推动力。这种监测手段始于终端用户浏览器，也就是所有的应用程序真正组合到一起的地方。只有在浏览器上，IT才可能考虑“最后一里”的情况并识别是否有会影响到客户满意度的事情发生。由遗产工具搜集而来的数据主要侧重于监测特定的技术局限范围――如网络路由器、Apache网络服务器、WebSphere应用服务器或者是NET框架――都不能用于推断识别SOA复杂应用程序的真实最终用户在浏览器中的体验。
隔离分析：一旦了解了最终用户在应用程序性能方面的体验，它就应该与SOA相关反应交付中涉及到的所有的基础架构和应用组件性能资料联系起来。因为复合应用程序是由像“黑匣子”一样的服务构成的，它们的性能是不能够被这些组合程序的工具所控制和调节，对于这些运行在真实或虚拟基础架构组件之上的应用是不可能完全的被IT运作所掌控，他们可能有来自不同数据中心的事务交易或是由第三方服务方所提供服务端，最重要的一点这些不管是整体基础架构也好，第三方数据中心也好，还是不同的应用组件也好需要紧密的相互关联起来并对其性能做出准确的报告。性能的相关性可以通过对日志文件的细致分析或是通过各阶段IP匹配与请求发起的时间等做出判断，但是即便在所有的日志文件都可得的情况下这种方法依然会是非常困难并且会有难以避免的错误出现，而且一旦出现事务交易涉及到了外部的数据中心那日志文件将很难记录下来从而在分析时造成错误。另一种简单的机制则是标记出每一个事务交易是由哪一个终端用户所发起，并在整个基础架构中采用非干扰性的动态追踪，在每一阶段记录下适当的性能数据。这种端到端的性能观测需要基于用户的使用经验所能提供的对于整体状况的鸟瞰视角，从而对细微的事件、错误或性能瓶颈所对最终用户在响应时间上的影响做出判断。
优化：全面的浏览器到数据库的事务交易性能视角可以确保提供可靠的信息从而使得特别的或是反复试验所得的方法将不再需要用来对性能问题做出鉴别和响应。如果缺少可靠的信息那么IT部门的事件响应团队可能需要花费更多的时间去辩论，努力找出问题所出现的原因，在很大程度上他们会更多试图重建这次问题而不是马上着手于解决这个问题从而恢复整体的业务功能。通过长期对这些相互关联的事务交易性能的信息进行分析，IT部门可以准确的判断出性能影响中最关键的主要冲突所在并能在下一次问题对用户满意度或业务生产力造成影响之前将其解决。此外，这些信息也能更好对基础架构、服务以及应用程序性能的改善带来着实有效的帮助。
将以上三种功能集成到一个单一的SOA性能管理工具里可以为IT部门提供一个前期响应系统用以监测并在最终用户端性能问题引发大范围冲击造成巨大损失之前迅速做出响应。业务冲击或性能瓶颈的相关信息应第一时间及时反馈到运作人员用以完成对基础设施或流程的改进，同时为开发人员优化程序应用。
毋庸置疑，SOA的出现可以大大提升业务灵活性，降低应用程序开发成本。但是，如果没有一个真正的面向用户的方式用以管理SOA部署实施以及一个系统化的生产管理，那SOA应用的前途真的有可能踏上不归的死亡之路。
http://soa.ctocio.com.cn/xwpl/316/8185316.shtml
java060515收录，使用标签：SOA，时间：2008-6-30 11:17:09 | 相关网摘，我也收藏
SOA是一种思想?一种软件产品?还是一种软件服务?尽管越来越流行的SOA已经充斥到几乎所有的IT经理脑中，但SOA究竟是什么?仍然让人迷茫。面向服务的IT架构到底在业务与IT两个世界中扮演了怎样的角色?你眼中的SOA到底是什么?
在今天，竞争激烈、变化越来越快的全球化商业环境中，传统企业观受到严重挑战，如何灵活快速适应变化、创新求变，成为企业生存和发展的头等大事。在业务敏捷性的实践中，SOA正成长为IT促进业务提高的转移范式，从设计原则、架构范式以及技术、标准和产品中实践着它面向服务架构的伟大使命。
业务敏捷性向业务与IT两个世界发起挑战
事实上，许多企业都无法实现“业务敏捷”。他们的工作人员各自行动，计算机系统又相互隔离，不能协同工作：一方面是由IT部门负责的信息系统，另外一方面则是调整IT系统所需要必要时间和成本。受这二者的制约，企业变化要么时机已逝，要么得不偿失。因此，业务方作为利润中心，总是抱怨IT每年都要花很多钱，不仅不能获得良好的投资回报，也不能帮助建立战略性的竞争优势。而IT方作为成本中心，往往怨恨自己没有得到应有的重视，资金不够、加班加点。这种现象的出现也就不足为奇。
到底应如何看待IT与业务之间的关系?
首先，业务活动是由业务人员和信息系统共同完成的，业务人员执行人工活动，比如拜访客户、输入订单和客户资料、做出商务决策等等，而信息系统执行各种自动化活动，包括商业逻辑、业务规则、管理业务数据，提供界面连接人员和信息系统。所以IT是业务的一个重要组成部分。
其次，业务方决定人工活动和自动化活动的需求，管理人工活动，但是他们往往不具备必要的技术能力来建立、维护和运营那些支持自动化活动的信息系统，这些工作被委托给自己的IT部门或者外包。所以IT要服务于企业战略，为业务建立竞争优势，帮助业务快速应变和创新求变。
可见，业务敏捷性首先需要的是一个灵活的业务模式(Business Model)，业务自身不灵活，想改变却心有余而力不足，IT再能干也是干着急。其次，需要IT的敏捷性，也就是说一个当业务改变的时候，那些自动化活动说变就变，随业务的变化而变化，花的时间少，花的人力物力也少。这种IT的灵活性，对IT的所有方面都提出了挑战，从架构、方法论、技术、产品，到过程、成熟度和管控。最后，还需要IT与业务这对“冤家”之间的有效沟通与亲密合作。
这很不容易，业务与IT来自两个不同的世界，看世界的方式不同，所使用的“语言”也不同。大多数时候，业务不愿意花足够的时间在IT上，反过来，IT也不愿意花足够的时间去理解业务。他们把更多的心思放在技术上，有时候甚至为技术而技术，忘了IT是为业务和战略服务的。 因此，业务敏捷性同时向业务和IT两个世界发起挑战，沟通和协调成为必然。
SOA畅行业务与IT两个世界业务架构描述业务世界：从业务领域、业务组件、业务对象，到业务服务、业务流程、业务规则……IT架构描述IT世界：从应用、数据、集成、安全、基础设施(包括服务器、存储、网络)，到IT运营，全面覆盖……两个“世界”共同服务于企业，而如何实现两个世界协作则成为企业战略目标实现的关键!
SOA正是沟通两个“世界”使命的承担者，它提出了架构管控的概念，从角色、活动、职责，到协作、审批和监管的框架，保证有一个游戏规则来让这些东西真正地服务于企业的战略和目标。
然而，大多数企业对自己的业务模型仍停留在自发状态，缺乏业务方面的严谨企业架构实践，更谈不上业务与IT的沟通，这直接带来两个问题：
一是业务优化、应变和创新缺乏形式化和数字化的基础，很容易靠感觉办事。这种“拍脑袋”应变策略，往往带来很多问题，有些时候，这些问题的原因被强加到IT的头上，而使IT承担了不应承担的责任。
二是业务和IT之间缺乏“可追溯性”(Tracability)。在将业务的需求映射到IT的时候，使用模糊的自然语言，容易造成翻译后的失真和变形。同时，细粒度的操作层次所定义的需求，受到变化的冲击大而快。这最终导致业务和IT在进行需求映射，尤其是在需求发生变化时，很难保证好的可追溯性，从而导致业务的需求无法准确地映射到IT，业务需求的变化很难被快速地定位到IT。
传统模式需要引入新的IT架构范式和抽象层次，从而为企业的业务活动和流程提供多系统相互协作的IT支持，SOA则恰好扮演了这个角色。
SOA为业务与IT两个世界带来什么?
SOA究竟在实现业务和IT两个世界的沟通中体现了怎样的价值?笔者认为：
① SOA在业务与IT之间增加了一个新的抽象层次，就是“业务层次上的契约”，用来描述不同的业务组件(或者业务对象)之间交互的接口。这就是SOA通常所说的“服务”。
其中包括功能接口、服务质量约定(Service Level Agreement)和业务策略等。它们是用于组件化地对业务建模，通常其粒度比技术层次上的对象或者组件接口要粗，而业务流程就是通过将这些服务编排在一起得到的。当业务流程发生变化时，有些变化通过改变服务的配置(如业务策略)来完成，有些变化通过重新组装已有服务来完成，有些变化要用到现有服务之外的业务功能，则需要外购或者开发少量新服务，然后重新组装。
业务组件化建模所得到的服务模型，解耦了业务架构和IT架构，提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性，即在服务定义不变的情况下，业务和IT可以独立地演变，带来很好的灵活性。
② SOA建立了一个新的集成架构，负责将遗留系统和新建的系统连通起来，让不同技术世界的服务组件可以相互以Web服务接口为中介来松散耦合地交互。
这牵涉到各种协议、API、消息格式的转换、服务端点的发现和绑定、消息的路由、服务质量的保证、服务策略的实施等等。SOA继承了过去EAI(Enterprise Application Integration)和MOM(Message Oriented middleware)的最佳实践，比如“企业服务总线”(Enterprise Service Bus，ESB)作为一种架构风格元素，用于在分布式环境下提供松散耦合的集成基础，但是SOA使用了Web服务，建立在标准和开放技术的基础上，而不是私有的技术、标准和方式。新的集成架构还引入Service Registry，ESB与之合作提供服务的动态发现和绑定。ESB的实现通常会利用已有的消息中间件。
③ SOA通常会创建一个数据服务层，集成EII(Enterprise Information Integration)的技术和最佳实践。
这个集成架构，要确保所有服务和应用在开发之时，能够跟其他的应用和服务集成，不管它们今天是否存在，互联互通、相互集成、“开发即集成”是SOA对技术层面的基本要求。
值得提醒的是，SOA一个很重要的设计原则ESB是基于“服务”的分布式集成，很多基于“细粒度”的接口和消息集成，并不符合SOA的设计原则，也将导致可能的性能问题。
④ 在应用架构方面，新的SOA技术和标准，比如SCA/SDO允许你采用平台和语言相关的方式实现，但是组件实现的服务接口则是标准化的。
复合应用(Composite Application)建立在其他应用的基础上，通过将来自Portal应用的人工活动、B2B的合作伙伴应用、数据服务和本地业务服务来快速形成新应用。基于BPEL等标准的流程引擎，使用“声明式”的方式来将服务编排在一起，在复合应用中起着重要的作用。这些都是在已有的应用平台上增加而来，比如IBM的WebSphere Process Server支持SCA/SDO和BPEL，它是在IBM的J2EE服务器WebSphere Application Server的基础上实现的。
我们前面所设计的服务，实现它们的IT组件就表现为一些SCA组件，或者EJB、POJO组件，而业务流程则在IT层次上实现为BPEL或者一些SCA组件。这些服务和流程都有自己基于标准的形式化描述，保存在服务注册库(Service Registry)中。
⑤ SOA Governance被用来在整个服务的生命中期中，将来自业务和IT的人协调起来，让他们各司其职，有章可循，相互协作。
在实现层面，这通常需要借助于Service Registry来管理服务的生命周期，同时，我们需要扩展现有的管理产品，从基础设施、应用和组件的管理，延伸到服务、流程和业务活动和业务绩效的管理。在这个基础上，建立数字化的服务和流程优化策略，从而使得IT可以主动地向业务提供业务优化和调整的支持。
辨明SOA认识的四个误区
简单的说，SOA的产生遵循了这样的逻辑主线：业务敏捷性需要一个灵活的业务模型，业务模型需要一个灵活的IT来支持。同时，良好的业务建模，IT与业务之间的对齐和互动变得很重要，所以基于企业架构的实践，横贯业务和技术的SOA管控被用来保证SOA转型的成功。
一个灵活的IT需要遵循必要的设计原则，比如关注点分离、松散耦合，而这些设计原则结合具体技术形式体现在IT架构中，将会形成自己的架构风格，这当然也由一些架构元素支撑，比如ESB，服务注册库等。这些架构元素多多少少都能够从过去的IT当中找到些影子，但是，它们使用新技术，建构在开放标准和技术的基础上，融合和继承了过去的实践成果，也同时容易产生误解：
误解一：SOA=ESB
ESB只是SOA架构中的一个元素，负责转换、路由和服务质量等。看待SOA，应该从业务、技术、管控等不同的角度来看待。
误解二：SOA=Web Service
Web Service通常指基于SOAP/HTTP的Web服务，这些服务是实现SOA中所定义服务的一种技术形式。Web Service提供了分布式环境下卓越的互操作能力。
误解三：我的系统都是新系统，SOA没有用武之地
答案应该是“有”，如果你希望得到业务敏捷性的话。SOA通过更好地让IT和业务融合在一起，借助于企业架构、业务建模、SOA监管和一些新的设计原则，架构风格，支持这些原则和风格的最新技术来达成IT的灵活性，以支持业务敏捷性。
误解四：SOA与BPM是一回事
BPM与SOA关系紧密，但并非一件事。BPM的目的是业务优化，这种优化需要IT的支持，SOA提供很好的支持。另外，BPM在业务建模和业务规则方面为SOA提供很好的支持，为SOA达成业务敏捷性带来良好的基础。
你的SOA是什么?
SOA作为一种架构方式的变革，充分体现了业务驱动的价值诉求。通过总结和继承过去IT实践的成败得失，SOA将其首要目标定位为业务敏捷性，即通过建设一个灵活的IT来帮助业务快速应变，引领创新。因此SOA对业务人员、管理阶层是一个值得注意并且很有吸引力的事，但SOA对不同角色的人意义也自然不同。
① 对于IT主管
SOA是一个好机会，建立IT的战略地位，通过IT帮助企业建立战略性竞争优势是IT人员马上就可以去做的，但是如何实践企业架构，如何建立SOA管控，如何通过SOA Center of Excellence来组织人员，培养种子力量将是IT主管要面临的挑战。
② 对于架构师
需要了解SOA的设计原则、架构风格、架构元素和相关技术和产品。他们需要配合IT主管，推动企业架构实践和SOA管控，跟业务人员共同合作，推动SOA项目。
③ 对于开发人员
学习和使用SOA，是趋势使然，即需要学习新技术，也需要增加一点架构的意识，还需要培养自己的业务建模能力。
④ 对于ISV
SOA可能意味着一个好机会，就是如何将自己对一个行业的理解转化为一个比较通用的业务模型和服务模型，通过可重用的软件资产，建立面向行业的解决方案模板与复合应用。
http://soa.ctocio.com.cn/xwpl/54/8195554.shtml
java060515收录，使用标签：SOA，时间：2008-6-30 11:15:51 | 相关网摘，我也收藏
从企业服务总线(Enterprise Service Bus，ESB)在2002年被正式提出以来，我们看到ESB不管是在实现方式还是部署方式上都有了不小的变化。在过去的四年多的时间里，ESB作为软件领域里的一个独立产品也被越来越多的人所接受，众多的ESB供应商正在架构、连接性、易用性以及服务质量的保证(如持续可用)等方面进行竞争......
很多综合服务供应商(如IBM、BEA)、企业应用集成商(如Tibco、webMethod)以及Web服务工具供应商都纷纷给自己的产品冠以ESB的名号，英国电信甚至把ESB做进了它们的一个硬件产品中。
很明显，作为SOA(Service-Oriented Architecture)的核心和基础架构，ESB已经成为准备踏上和已经踏上SOA之旅的CIO们必须认真考虑和仔细研究的一个产品。因为作为一种中间件，ESB通过与它连接的各种应用的服务级接口实现各种应用之间的连接，控制它们之间的通信，这一功能正在越来越多的生产系统中发挥着作用。更为重要的是，几年来很多企业和机构已经在生产中部署了ESB，ESB的效果得到了一定程度的校验，同时人们对如何充分发挥ESB的作用以及建立SOA的环境，为此需要建设、部署管理哪些基础设施有了越来越清晰的认识。这些基础设施包括：
面向流程、事件驱动的架构(Event-Driven Architecture，EDA);
Web服务的治理;
高级Web服务规范(WS-*);
复杂事件处理(Complex Event Processing，CEP);
语义数据集成。
事件驱动的架构
谈到ESB就不得不谈到面向流程、事件驱动的架构，因为ESB与这种架构配合起来可谓相得益彰。
通常，点对点的集成是通过简单的请求/响应这种同步的方式来完成交互的。在这种环境中，ESB作为数据传输和转换的中介可以很好地完成这一任务，但是，ESB最能发挥作用、也最能体现其带来的灵活性的地方还是在面向流程、事件驱动的架构中。
在进行跨多个应用、大范围的集成时，成功的关键是有一个灵活的架构，面向流程、事件驱动的架构就是这样的架构。通过使用ESB，事件驱动的架构中的每个应用与其他应用之间处于一种松耦合状态。在这种架构中，每个应用独立于其他应用运行完成一项任务，或者异步地完成一组任务中的一个。
即使在一个应用发出了一个请求，然后等待响应以完成接下来的流程时也是这样。这个请求被发到总线上，按照预先定义的流程，这个请求可能会经过很多应用、数据源、路由器和转换器。上述一系列的行为都是独立完成的，最后的响应也是作为一个独立的事件到达最初的这个应用。
事件驱动的交互模式一个主要优点就是保证应用之间的松耦合。只要接入ESB中，每个应用都不用了解如何与其他的应用进行交互这些细节，ESB负责处理所有的协议、数据格式和不同的交互模式。
当然，事件驱动的架构只有在一定条件下才能有效地工作。首先，ESB必须具有可靠和高可用的异步消息传递能力。在一个同步的点对点的集成项目中，如果一个应用没有收到一个请求的响应，它会发出错误的信息，同时再次尝试发出请求。但是在异步的情况下，应用向ESB发出一个请求以后就不再关心是否会有响应，直到一个新的请求到达，通知这个应用完成下一个处理。
由于很多时候企业的所有交易都必须经过ESB总线完成，因此ESB必须有容错能力，支持复杂的业务逻辑，遇到错误的逻辑也能及时恢复。
另外一个必须满足的条件是，应用需要适应这种事件驱动的交互模式。在事件顺序非常重要的场合，应用必须能够检查事件的顺序并做出适当的处理，否则，ESB就要有能力保证在复杂的逻辑情况下(也许这些逻辑还会有错)事件的先后顺序。
http://soa.ctocio.com.cn/xwpl/70/8195570.shtml
java060515收录，使用标签：SOA，时间：2008-6-17 12:58:17 | 相关网摘，我也收藏
SOA是面向服务的架构，没有人不同意。但对于SOA究竟是什么，每个厂商都有自己的定义和解释。有人说是一种架构，有人说是一种方法论，却没有几个人能给出一个大家都信服且简单易懂的解释。SOA将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA给整个IT机构都提出了技能挑战，而不仅仅是架构师团队。特别是，SOA---就像其它任何架构一样，给应用开发团队带来了很多困难。毕竟，开发人员都是有创造性的精英，他们喜欢自由自在，不欣赏太多的结构。然而，作为一种架构，SOA给开发人员带来了太多地限制。
重量级SOA的部署可能涉及到很大的团队进行参与，并且责任分工很广泛，而中型SOA项目一般都是由规模较小、比较灵活的开发团队完成的，在部署过程中，架构师可直接与开发人员、测试人员和其它日常工作人员直接打交道。此外，如果企业能够利用可以支持如此广泛专业的工具，那么，这样的一个以团队为基础工具可以缓解许多架构师和开发人员之间的矛盾。
其实上，这些冲突往往归结为治理(governance)问题---当开发人员在创建、发布、发现以及重用服务时，应该使用什么策略，谁负责制定和执行这些政策。中型SOA工具因此应该还具备对于这种治理能力的支持，从而使得应用程序开发团队与架构师可以一起参与策略的制定和执行，而不是仅仅让架构师负责制定这些策略，这种做法是不切实际的，通常会引起开发人员的抵制。
在阐释SOA的理念上，各家厂商可谓八仙过海，各显神通。这些厂商不仅有IBM、BEA等老牌厂商，还有IONA、普元、TmaxSoft等市场新秀。在一些传统老牌中间件厂商推进SOA的同时，一些市场后进者也开始提出自己对SOA的定义，由此引发用户对SOA美好前景的期待。
没有选择是一种无奈，有选择是一种痛苦：在市场只有一家垄断厂商具有发言权时，用户就没有选择。选择很多时，用户往往又会无所适从。目前，SOA已经成为全球IT市场的焦点，中国也成为SOA最大的潜在市场。对处于摸着石头过河的SOA产业来说，市场的培育需要概念开路。名目繁多或过于超前的概念，其好处是可以让更多的厂商在市场上取得发言权，让用户有更多的选择，可谓一件好事;其坏处是，很容易让用户在对SOA创造商业价值抱以几许期待的同时，不免多了几分困惑，同时，也不利于SOA的落地。
不论厂商宣称自己的SOA理念多么超前、落地方法如何敏捷，对于用户CIO来说，实施SOA的目的都是一样的，那就是实现以业务为核心，提高IT系统扩展的灵活性以及IT资产的复用，达到业务灵活组合的状态。
虽然不同厂商或个人对SOA有着不同的理解，但对SOA所能实现的目标却没有太大的争议，那就是实现企业IT资产的最大化重用，让IT变得更有弹性，更快地响应业务单位的需求，实现实时企业。从这个角度看，SOA是什么并不重要，重要的是能否满足用户的需求。不论黑猫还是白猫，抓住老鼠就是好猫。不论是市场的先行者，还是市场的后进者，不论它宣称的SOA是框架还是方法论，有一点不变的是，谁在中国树立了最有说服力的SOA样板用户，谁将吸引更多的新用户。
正确认识SOA的两大窍门：架构及规划。
SOA是个好东西，但还有点扑朔迷离，就像一座山，远看郁郁葱葱，近看荆棘丛生，真想登上去的时候不知道哪一条路可行。对于实施团队，SOA不是一个产品而是一个架构;对于管理团队，SOA不是一个项目而是一个规划。如果企业是从架构及规划的角度来考量SOA，那么它们会对其优点有更踏实的认识。
企业信息化服务体系要对传统应用和治理模式进行改造。
中国企业信息化工程最重要的就是透过全面开放的应用服务体系对传统体系进行应用模式和治理模式的改造。这是中国企业，不但是中小企业在进行信息化过程当中可能最需要的，也是我们国家在所有企业实施信息化的过程当中最有效的一种实施模式。
安全隐患成为移动信息化的一个难解的心结。
随着移动信息化的深入发展，许多专家预测未来会有更多的病毒和蠕虫蔓延到智能手机等移动设备，严重威胁移动信息化的安全。如今摆在用户单位面前的当务之急是如何最有效地保护所有移动设备上存储的各种敏感信息。
最准确的解释，SOA将不会仅仅作为一套架构存在，而是在整个执行过程中的一套政策，实践做法，甚至是遵从的框架。
我可能并没有正面指出SOA带来什么。但是，我所能明确的是，对于最初的汇编语言，其后的结构化编程，以及风靡的面向对象理念，SOA的出现是发展的必然，同时也是对以往最强力的冲击。
作者: Heven, 出处:IT专家网
http://soa.ctocio.com.cn/xwpl/124/8164124.shtml
java060515收录，使用标签：SOA，时间：2008-6-17 12:51:28 | 相关网摘，我也收藏
CIO心中的SOA和厂商宣传的SOA，好像并不是一码事儿。为什么SOA(Service Oriented Architecture，面向服务架构)正在大行其道?答案也许简单到极点。
随着企业规模的逐渐扩大，企业的复杂性也不断增加，不同部门之间职责、利益、流程的交错，让包括部分高层管理者在内的很多人不清楚，如果企业某个地方出了问题，到底应该追根溯源到哪个部门、哪个人。
这种现象对于已经深入到企业每个角落的IT产品、IT服务也是如此。早上ERP登录不上去了——这到底是网络问题，还是ERP问题，或者是数据库、服务器出错了?IT部门到底应该找哪个供应商解决问题呢?
国内CIO对SOA早已听了很多。SOA的理念和他们所面临诸多挑战，促使很多CIO 开始认真地思考“企业的IT 环境到底需要什么?企业的业务需要到底有多复杂?
从这个角度上看，对CIO而言，有无识别能力显得非常重要。那么，CIO们该如何决策?“CIO采用新技术和新理念的动力有两个，一个是希望，一个是恐惧。”上海家化副总经理王茁说。他所说的希望，就是CIO如果采用某种解决方案或者技术架构，IT和业务的情况也许会变得更好;而所谓恐惧，是指如果你不采用新技术优化现状，那将会面临“下课”的风险。王茁说:“对于SOA，我从来没有恐惧过。”
当我们把目光转向SOA时，同样的问题出现了——当应用因为一个根本性的故障而被迫终止的时候，应该由谁来负责接听并处理用户的紧急求助?
目前SOA已经步入实施的纵深阶段，然而，近来国外的一系列SOA实施案例表明，曾经备受肯定的SOA架构正暴露出其架构的固有缺陷——当基于SOA的服务管理达到一定深度时，目前的SOA管理策略在服务故障的追根溯源方面力有未逮，这一现实对整个SOA架构和管理理念都提出了严峻的挑战。国内SOA用户应该对这一动向保持足够的警惕。
多数CIO计划实施SOA
在调查的企业中，有一半多(58%)企业的IT主管已经实施了或正在考虑实施SOA，其余的(42%)没有考虑SOA。在选择SOA方面，首要的顾虑为缺乏合格的员工或资源(47%)，缺乏期望的投资回报ROI (40%)和缺乏资金 (38%)。
几乎三分之二被调查的企业正在培训现有的职员来满足新的实施要求，而培训中接近一半人(45%)将胜任顾问职务。41%的企业说他们已经适当地培训了员工， 19%的企业计划外包其SOA关键的部分。当问及为了使职员满足SOA要求而采取的战略时， 有40%的IT主管强调他们会培训现有的员工。
曾经实施过SOA的CIO们说，SOA是为内部集成应用使用的占44%，直接地提供服务给顾客或消费者的占28%， 与外部合作伙伴提供的应用进行连接的占21%，而有53%的回答“上述的情况都有”。
CIO如何把握时机部署SOA
SOA 能够优化业务需求与 IT 的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向 SOA 实现的技术可以无缝集成(考虑：“开放标准”)，以构造全面的端到端解决方案。
当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验。
在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制(例如，技术投资、编程模型采用、服务的合同协定等)。因此，我们并不能总是自由地采用看起来能满足某个业务需求或技术要求的最佳选项。
CIO如何选择SOA标准
挑战是还不存在通用的、一致的架构框架来指导这些标准的进化、完善和集成。很多标准都不成熟。”
在这些标准成熟之前，CIO怎样才能趟过这滩泥地呢?技术官员和行业专家给出了这样的建议：密切的监视这些标准的发展并且努力保证你的选择是开放的，但是一定不要拖延关键SOA项目的启动。一些策略可以帮助你避免陷入标准的困境中。
当你做你的SOA规划的时候，你可以创建一个关键标准的列表，不是全面的标准列表。比如，像SOAP和WSDL这样的标准已经被广泛的采纳了，包括WS-Security等标准即将被广泛采纳的。但是其他的一些需要构建和高质量服务进行操作的WebServices的规范——比如管理、交易和高级安全的标准——仅仅成熟到适合具有冒险精神的技术采纳者。
CIO应该支持基于标准的SOA而不是本地的协议，如果一个应用必须有比WebServices所能提供的更高的QoS，“那么做技术的变通，但是这些变通能够保持和出现的规范的设计模型的密切联系，从CIO的角度来讲，他们冒着很大的压力来采用一个中间件平台来填补缺乏的标准，但是从某种程度来讲，这不会将他们锁定到它。
作者: 清茶, 出处:IT专家网
http://soa.ctocio.com.cn/xwpl/384/8165884.shtml
java060515收录，使用标签：SOA，时间：2008-6-17 12:50:16 | 相关网摘，我也收藏
作者: Heven, 出处:IT专家网
对于开发人员而言，他们无时无刻不面临的问题是：所有的应用程序使用在对于一个很普遍的系统时，即便是在同一时刻不同的团队之间也无法很好的达成协作。这样的问题在2007年初的时候给Leapfrog公司带来了不小的麻烦，当这个玩具公司试图将其多样的应用程序系统应用于供应商和客户，并在两者间取得一致，用以更好的利用以网络为基础的业务交易。Leapfrog公司系统基础设施主管Eugene Ciurana对此说道：正是这样的一个原因让我们决定采用一个全新的方式去开发应用程序，今年3月，也就是SOA开始得以实施的时候，到此为止我们也已经取得了一定的成果。他强调：“我们需要为将来基于网络的基础设施和应用系统奠定坚实的基础，因此，我们一切从头开始。”
在这个过程中Leapfrog公司一直有着一个确定不变的目标，而这个目标也是SOA思想最典型的目标：更大程度的代码重用，更快的开发时间以及更为简捷的集成应用。但是，Leapfrog公司并不仅仅只是打算让简单的让SOA在开发工具和综合应用平台上发挥微乎其微的作用。更多的是他们希望SOA能够在更为广泛的程度上自由发展，从一个领先理念指导的前提出发整合所有平台为一体以达到最佳的效果，从而可以更好的专注于应用程序的功能性并在此程度上最大限度的使用各个开发技术所带来的优势。(Leapfrog公司的开发人员使用的是Java，微软的C#，以及来自第三方库中的Web服务。)
举例来说，Ciurana不希望迫使开发人员使用相同的传输方式。他说道，“如何传输其实并不重要”。他选择使用开源Mule ESB作为通讯支柱，并以此作为解决各层面传输问题之间的关键工具。通过这个途径，“开发人员可以尽可能的减少所需要面对的服务实施问题。”同时，他们可以更多的将精力集中在对功能性方面的实现，这也是他们努力的工作的目标重点所在。这样一来开发人员更趋向于使用HTTP传输协议，当然，REST和SOAP也会是他们的选择。“他们会考虑使用一些项目实现最佳的同时也是最合适的传输方式。” Ciurana对此解释道。在Mule ESB的帮助下，“开发人员不需要担心在他所使用的SOAP栈中有什么独特不能被重用的内容或者是什么样的集成开发环境会是他们使用的。” Ciurana早在Walmart.com的时候就已经使用过Mule了，所以他认为这是Leapfrog公司值得“从头开始”的依据所在。
Ciurana 指出，Leapfrog公司之所以采用这样的作法是因为他们的重点是在如何整合应用。“大部分的整合都是针对于应用层面的，应用程序之间相互访问。整合能够将单纯的输入与输出仅仅停留在这一个层面去解决。”开发人员运用POJOs (plain old Java objects)完成服务组件的书写并将其与Mule ESB紧紧连在一起，并在ESB中完成几乎所有的转换。“通常情况下，当开发人员在使用SOAP和REST的时候，他们需要考虑如何为外界提供一个友好的接口。但是在POJOs的帮助下开发人员大可不用为这个问题担心。”他继续补充道。
对于Mule ESB而言，Ciurana更对它的简单明了情有独钟，它的议程管理已经足够不再需要更多的信息管理功能作为辅助。“所有的厂商都希望能够将他们的产品套件整套卖给我们。但是对于SOA的核心观点而言，对于完全不同的系统是需要友好整合在一起的。” 使用Mule ESB，Leapfrog公司可能需要去面对如何整合各个层面不同的SOA应用，但是Ciurana表示他乐于为此付出代价去换取一个更
具有可塑性的应用，因为这样能够给整个项目的实施带来更多的可能。
Leapfrog公司目前使用两个ESB系统，其中一个用以数据流的管理和应用，这类似于一个ERP系统，一个活动目录或者是一个数据仓库;另外的一个ESB系统则是基于网络的面向客户的应用系统，就如同它的客户帐号管理系统和它向消费者提供的在线游戏。之所以采取这样的分工是确保了所有应用的安全性和存取管理的便捷，同时也可保证数据等其他内容的相互备份，并在需要的时候相互代替进行工作。
Leapfrog公司创造着一种统一的服务计划，并能够在任一的ESB系统中运行，Ciurana强调，这能够保证我们“创建统一的服务接口”。这就使一个开放的ESB所能带来的理想效果。
http://soa.ctocio.com.cn/xwpl/347/8165847.shtml
java060515收录，使用标签：SOA，时间：2008-6-10 16:27:14 | 相关网摘，我也收藏
对于Mashup应用能否作为业务工具的质疑所引发的讨论在近期总是不曾停歇，但是有一点是可以毋庸置疑的，这类产品在近期是不会达到一个较为成熟的阶段，并且在可预见的未来时间里它也很难在业务方面带来翻天覆地的推动作用。在Joe McKendrick的报告中指出，随着其知名度的上升以及市场炒作的不断加剧，一些面向服务架构的倡导者更多的开始参与到Mashup应用的推进当中。
简单来说，Mashup应用的核心思想更多还是通过一种简单的方法，当然我个人认为这并不是一种好的方法，去实现一些典型的SOA应用，而不用更加费力的去建立好一个架构基础。如果所有的发展都是以这样的形式展开，那么长期以来这必定会对整个系统的发展带来不好的影响，甚至会出现一些我们所不愿意见到的坏的一面。McKendrick指出，不管怎么说，一个成熟的，立即可用的Mashup应用(如果这所谓的工具真的存在的话)对于那些计划采用SOA的非技术人员交流时会是一个非常好的卖点。
但从我的观点出发，我并没有看到这一点确实存在。确实，在当前所出售的某些SOA产品中，Mashup应用工具已经是作为其中的一部分交付给了基础的SOA实施，它可以成为一个有效的组件通过适当的交付方式在SOA的兴建中发挥作用，但是它并非是达到某种架构的捷径。我毫不怀疑人们可以尝试用它去建立起一个可靠的面向服务的架构体系，但是更多的人只是在通过各种各样的努力去实现一些类似于SOA但又不是真正意义上面向服务的架构体系，而这些很难归咎于Mashup应用。
作者: Stella, 出处:IT专家网
http://soa.ctocio.com.cn/xwpl/485/8155985.shtml
java060515收录，使用标签：SOA，时间：2008-6-10 16:24:38 | 相关网摘，我也收藏
SOA厂商们最近可谓动作频频，5月22日，普元软件在北京主办了“SOA中国技术论坛2008年会”，金蝶中间件最近也启动了针对SOA解决方案的全国巡展活动，IBM在6月也将会有一个关于SOA的大型会议。与前些年仅仅推销概念不同，如今厂商们更加务实，也更关注SOA的应用。析师曹宇杰看来，虽然经过国内、国外厂商的大力推动，国内企业用户对SOA的认知度已有大幅提升，但对SOA的认可度并不是很高。
要让潜在用户打消顾虑，从认知、认可到形成投资采购，并非易事。不仅厂商在努力探求潜在用户的心理，很多对SOA感兴趣的潜在用户也在试图了解其他同行业、同规模、相似系统状况企业的投资意向。如何才能消除这些潜在用户心中的顾虑?
SOA的潜在用户
业界现在有一种普遍的认识，就是SOA更适合那些信息化发展相对成熟的大中型企业，中小型企业暂时不是SOA厂商们考虑的重点。普元副总裁刘尔洪介绍说：“普元的SOA用户主要集中在一些对信息化支撑要求较高的中大型企业(比如金融、电信)和政府部门。”金蝶中间件总经理蔡军也表示：“金蝶中间件的SOA用户主要集中在电子政务和电子商务领域。这些企业的共同特征主要表现为：信息化发展基础较好，对企业业务流程的梳理有迫切的需求。”
当问到这些SOA厂商心目中的潜在用户有哪些时，刘尔洪用三个特征来归纳这个群体：一是企业(或政府)的运营管理是基于流程化思想，并且对IT支撑依赖较大;二是对IT支撑的敏捷性要求上很高;三是组织层级较多，现在或未来有很多跨组织应用。这三个特征也是他们目前已有的用户所具有的主要特征。
蔡军的回答则更直接。他说：“凡是信息化程度比较高、业务管理比较复杂的企业都应该考虑SOA。”
仅从这些厂商的角度来看，SOA的潜在用户理应是个不小的群体。SOA厂商们本该大有作为，但事实好像并非如此，这又是因为什么呢?
潜在用户的顾虑
计世资讯的曹宇杰认为，SOA在中国尚没有形成一个蓬勃发展的局面，很多潜在用户对SOA仍有着这样那样的顾虑，困扰他们的主要原因如下：
1、缺乏充分的案例
虽然现阶段厂商们纷纷在SOA应用的宣传上大做文章，但曹宇杰坚持认为，SOA在中国的成功应用案例并不是很多，厂商可以拿出来介绍的仅仅只是一些个案，谈不上在某个具体领域获得的成功。这也使得潜在用户的观望情绪浓厚，不愿成为最先“吃螃蟹”的人。
2、SOA本身尚未成熟
除了案例的缺乏，SOA本身的不成熟也是困扰用户的主要原因。如果用户和不同的SOA厂商接触时，就会发现这些厂商所谓的“SOA”存在很大的差异，甚至搞不懂对方所说的SOA和自己想了解的是不是一回事。
曹宇杰对此并不感到奇怪，他认为，在一种技术或理念最终成熟前，肯定会经历这样的一个时期。目前SOA的技术、产品、标准都处于发展阶段，尚不成熟，不同厂商的解决方案也存在差异，这会令很多用户产生顾虑，越是成熟的用户，越是习惯于自己采购选型构建系统的用户，对此问题越关注。
一些公司把BPM、ESB(企业服务总线)这些当作SOA的核心产品，兜售给尚没有搞清楚SOA到底能带来什么的用户是不恰当的。
3、资金问题
一些SOA厂商将无法打动潜在用户的原因归结为价格问题。普元软件CEO沈惠中指出，国内用户对价格的敏感度高，和国外相比，往往期望以十分之一的时间与预算来实现十倍于国外的性能与容量，这样的要求肯定是不现实的。蔡军也认为，SOA需要投入大量的资金和物力来完成。用户在决定选择SOA之前，一定要先考虑自己的经济实力。
4、实施的难度
实施的难度也让很多潜在用户对SOA望而却步。曹宇杰说：“对SOA的潜在用户来说，他们多数已经有了一个相对成熟的信息系统，要改变系统的整体架构并非轻而易举。这种情况下，只有CIO对SOA价值的深刻理解和认可往往是不够的，而是需要系统实现能力与业务需求出现较大差距时，IT系统能全面梳理或升级。只有在CEO的全力支持和推动下，企业才可能全面接纳SOA。不过这类用户一旦部署SOA，通常也会成为全面应用SOA的典型代表。”
蔡军也表示，“SOA落实到企业中需要一个长期的过程。而且时间长，见效慢。实施SOA还可能会引起企业发展中的阵痛，IT厂商能够起到的帮助只是辅助作用，更多的要靠企业在管理、人员等方面把工作落到实处。”
作者: 邢小萍, 出处:网界网
http://soa.ctocio.com.cn/xwpl/282/8155782.shtml
java060515收录，使用标签：SOA，时间：2008-6-4 18:59:05 | 相关网摘，我也收藏
TIBCO软件公司日前宣布，与微软展开紧密合作，在服务导向架构产品上为客户提供更多便利和灵活性，以便更好地结合利用两家公司各自的技术。这也是TIBCO和微软第一次直接面向客户的全面合作，以方便客户充分利用双方在软件领域的现有信息科技投资。
声明表示，TIBCO和微软通信基础的合作将使微软.NET架构战略服务和应用能够利用TIBCO的企业级信息服务平台轻松通信。TIBCO平台让微软的相关应用具有了相应的可靠性和可扩展性。这种特点在双方合作之前是没有的。TIBCO选择微软Silverlight来进行丰富互联网应用程序开发———为有大规模部署和扩展要求的客户提供最佳用户体验，同时完备AJAX的使用。
微软互联系统产品部主任BurleyKawasaki表示，“我们希望帮助客户最大程度地利用他们现有的技术投资，并为他们提供必要的工具和基础架构来实现持续创新。通过与TIBCO合作加强微软通信基础的互操作性，我们将让开发人员更容易跨平台创建服务。”
http://soa.ctocio.com.cn/xwpl/483/8149983.shtml
java060515收录，使用标签：SOA，时间：2008-6-4 18:53:34 | 相关网摘，我也收藏
安全性是较为宽泛的概念，涉及到从端点(服务器和最终用户的PC等)到核心的所有网络层。有观点认为既然SOA是应用级实施，那么只需确保应用服务器和端点提供适当的验证和授权功能以及端到端的安全传输(如SSL)即可。Juniper网络公司中国区总经理张小琳认为，这种认识比较片面，SOA须在四个方面打造安全性。
网络安全性
谈到网络安全性，张小琳认为，业内首先想到的是防火墙。然而，随着端口80/443传输越来越多的web流量，基于L3/4防火墙的传统网络安全方法虽然仍有存在的必要，但却不足以提供全面的保护。需要深层检测并保护这些端口中的流量。因此，必须部署入侵检测与防御专用的应用层安全产品来补充网络防火墙。这些产品可检测到恶意用户或恶意代码(如蠕虫)创建的模式(攻击签名)或异常流量及协议，以防它们利用应用的安全漏洞，从而在攻击到达目的地之前阻断它们。
访问安全性
张小琳表示，远程访问是企业应用中的关键组件。移动用户(包括内部员工、顾问、业务伙伴和客户)需要安全而轻松地访问企业应用，包括互联网上的SOA应用。通过VPN和SSL加密线路来连接企业应用现已成为业界标准，用于确保安全地访问面向公众的应用。业界正在朝着SSLVPN迁移并在SSLVPN上实施技术标准化，以便获得更高的灵活性和粒度更细的控制。使用JuniperSA系列等最新的SSLVPN网关解决方案，管理员将能够利用SSLVPN细粒度的应用、文件和URL级访问控制功能以及客户端安全保护功能，以便基于用户身份和客户端点安全评估结果(使用主机检查器等技术完成)动态控制应用访问。这将使企业能够使用SSLVPN在各种情况下安全地设置访问控制机制。
端点安全性
不仅是远程端点需要安全保护，在办公室外围访问SOA应用的端点也需要适当的安全保护。例如，员工可绕过所有的外围防御措施，将染毒的笔记本电脑轻松带入办公室。这些受感染的设备可发动web服务器攻击并中断网络中web服务的运行。
张小琳认为，端点安全策略执行不当是造成近期大量蠕虫和威胁泛滥的罪魁祸首。缺乏直接控制以及未能合理地执行端点策略使企业屡遭安全威胁，包括最新的防病毒保护机制、主机入侵防御机制、可接受的软硬件配置以及限制程序的运行等。
数据中心安全性
无论是否正在使用SOA，数据中心都需要通过防火墙和IDP等技术得到适当保护。张小琳表示，如果SOA大量使用web服务交易，将带来更繁重的SSL加密负担(https)。在加密/解密以及对SSL交易进行密钥处理时，将生成大量的CPU处理杂务，对CPU利用率产生负面影响，进而影响性能和可扩展性。JuniperDX等SSL卸载产品能够解决可扩展性问题并加密整个应用交易。对于需要端到端加密的环境，SSL产品能够从客户端加密/解密连接，还能重新加密与后端服务器之间的连接，这对负载平衡器和广域网加速器等需要纯文本数据才能运行的其它网络服务至关重要。
张小琳表示，总而言之，SOA的安全风险同时来自内外部。企业中使用Web服务进行互操作的系统对于内外部攻击的防御能力越来越差。当这些系统使用的Web服务由供应商和业务伙伴等外部机构提供时，SOA和web服务的部署工作将变得更加复杂。因此，应全面考虑上述所有因素并谨慎部署最新的安全解决方案，如应用级防火墙、IDP、SSLVPN和SSL卸载产品等，以便为企业中的SOA环境提供安全保护。
http://soa.ctocio.com.cn/xwpl/212/8149712.shtml
java060515收录，使用标签：SOA，时间：2008-6-2 16:25:32 | 相关网摘，我也收藏
JKHL Enterprises (JKHLE) 正在进行一系列的基本业务变更，期望最终能够获得最大收益。JKHLE 已决定采用 SOA 来解决其面临的业务和 IT 挑战。
JKHLE 团队的工作重点是，如何在各个销售渠道中以一致的方式解决因创建新客户帐户而带来的难题。此 SOA 采用计划被称为帐户开立项目 (Account Open Project)。使用 SOA 方法有利于在未来业务发生变化时进行更快的实现和提供更大的灵活性。
注意：有关该案例研究的详细信息，请参考案例研究：SOA 案例研究，第 1 部分：项目启动。
我们在本文中介绍的案例研究包括以下人员和角色：
Sandy Osbourne-Archer，首席技术架构师
Edmund Smythe-Barrett，企业架构师
Kai Buser，集成架构师
Willy Sheng Duo Li（也叫 Willy Li），应用程序开发员
Ursula DeBarry，软件架构师和服务设计主管
Eugene Testrite，质量工程师经理
帐户开立项目的挑战
我们在本文中定义的帐户开立项目挑战与重用作为服务公开的现有应用程序组件、创建新服务和使用服务相关。
Willy Li 是一位应用程序开发员，在其职业生涯之初的前一份工作中，积累了大约两年的 COBOL 编程经验。后来，Willy Li 继续着他的事业，并在 C、C++、Microsoft® C# 和 .Net 方面锤炼了自己的编程技巧。最近，他又开始了 Java™ 编程工作。他从未想到以前的 COBOL 经验会对他当前的工作大有帮助。
在 Willy Li 以前的工作中，他完成了对 Java Web 服务的试验并研究过 SOA 的基本原理。Willy Li 深信，在今后的几年中，整个行业将转向 SOA，所以他准备将职业重点放在 SOA 上。遗憾的是，由于政治原因，他以前雇主那里的 SOA 开发搁浅了，因此，他又去寻找其他的机会。在了解到 JKHLE 中 SOA 的采用情况后，Willy Li 加入了 JKHLE。
Willy Li 被分配到了新组建的帐户开立项目中，该项目由首席技术架构师 Sandy Osbourne-Archer 领导。Sandy 最近派 Willy Li 主持工作，负责服务创建的开发和对现有应用程序的重用。
JKHLE 有许多应用程序运行在现有的系统上，如 CICS® 和 IMS™。因此有必要利用现有系统中的这些资产，以便缩短时间、降低成本。
Wily 当时非常担心对他的工作要求。Willy Li 坦言，“我对 CICS 和 IMS 一窍不通，对 COBOL 的了解也是很久以前的事”。Sandy 劝他说：“别担心，大多数情况下，我们不需要修改 COBOL。在某些情况下，当现有的代码与业务功能不匹配时，这时我们才需要重构代码”。
在重构现有代码方面，可以使用 IBM® WebSphere Studio Asset Analyzer 加强对现有应用程序和资产的理解。当进行重构时，可以像我们在以下部分中介绍的那样，启用应用程序的业务功能。
IBM 将为 CICS 和 IMS 同时提供适配器，并且新版本支持将现有的应用程序作为服务公开。这些访问方法可以在一定程度上提供屏蔽，使您不受 COBOL 和后端系统的影响。Sandy 向 Willy Li 解释说，Willy Li 对 SOA 的背景和理解对该项目非常有用。此外，企业架构师 Edmund Smythe-Barrett 和其他架构师还将提供有关 SOA 采用的全局方案。
在 初次会面之后，各团队领导以非正式方式讨论了他们新分配的任务。Edmund 将讨论他针对企业服务总线 (ESB) 和服务注册中心的计划，并提供对整个基础结构中已计划服务的访问。由于 Willy Li 曾经在前一雇主那里做过 Web 服务试验方面的工作，因此他能够很快看出，与直接链接这些服务的刻板方法相比，使用 ESB 的服务可以提高灵活性。
Ursula DeBarry 是一名软件架构师和服务设计主管，负责设计用于访问和处理信息的服务接口。Ursula 解释，服务设计团队需要一些时间为所需的服务定义准备规范。根据帐户开立项目制定的计划，Willy Li 已经急切希望尽快开始工作，并能做出一些成果出来。
Willy Li 决定，他将通过为后端系统所需的每个访问方法开发服务原型来缩短学习过程。Willy Li 知道，当服务设计团队公布其服务设计规范时，需要更改其原型服务。
帐户开立项目的要求
Willy Li 安排与 Edmund 会面，以审核和讨论该原型实现的要求。Willy Li 尽力确保这些要求体现出公开和使用帐户开立项目服务所需的访问方法。
REQ-01：使用外部服务
帐户开立应用包括的流程需要使用外部第三方服务（如地址验证服务）。
REQ-02：创建新服务
这些服务接口将以 Web 服务描述语言 (WSDL) 文件的形式提供。WSDL 将为所有服务提供一个通用描述形式，实质上对服务使用者隐藏了实现细节。Willy Li 计划根据 WSDL 文档创建一些新服务。
REQ-03：将 CICS 应用直接作为服务公开
将 CICS Transaction Server v3.1 托管的 COBOL 应用程序作为服务公开。Willy Li 了解到 CICS v3.1 包括对 Web 服务的本机支持和工具，这简化了该要求，因此，将很少需要甚至不需要编程。
REQ-04：将 CICS 应用间接作为服务组件公开
Willy Li 了解到，一些旧的 COBOL 应用程序仍由 CICSTransaction Server v2.3 托管，它不包括直接启用 Web 服务的本机功能。此外，JKHLE 需要通过 Java 代码、CICS 适配器和 CICS Transaction Gateway (CTG) 来公开由 CICS Transaction Server v2.3 托管的 COBOL 应用程序还有其他一些原因。这将使 JKHLE 内部系统和外部合作伙伴能够将该应用程序作为一项服务来使用。
REQ-05：使 WebSphere Message Broker 流支持服务
作 为支持电子业务的一部分，JKHLE 在WebSphere® Message Broker上进行了一些投资。它是一个企业应用程序集成基础架构，用于连接 IMS、SAP® 和 Siebel® 应用程序。JKHLE 想通过使 WebSphere Message Broker流（该流提供与基础结构相关的服务）支持服务来使用和重用在 WebSphere Message Broker 中进行的投资。
REQ-06：使 IMS 事务支持服务
使 IMS 事务支持服务可将这些事务作为服务使用。JKHLE 公司想利用他们在 WebSphere Application Server 和 WebSphere Message Broker 中的现有投资。
中间层服务将用来与 IMS 后端系统通信。
本文转自IBM Developerworks中国
请点击此处查看全文
http://ibm.csdn.net/ISN_J.aspx?action=JMP&pointid=2995
http://blog.csdn.net/ibmjournal/archive/2008/05/25/2480017.aspx
java060515收录，使用标签：SOA，时间：2008-6-2 16:02:35 | 相关网摘，我也收藏
1：SOA并非纯粹的技术性方法
如果得以成功执行，服务导向架构(SOA)并非只是一个技术性架构，理解这一点是非常重要。SOA范例旨在于对商业流程进行建模，这些商业流程并不能总是得到技术组件的直接支持。最终，服务可能由技术组件执行，但是商业流程本身要比支持它们的这些服务重要得多。
作为一种技术，SOA是一个工具，虽然这种技术本身没有提供直接的价值，但是与EJB或者.NET组件相比，SOA是一种更为廉价的代码行服务开发方式。另外，SOA应被当作是其它利益的实现者，比如改进更广泛的再利用，提高对商业流程的响应性以及与使商业流程保持更好协调性。
2：SOA不一定意味着网络服务
很多技术人员对SOA存在这样一种误解，认为SOA意味着必需使用网络服务。虽然网络服务可作为SOA策略的一部分，但它并不是必需的部分。服务的定义可以基于除HTTP以外的其它标准。和具体的实现技术相比，关注商业流程和服务的需求更为重要。通常，服务的环境将有助于决定其执行方式。
例如，对于包含了关键商业事务的服务而言，使用网络服务是不利的，因为我们无法通过SOAP/HTTP协议来保证交易。而且，很多服务可能需要异步操作，在这种情况下，基于队列和通道的消息系统可能是进行提供服务的最佳方式。当然，有效负载和界面依然可以使用XML来定义。
3：可以使用现有架构建立SOA
很多组织对于SOA可以使用现行架构来建立感到非常惊讶，例如，.NET和J2EE平台都可为网络服务开发、XML解析与生成，以及与MSMQ和JMS这类消息系统进行通信提供支持。
SOA堆栈常常缺乏流程管理层或自动化层面。不过，许多公司现在已经在企业应用集成 (EAI)工具上进行了投资，很多EAI工具能够提供流程自动化和管理层功能，它们可以从现有的应用程序或在.NET和J2EE平台上建立的应用程序中对服务进行访问。
4：SOA是一种(从组件、对象等)进化而来的方法
服务导向架构并不是一种全新的解决方案;相反，SOA是技术与架构的自然进化。系统架构一直在不断进步，与商业保持高度一致。系统设计师与商家很早就认识到将技术与商业流程相协调的重要性，包括充分应用并合理化技术资源，以及为商业提供更好的支持。
SOA也在一定程度上源于早已有之的企业架构理论。企业架构对技术进行评估，但是更重要的是，它关注整个企业和全部的商业流程并提供了做出技术决策的背景信息。SOA工具则融合了互联网技术，如HTTP和XML，以及综合技术，如消息总线、转译技术和连接技术。
5：流程自动化是SOA的关键优势
许多组织和技术专家错误地关注服务架构内的服务实现与交付，不幸的是，他们没有抓住重点，SOA的真正价值体现在它是一个商业自动化工具。最终，软件和系统将会提高商业或组织的效率，这可以根据组织执行的活动或者流程来定义。因此SOA不应将焦点放在服务上，而应放在流程以及流程的改进上。
当然，我们也需要服务为流程提供支持。但是对于提高效率和改进流程的目标而言，它们是次要的，服务本身的价值有限。
6：SOA架构可能高度复杂
从某一角度看，SOA架构可以相当简单。例如，开发一个商业流程并确定所需的服务，这种要求就合理而直接。但是，要在数据和服务之间进行平衡，并实现有意义的目标则要复杂得多。
例如，假设有这样一种情况：用户使用订单服务在系统中下订单。这是相当简单的操作。但是如果您希望将订单上的数据和来自其它服务的数据关联起来呢?如果所有的服务共享同一个数据源，这时您可以跳过服务层，并生成报告。但是，如果一些数据属于本地服务，一些数据属于原有的主机系统，并且另外一些数据属于商业应用程序(比如SAP)，将这些数据集成在一起将会特别复杂。
7：SOA需要深入了解商业数据
因为SOA关注于商业流程，因此理解这些与流程密切相关的数据至关重要。例如，一个订单流程会包含很多重要的数据项，比如订单、客户、运输信息、发票、付款和收据;更重要的是必须以一种标准的方式来记录这些数据，从而使流程中的每项服务都能以同样的方式理解这些数据。
对于现在拥有信息架构的组织而言，这并不是一个大问题。但如果大型组织没有信息架构或者信息架构支持有限，这一问题会导致实施过程中的长时间中断。因为大型企业通常拥有的数据多种多样，所以一般建议他们采用进化的方式来定义信息架构，即与“大爆炸”方式相反的方法。这意味着不必花费四年的时间来定义数据模型，而只需要在开发服务过程中花费少量时间来定义与那些服务相关的数据。这样，在执行每项服务或者流程时，就可以发展相关的信息架构来包含必需的数据项。
8：服务可简单可复合
定义服务可能是一个艰巨的任务。在某些情况下，我们很清楚需要哪些服务;很多时候，服务相当简单。例如一个查找客户的服务，可能需要使用一些标准来查找用户并为服务的使用者提供标准化的客户记录。
然而，服务也可以复合形式存在。这意味着“超级服务”可以提供一个标准的界面，就像我们刚才查找客户的服务所提供的那样。在前面的例子中，暗指所有的客户信息都存储在同一个资料库中，所以很容易进行查找。但如果一些客户资料存放在大型主机中，一部分存放在SAP中，一部分存放在其它应用程序中，而另外一部分存放在Oracle数据库中呢?让我们假定在每一种系统上已经建立了查找服务的界面。换句话说，我们拥有在大型主机、SAP、其他的应用程序和Oracle数据库上查找客户的服务。我们新的查找客户的服务可以使用所有这些现有的服务来查找客户。现在，因为我们的服务要调用其它服务，它变成一个复合式的服务。当一个自动化流程模型自己成为一项服务时，也会建立复合式服务。
9：SOA的自动化可能有很多层面
自动化可以发生在不同的层面，这是服务架构经常被忽视的一个特点。很多SOA架构的错误在于只看到某一个层面的自动化，然而，在一个SOA解决方案中，自动化至少可以应用到两个关键领域。
第一个也是最明显领域的是商业流程层，在设计流程的时候，其中的步骤已经进行了连接并形成自动化。因为这些流程通常是基于日常商业活动，往往与人类的交互活动有关。在人类交互流程中实现自动化是一个重要的自动化层面。
另外一个重要的自动化层面是没有人参与的系统交互层，过去几年来，集成工具已经应用到这一领域。通过对系统间任务进行自动化，往往可以提高流程的总体效率。
在这些层面上使用不同的工具也是很重要，应该对人类交互、程序或系统间的交互区别考虑，从而采取不同的策略。
10：服务应当遵循相同的界面标准(包括协议和数据)
使用标准化的方法进行通讯对于服务而言非常重要。在SOA世界中，通讯由两个组件构成。一个是服务进行通信的网络协议，就好比是人们每天使用的通讯媒介一样，例如，如果您想和老板通讯，最好搞清楚老板喜欢接电话还是电子邮件。
第二个组件是通讯的数据或者语言，一旦您同意将HTTP或者JMS作为通讯机制，就等于确定了您交流的语言，例如，您的老板说法语而您说英语，可能就会造成通讯困难。在服务领域，通常使用XML作为语言，但这并没有提供足够的信息。必需对服务需要的数据进行清晰定义并达成一致，这样服务提供商与服务用户就能进行有效的通讯。
11：可以将服务外包
服务的另外一个优点就是它们不必作为整体组件购买，不必在内部进行管理，也不必从头进行开发。相反，可以将服务外包。这意味着在您需要一项服务向政府部门提交法规遵从文件时，您不必自己建立这项服务。各类公司为几乎每个产业部门提供各种服务。利用服务外包，您可以将主要精力放在与最重要的SOA策略——流程——上面。
外包方式的一个不足之处在于，如果您的竞争对手使用了同样的服务，您可能会丧失一些竞争优势。
另外一个需要考虑的问题是性能，这依赖于很多因素，主要包括网络连接性、可用性和反应时间。采用外部网络的服务可能会使您商业流程的性能降级。
12 服务可以在现有的系统和软件基础上建立
许多组织误认为SOA方式没有考虑到原有系统，如大型主机应用程序。实际上，SOA的一个最强大的价值就在于它允许组织重新利用大型主机和其它原有资产，这一点尤其重要，因为核心商业逻辑和核心商业数据通常保存在私有的原有系统中。通过服务来访问核心商业逻辑和数据，可以立即在自动化流程模型中重新利用这些资产。
当然，大型主机并不是唯一的原有数据源。微型计算机系统，如AS/400、VAX和HP3000等等，都可以以各种方式提供服务。很多工具都可以帮助与这些所有权系统进行通讯，并将它们的信息作为标准化的服务来传递。
13：性能是SOA系统的关键
尽管SOA为一个组织提供了很多利益，包括协调技术与商业，增强灵活性等;它与性能有着密切的关系。因为在典型的SOA环境中，应用程序往往被高度细分，而程序之间的数据关联也很缓慢，在决策支持和报告系统中特别需要考虑这一点，以往这些系统只依赖少量数据源。
性能最大化的关键在于了解应用程序和系统性能在何处对于商业最重要。构建一个高性能的系统来支持一个并不需要它的商业流程是无益的。一旦确定关键流程，您只需要在有必要的地方改进并提升性能就行了。
14：SOA以四个组件为基础
一个成功的SOA交付计划有四个组件。第一个组件是定义商业流程，需要哪些服务来支持它们，以及哪些数据与它们相关。这是关于SOA的商业分析。
第二个组件是SOA的架构和模式，这是一组描述如何定义与实现服务的规则，指定通用的交付与使用模式，并制订开发服务需要遵循的原则与标准。
第三个组件是SOA的基础结构，这包括网络、服务器、存储设备、消息工具、整合工具以及流程自动化工具等等，它们支持服务与商业流程的开发与交付。
第四个组件是SOA的开发计划。该计划确定了服务开发与流程实现的先后次序，并且指导形成新服务与新流程项目。
15：建立SOA可能相当麻烦
尽管SOA是一个进化性技术，尽管在SOA领域已经具备相当丰富的知识储备，但由于各种原因，建立SOA仍然相当麻烦。最主要的原因在于SOA和其它变革一样：它需要大量的沟通与社会化，使组织为变革做好准备。
在克服了变革的困难之后，还可能有其它技术性问题。这些问题包括建立适当的服务交付和使用模式、培训技术开发团队、以及为支持SOA开发模式对组织进行的可能的结构变化。尽管SOA的技术组件可以在隔离的环境下进行测试和验证，SOA依然是一个全企业参与的方法，因而需要付出更多的努力来规划服务架构的控制与管理。
http://soa.ctocio.com.cn/xwpl/64/8146064.shtml
java060515收录，使用标签：SOA，时间：2008-5-29 15:13:36 | 相关网摘，我也收藏
通过一个进行实际性能测试的样例，通过对有铺底数据和没有铺底数据两种情况的测试结果所进行的分析，我们发现，使用铺底数据进行性能测试，不仅可以帮助测试人员更好地发现应用系统存在的问题，同时也能够使测试结果更加接近真实生产环境下的结果。
本文假设对某大型 SOA 系统进行性能测试，要保证所有在线用户能同时在线录入档案。测试场景包括创建成员信息、收入及支出信息和提交救援案例的申请等。
在这个系统中，性能测试需要模拟很多人同时在线的情景。通过性能测试工具能模拟任意多的人同时在线，而且要保证系统性能稳定，不论任何时候都要保证系统的请求和响应时间基本保持稳定，不会随着数据库数据的增加而变慢。基于这些问题，我们需要找到一种有效的方式来对系统进行性能测试。在上面的场景中，需要一个长时间稳定的环境，这样才可以增大数据库里面的数据量，并构建负载平衡的应用服务器环境。
综上所述，可以在数据库里面存入铺底数据，在服务器端搭建集群服务器。
为什么要准备铺底数据
那么，我们该如何制作铺底数据呢?下面我们将详细地阐述这些问题。
铺底数据就是我们在做性能测试之前，在数据库里除数据库字典表外按照业务逻辑存入的大量的数据。这些数据可以被视为垃圾数据，因为它们对系统的业务逻辑没有实际影响，但对系统的性能却有着很大的影响。
我们需要按照实际的情况去生成铺底数据，而且这一过程要符合实际的生产情况表的数据比例。譬如：有一张表的数据量和另外一张表的倍数关系是 5∶1，那么准备数据的时候不论准备的数据是多少条，也需要保证这两个表的数据量的倍数是 5∶1。
虽然铺底数据是垃圾数据，但是它们同样需要遵守数据库中数据的依赖关系。比如一对一、一对多的关系等。
我们在性能测试中准备的数据如“性能测试之前在 DB2 里面准备的铺底数据表”所示。
在性能测试开始之前，我们在 DB2 数据库里面准备的铺底数据的总量是10.5 GB。
或许你会问，为什么要准备这些铺底数据?这些数据不是我们实际生产环境中出现的数据，那为什么要花时间去准备如此大量的数据呢?答案是，系统在有铺底数据和没有铺底数据的情况下，性能会有很大的差异。那么，为什么会出现这种情况呢?
首先，如果没有那些铺底数据，那么，本来为一张表建立了一个索引，当系统的数据量很小的时候，数据库就有可能进行全表扫描，而不是索引扫描，因此，如果没有铺底数据的话，有可能会造成系统发生数据库的死锁。
如果数据量比较少，数据库为了优化，有的时候就不用索引扫描，而采用全表扫描，这样造成整表被锁，导致死锁。而数据量大了以后数据库会进行索引扫描，不会锁住整个表。
所以，在有些情况下，系统上线时必须要准备一些无用的数据放在表中，让数据库不会采用全表扫描。虽然有的时候可以通过改变锁的策略去解决这个问题，但是如果存在风险，在上线系统中就要避免。
其次，如果数据量很小的话，我们不知道进行一次查询的时候， SQL 语句究竟是哪种执行路径方案。数据库有自动根据 SQL 语句算出一条自认为最优化的路径的功能，譬如 DB2 的 ACCESS PATH。ACCESS PATH 会随着数据量多少的变化而变化。一旦系统的体系结构比较庞大，那么，在日积月累中数据量会越来越大。所以要准备一定数量的数据，让 ACCESS PATH 保持相对稳定。
因为，铺底数据使得系统性能更加真实，更符合生产环境的真实情况。在数据库里面存入铺底数据，系统从一开始上线的时候，就有了一个比较稳定的环境。
如果没有铺底数据，那么系统的环境可能随时都会面临着不稳定的因素，如性能陡变、数据库异常、响应时间突然下降等。所以准备铺底数据，不但对性能测试意义深远，而且对即将上线的生产环境也是至关重要的。试想在银行系统中，如果不准备铺底数据，一旦系统上线的时候发生了问题，那么银行会损失多少客户。
准备铺底数据主要有以下几个原则：1.数据库中的数据量只要比内存大上若干倍，结果就差不多了;2.数据在准备的时候，要保持原表的约束关系;3.每张表的数据量要符合真实情况。
在理想的情况下，性能测试的环境最好能够完全模拟真实应用部署的环境，以便于通过性能测试得到应用在真实生产环境下的性能结果。然而，由于真实应用部署环境的规模比较大，上述思路是不实际的。因此，为了能够得到更具真实性的性能结果以及更好地发现应用存在的性能问题，我们在测试中采用可控制的测试环境来尽量模拟真实环境，其中也包括对历史数据的准备。在我们的测试环境中，为了更好地分析数据库和应用本身的性能问题，如 I/O 问题，将 WPS 和数据库将分别安装在不同的物理机上。
首先通过 HTTP 请求到 HTTP Server ，再进入 UI 层，然后通过 UI 调用 Web Service，Web Servive 再通过 HTTP Server 调用 BPEL 和 WSDL 文件，再通过 JDBC 连接 Database，并用 Content Manager 存入一些文件(如 PDF、Word)到 Database 上。
用 IBM HTTP Server 做 HTTP Server，并在WebSphere Application Server 上搭建 UI 层，将 BPEL WSDL 搭建到 WebSphere Process Server 上，然后用 DB2 做 Database。现在，我们所需要的整个测试环境就基本搭建完成了。
分析测试结果
通过分别对没有铺底数据和有铺底数据的情况进行相同的性能测试，我们发现测试结果有很大的区别，主要表现在页面平均响应时间方面。
经过测试，在没有铺底数据的情况下，页面平均响应时间是 58.552ms;而在有铺底数据的情况下，则是 608.344ms。从Rational Performance Tester 生成的测试报告中，我们可以清楚地看到每个页面的平均响应时间。
从两类页面平均响应时间的对比，可以看出在有铺底数据的情况下，平均响应时间高于没有铺底数据的测试结果。经过查找问题根源，发现在这两个页面中，由于在数据库中进行了大量视图的创建和 Select 语句的操作，导致了响应时间比较长。
因此，从上述比较结果中我们可以看出，在有铺底数据的情况下进行性能测试，能够帮助测试人员更好地发现被测应用系统存在的问题。
另外，一般应用在真实情况下的生产系统中运行时，都会存在大量的历史数据。因此，我们在测试时就需要加入铺底数据，这样不仅能够得到更加真实的测试结果，而且能够及早发现应用系统中存在的隐患，从而避免在系统正式运行后才发现问题给后续工作带来很大麻烦。
通过一个进行实际性能测试的样例，通过对基于 WebSphere Process Sever 的应用程序性能的测试，通过对有铺底数据和没有铺底数据两种情况的测试结果所进行的对比与分析，我们发现，使用铺底数据进行性能测试不仅可以帮助测试人员更好地发现应用系统存在的问题，同时也能够使测试结果更加接近真实生产环境下的结果。
作者: 陈鑫 陈芳, 出处:赛迪网-中国计算机报
http://soa.ctocio.com.cn/xwpl/364/8141364.shtml
java060515收录，使用标签：SOA，时间：2008-5-29 15:11:09 | 相关网摘，我也收藏
SOA联盟宣布称，日立已经加入了SOA联盟。这是第一个加入SOA联盟的日本机构。SOA联盟是最终用户、服务提供商和技术厂商的一个倡导组织，致力于帮助全球1000强大企业、主要政府机构和中型企业在2010年之前成功地应用SOA。SOA联盟的发起人公司包括思科、惠普、IBM、SAP、Savant、Sparx Systems和Sun微系统公司等。
SOA联盟执行主任Richard Mark Soley博士说，我们非常高兴欢迎日立公司加入SOA联盟。在我们努力把SOA作为一种商业灵活性的故事推广到这个快速增长的社区的时候，日立的经验以及它与日本市场和其它地方的关系对于我们来说有无可估量的价值。
日立信息和电信系统部门首席战略官Masahiro Kitano说，我们看到日本和全球市场对于SOA的灵活的企业系统的需求正在增长。SOA联盟是共享最佳做法、案例研究和SOA经验的最佳地方。这些共同的知识将使所有需要为未来的企业或者技术变化做准备的加入这个联盟的厂商受益。由于日立集团的一个成员公司日立顾问公司在美国，日立很高兴作为一家在日本推广SOA技术的公司。
作者: 东缘, 出处:IT专家网
http://soa.ctocio.com.cn/xwzx/319/8141319.shtml
java060515收录，使用标签：SOA，时间：2008-5-28 16:19:54 | 相关网摘，我也收藏
作为一个时代标志，SOA越来越广泛地影响着企业在建应用和既有环境的IT布局。在SOA理念的指引下，IT的计算能力、业务应用的协作关系以服务的方式呈现出来，其应用的实质体现在“业务敏捷”方面。站在这一角度，SOA为我们呈现了一个美好的场景，但其不足之处是，没有强调具体的实施步骤。
通常而言，企业的SOA实施需要结合市场上一系列的SOA产品，并遵循一定的流程和步骤。常规的SOA实施步骤包括，打通上层路线;融汇企业业务规划的长短期目标;提高并统一认识，明确SOA建设目标;设立组织建制;梳理既有资源，完成概念上的现有服务布局;查找差距，包括自身差距以及合作伙伴对双方业务链预期IT能力的差距;规划IT布局;完成企业服务总线(ESB)以及关键服务的梳理和部署;基于SOA环境编排业务，查漏补缺。除此之外，SOA的实施还需要一个全程治理的保证体系。
理念与现实的差距
这样的步骤基于一个假设，即开发、运维以及相关的技术产品是跟着业务发展跑的。很多时候，大部分SOA产品(或框架，可以视为另一种由松散组织开发的产品)都声称他们具有不错的适应能力。而且是从业务角度出发，在“查漏补缺”之后以更加灵活和便捷的方式使企业获得SOA所带来的业务敏捷性。但是从SOA产品(或框架)交付的角度来看，由于其面对全球所有客户的应用环境，而且实际上是更多地关注技术共性问题的解决，因此，虽然可以较快地适应企业的业务变化，但对企业自行的开发和运维而言，其推进的速度还是相对滞后。
现实中的事实与SOA理念所倡导的业务敏捷性之间为什么会出现落差呢?笔者认为，SOA产品“先入为主”的交付模式误导了企业的系统架构设计。这在那些高端SOA产品身上体现得尤为明显。这些产品总是试图将必要的基础环境和高层业务视图打包提供给客户，通过捕捉IT运行中的事件和关系，面向业务流程地从高层完善企业的IT技术架构。但实际上，企业内的运行过程，本身就不是一成不变的，它主要包含规范化流程、企业自身变化流程及业务环境变化流程这三类流程。
其中，规范化流程是指流程本身是规定，且完全由企业自身主导或是获得合作联盟、行业明令认可的流程。这些流程中实践、业务对象实体状态的变化，在一定阶段内是相对静态的。
企业自身变化流程则涉及许多动态元素。通常情况下，业务部门总是先于IT部门发起各种变化，这些变化可能来自于一位新任CEO，也可能来自某个新业务领域的大客户。而即便没有这些因素，企业自身的财务和销售渠道的运行也并不总是顺畅的，用IT术语描述就是“上下文”(Context)总是在变化。虽然从SOA产品角度看没有新的流程和事件约束出现，但业务却在经历实实在在的变革。
业务环境变化流程的产生原因更加多种多样。例如社会突发事件对企业业务运营的影响。这些变化并不在SOA产品所覆盖的范围之内。更确切地说，虽然借助各种SOA产品可以快速地找到服务的替代品，但那是企业对外的服务需求，而业务环境的变化所要求的是企业自身服务的变化，这些不是通过某些SOA产品就可以获得的。
因此，虽然我们按照上面的实施步骤可以利用SOA产品完成一个“SOA项目”，但这种做法很容易误导我们对“业务敏捷性”的实践。事实上，现阶段SOA产品支持的是瀑布型的建设过程。但正如我们所知，虽然瀑布模型对于规范化流程有着不错的规范作用，但对于企业自身变化流程和业务环境变化流程就不是非常适合了。
SOA实施需要动静结合
如果类比其他工业，我们会发现，现在市场上SOA产品所倡导的建设理念高度类似于早期的兵器工业。如果需要快速武装一支部队，那么需要每个工厂加班加点生产自己的毛瑟枪(整枪)。但是这往往要求一个动态的流程，而且流程需要根据内部和外部制约因素的变化做出相应的调整。为了全面满足三类流程，实施者需要经历如下两个步骤。
1. 将毛瑟枪的零件全部标准化，让更多的企业参与到各个零件的生产过程，最后由少量企业专门负责组装这些由不同企业生产的配件。将此过程映射在SOA建设中，就是首先把每个信息“孤岛”内的公共能力抽象为服务，并以服务接口的方式对外暴露，然后通过SOA产品完成新服务的组装(或称之为业务流程编排，Orchestration)过程。这个过程主要解决的是规范化流程的问题。
2. 改变每个协作企业的处理方式，变任务指派为竞标方式，每个企业根据自身的生产能力和外部购买要求(即业务事件)，以竞争的方式提供服务，积极发掘市场中的长尾和增值内容。映射在SOA建设中，就是需要在现有“计划性”治理之外，提供虚拟的业务事件能力。至于实际反馈客户的服务结果，则是由消费这些虚拟事件的服务根据事件预定情况、参考当前业务环境和外部制约因素之后联合提供。
必须强调的是，第2个步骤才是SOA建设更加符合“业务敏捷性”精神的关键。它基于动态的前提，而非现阶段SOA产品中所普遍采用的“汇总→集中化→固定→静态组装”的思路。要达到“动态”的目的并不简单，起码对SOA产品而言，要更多融入反馈和自适应系统的设计思路。它要在服务注册器和ESB之上实现服务间、服务对业务变化、服务对外部制约因素可以理解的事件机制，并且ESB可以根据动态的事件预定自动协调各个服务。
立足企业高层架构的角度，SOA建设不是现有SOA产品所描述的这些静态服务环境所能完成的。它们不足以承担业务服务建模的工作，只是基于业务事件执行模型的功能模块而已。这些产品所要求的稳定化内容恰恰与SOA的“业务敏捷”本质相背离，但可以利用其完成服务环境的治理工作。
http://soa.ctocio.com.cn/xwpl/257/8136757.shtml
java060515收录，使用标签：SOA，时间：2008-5-28 16:14:01 | 相关网摘，我也收藏
是什么让BPM和SOA联系到一起，并受到分析师们的更多关注，甚至还成为了业界新闻呢?
SOA(面向服务的架构)是一种企业级的IT架构方式，它把IT资源作为与业务协调的服务来提供，从而满足业务要求。但大部分的业务领导者并不关心SOA具体是一种什么理念，可以实施什么新技术，而只关心能不能改善他们的BPM(业务流程管理)。现在早已过了SOA的概念普及阶段，对用户来说，拿什么做SOA的切入点才是他们所关心的。
再来看看BPM，与其说它是一项技术，不如说是一门商业学科，要确保 SOA能够提供商业价值，它就必不可少。在Gartner新近公布的“2008年十大战略性技术”中，业务流程管理名列其中。BPM在经历了数十年的发展后，如今，正悄然掀起一场流程管理的热潮。
BPM效益在哪里?
以前，其他部门人员去财务部门报销时，要么就是少了发票，要么就是少了审核人或者审核人不对，甚至有时候没有采购单等相关工具。财务人员不给审核，他们就跟财务人员吵架，说财务人员臭摆架子，有的还去老总那边打小报告。久而久之，同事之间渐生龃龉。
再举一个例子。某家生产企业样品管理很不规范，有时候，为了能及时把货交给客户，销售人员竟然直接把订单拿给研发人员生产。我们都知道，研发部分的耗费都是不直接计入到生产成本中去的。到了年底，研发人员一统计费用，吓了一大跳，怎么会这么多?不仅如此，这个费用还影响到了研发人员的考核，他们自然不愿意销售人员把本来应该是生产部门生产的订单，拿到研发部门来生产了。长此以往，两个部门的扯皮现象就越来越严重了。
第三个例子：一家从事电线电缆的制造企业从国外进口了几件全自动的生产机器，可以生产不同颜色、规格的电线。因为同一台机器放入的PVC颜色不同，生产的电线颜色也就不同。为了防止色差，要求在换PVC进行生产前，必须对机器进行彻底的清洗，同时，对于换过PVC后生产出来的电线，要进行首件检测。虽然管理人员多次强调这个流程，但却一直很难实施。
BPM怎么改善这些矛盾?
首先规范报销的相关制度，规定具体哪个部门的费用要由谁审核才能报销，再根据报销费用的多少设置从部门经理到财务总监、总经理等多道审批权限，并且设置代理人制度，以确保当相关领导人出差时，相关的费用也能得到及时报销;再者，对于报销的单据也要进行详细设置，如给差旅费用的报销