将 SOA 引入 Office 应用程序桌面
【导读】当今的企业都希望将 SOA 作为一种公开其应用程序和数据以便于用户使用的方法。
现在,使用现有开发工具在这些服务上构建解决方案非常容易。通过使用 SOAP 或 WSDL
之类的标准,不同的供应商可以提供在这些服务上进行公开和开发的工具。但是,当企业
开发了一些解决方案之后,问题就开始暴露出来。本文将重点说明一些最常 见的问题。
简介
当今的企业都希望将 SOA 作为一种公开其应用程序和数据以便于用户使用的方法。通过
采用 SOA,企业资产(例如,业务流程应用程序或后端系统)可以由在这些资产公开的服
务上构建的各种解决方案/应用程序使用。在这里,您可以将企业视为一组公开数据集或功
能集并在其后封装业务逻辑的服务。
现在,使用现有开发工具在这些服务上构建解决方案非常容易。通过使用 SOAP 或
WSDL 之类的标准,不同的供应商可以提供在这些服务上进行公开和开发的工具。
当企业开发了一些解决方案之后,问题就开始暴露出来。以下是一些最常见的问题:
1.解决方案只能使用一次。它们只能与一个或一组预先定义的服务进行通信,并且解决方
案本身难以重用。更改服务后需要重新构建/重新部署解决方案。
2.对服务所公开的内容的理解取决于人们的想法,而不是服务定义本身。当前的标准只涵
盖了如何获得那些服务。
3.很难将不同的服务集合在一起。既没有预先定义的聚合机制,也没有关于一个服务如何
与另一个服务相联系(服务彼此之间不了解)的定义。
4.按照大多数常见的用户标准来说,解决方案 UI 难以实现,而且通常很槽糕(除非进行
巨额投资)。这是因为难以在一次性解决方案中模拟当前的应用程序 UI。
5.大多数用户都相当熟悉 Oce 套件(Word、Excel、Outlook 等)之类的应用程序,
但是当设计出一个新的应用程序/解决方案后,需要对他们进行培训,从而增加了此类部署
的成本。
由于上述原因,我们需要一个在现有服务之上构建解决方案的更好的机制。
元数据方法
目前,Web 服务公开了许多有关如何使用服务的信息,但在说明提供了哪种类型的信息
或功能方面,却提供了非常少的帮助。Web 服务通常会公开 WSDL,因此工具可以轻松
地查明 Web 服务公开了哪些方法和参数,但是,至于在那些方法后定义了哪些业务实体、