协作，“让我们畅谈”

申请免费试用、咨询电话：400-8352-114

协作，“让我们畅谈”

协作应用使得下一代企业应用将利用Web服务相互“交谈”，实现比点到点互动更多的功能。

协作，“让我们畅谈”

下一代企业应用

由于协作应用使多种应用和数据源可以“交谈”，因此协作应用具有很多优势。

灵活性：应用是透明的，因此企业可以先定义业务目标，然后再开发容易改变并随意处理的组合应用来支持它们的目标。

优化：消除了对点到点集成的需要，应用开发人员可以更迅速地对企业用户需求做出应答。

部件可重用：企业无需重新编写代码就可使用已有的业务逻辑。

择优性：可以部署不同的企业应用程序，不必保持完整的套件。

无附加条件限制：应用是独立于传输、独立于平台的。

下一代企业应用可以消除传统的限制，打破功能分割条块，将客户、供应商、财务应用以及公司防火墙内外的其他应用无缝地连接在一起。在越来越多的数据以XML形式发布并通过Web服务连接在一起的情况下，企业正寻求将条块分割的业务过程捆绑起来，利用已有应用的最佳部分解决业务问题。协作应用就是这样一种“下一代企业应用”，这类新兴的协作应用将来自多种应用系统的功能组合起来，执行一个可作为Web服务发布的规模更大的近实时过程。

企业将不再需要定制业务过程和工作流来适应自己的erp系统参数。相反，它们将首先定义业务目标，然后再开发容易改变、可随意处理的复合应用来支持随企业发展而变化的目标。

关注应用

随着这种新兴模型的演进，厂商纷纷设法通过不同的方案支持协作应用的基础设施搭建，支持这种下一代企业应用。传统的EAI(企业应用集成)厂商正在他们的专有平台上开发业务过程来管理这类增值服务，而应用服务器厂商则迅速通过提供集成服务来支持Web服务。此外，Oracle和SAP这样的企业应用级厂商将他们的应用以XML的形式发布并在产品之间建立更紧密的集成，还有一些另类厂商则将重点放在为Web服务定制应用和为Web服务开发新应用上。

传统的EAI厂商，将宝押在了业务流程管理引擎和各种Web服务上，他们认为Web服务第一次真正有希望提供一种实现协作应用模型独立于传输、独立于平台和独立于防火墙的途径，但是将Web服务串在一起不是一个应用所能做到的，Web服务缺少的要素包括事务处理性、安全和管理,这些要素成为在防火墙之外采用协作应用的障碍。

一些厂商则选择了利用一种更加分布式的方法实现协作应用，而没有选择集中式代理实现集成。例如，北美Sonic Software公司的Sonic XQ产品是建立在基于Java的消息架构基础之上的，这种架构将向企业的特定部分传送叫作ESB(企业服务总线)的“轻型”服务容器。

业界人士分析，与数据不同，这类下一代企业应用将安装在主要受企业功能和过程驱动的服务架构中。在一个面向服务的架构中，企业可以调用服务在网上下订单和执行原始逻辑，而非来回传送数据。

无论采用什么形式，协作应用都将对SCM(供应链管理)和B2B特别有价值，因为SCM和B2B过程依赖于来自多个来源的数据的组合和互动。例如，一家拥有多种产品线的跨国公司(每种产品线都有自己的来自不同厂商的销售系统)可以将一个Web服务附加到每个系统上并建设全球销售立体网络，从每个系统提取数据，以获得一种销售信息的复合视图。

协作的挑战

ISV正在破解协作应用的难题

来自集成和应用开发领域的厂商正在应对协作应用的挑战，开发他们希望将成为开发下一代企业应用平台的新中间件层。他们的努力最终将使企业摆脱采用专有API的点到点集成，向一种基于标准的、松散连接的和业务规则驱动的软件层发展，这种软件层使企业能够将已有系统组件连接在一起构成协作应用。

但是，若想使协作应用发挥作用，就必须解决几个棘手的问题，这些问题包括数据转换、业务过程协调和事务处理性。目前的努力，主要建立在已有开放系统接口(如XML)上，是过渡性的步骤，一旦SOAP(简单对象访问协议)和WSDL (Web服务描述语言)等Web服务接口和协议得到普及，将出现一种更加面向服务的实现方法。

数据转换与同步

尽管许多遗留系统和套装应用程序采用XML，但是令人失望的是，它们的数据模型和方案是不同的。例如，在SAP系统、自编订单管理系统和SCM(供应链管理)系统中，“订单”或“客户”的定义可能会完全不同。此外，许多企业除了最初编写系统程序的人员的记忆外，没有保留全面的数据字典。因此，企业词汇管理—将来自多种系统的数据映射和转换到单一且一致的方案中是协作应用平台开发商面临的最困难的问题之一。

管理过程流

阻碍协作应用开发的另一个障碍是缺少描述和协调分布在多种系统上的业务过程流的标准。人们现在基本上是将各种应用串在一起，而不是以更加单独的方式编写它们，因此建模和过程流问题变得更加重要。

解决这个问题的多项标准正在制定中，Microsoft的XLANG、 IBM的WSFL(Web服务流语言)和来自业务过程管理计划的BPMI是人们密切关注的三个竞争标准。同样，ebXML(电子商务XML)具有一个业务过程部件，但它是基于对象模型的，因此缺少对松散连接的过程的抽象。

事务处理

第三种挑战将是为跨多种后端系统事务处理提供支持。事务处理定义还必须与过程流定义一致，使事务处理可以退回到过程中的合适的颗粒度水平上，而这种水平必须与安全模型中的颗粒度水平联系在一起。一种实现方法是XA。XA是一项建议的W3C标准，它可以在跨多种系统进行事务处理时锁定系统，以保证交易的完整性。

基于XML的协作应用的另一个问题来自事务处理的性能。在进行高容量事务处理时，CORBA或Java RMI(远程方式调用)可能比基于XML的应用效率更高，因为全文本XML文档占用更多的空间。

现在，所有厂商都认为某些技术组合——面向XML的中间件、传统的发布-订阅消息技术以及面向服务的Web服务架构将是完成工作所必须的。企业希望利用其已有应用组件，希望业务逻辑处在中间件中而非端点上，需要独立于任意厂商控制的中间件并且不愿意为每个新应用程序编写大量费用昂贵的定制代码。协作的实现，能够解决这一切！

协作应用

协作应用，即组合多种已经应用的功能或信息，在Web服务的支持下，这类应用将使企业在需要时，可以迅速地通过将信息组合在一起来创建和改变应用，应用可以受业务需要驱动，而不仅仅受数据驱动。