业界需要XML网络服务开发工具

互联网改变了一切,包括对开发工具提出了全新的需求。我们能否继续创新并获成功取决于我们能否认识到这些需求,以及能否开发出相应的互联网产品以满足这些需求。未来的工具将为这样的应用量身打造:在这种应用中应用程序由各种服务的集合组成,而不是由静态软件模块群组成的。

互联网改变了应用程序的基本概念。几十年来,应用程序都是“单起炉灶”,即每一个都自动完成某个特定的业务功能(例如,库存检查应用程序或发货应用程序)。随着互联网的发展出现了应用程序入口的概念,它给客户或供应商提供可能需要的各种服务。毕竟你不可能要求客户到这个网站上订购东西,到另一个网站上更新客户信息,然后再到另一个网站上查看发货状态。所有这些服务需要在一个站点上提供,并且给用户提供单一的界面。当今互联网应用程序的互联特性给应用程序的集成增加了不少富余度。

尽管工具不完善,但许多组织在迅速将它们的旧有应用程序转化成可被任何新应用程序访问的网络服务的集合。事实上,他们正在构建一系列互联业务服务。只有少数组织已实现了这一目标,但他们都在积极行动,其目标非常清楚:使所有的服务都可以互相访问并可被任何应用程序的前端访问。相比上一代的客户机-服务器应用程序来说这是一个根本上的转变。

在客户机-服务器的情况下,基于服务器的数据库是多个应用程序的中心。每个应用程序的业务流程都是单独构建和部署的。要由数据库来确保每个应用程序所用的数据是当前数据。当下了一个新订单时,要在库存数据上放一个相应的已订数据,以便另一个库存检查应用程序可以反映实际库存减去“已订但尚未发货”的项目。数据库锁定处理多个应用程序之间的数据冲突问题的方式和它处理同一应用程序的多用户的方式一样。

与此相反,在以网络服务为中心的架构中,商业服务以对等模式互相联系,既可以向其他服务提出请求,也可以响应其他服务的请求。每个服务可以有它自己的数据库,或者与其他服务共享一个数据库。

借助一个服务架构,多个应用程序可以在服务层面上调整他们的互相依赖性,而不是依靠底层的数据库。这种互联性是网络服务模式的核心。事实上,这种方式相当于在任一给定时间都为某种业务建立一个实时的跨部门的模式。因此它比企业资源规划(ERP)软件包功能更强大,因为它更具模块化且更灵活。

许多组织正在通过费时费力的基础结构层的编程来将各种千差万别的软件模块拼凑到一起,以建立一个服务架构。如今最紧迫的挑战是为这些组织提供一套工具集,它们要能自动完成大量与创建网络服务相关的工作,同时还可集成原来的应用程序。市场需要的是具有以服务为中心能力的第二代互联网工具。

看起来很多人都认为“可扩展标记语言(EML)”将会是允许框架内各种不同的服务交互操作的混合语言。新一代的工具将提供简单的方式来创建新服务和包装旧有专用系统,使它们既能“说”又能“听”XML信息,以便以对等方式提出和响应服务请求。

交换数据元素

不过,XML本身并不是全面的解决方案。在XML中,可以有很多方式来表示同样的数据元素,这意味着某个服务可以发送一个XML表示的数据元素,例如客户名称,而另一个支持XML的服务却不能理解它。

若干集成工具已经提供了各种数据转换功能来消除这一局限性,它们可在同一数据的不同XML表示之间进行映射。为了在各种平台混杂的环境中实现XML数据交换,一种可将这些数据进行转换的标准方案已经出现,它就是“可扩展样式表语言转换”(XSLT)标准。

无缝转换

数据转换使一个应用程序的数据可被转换以便用在另一个应用程序中。例如,常见的转换问题包括,一个应用程序需要“年龄”作为输入数据,而另一个应用程序只能提供“出生日期”。从出生日期得到年龄不仅需要解决不同含义和数据格式问题,可能还需要一些计算。

采用XSLT进行转换的优点是,转换规则和应用程序的编程能清晰地分离,同时它和XML是无缝集成在一起的。通过支持XSLT,新一代的网络服务工具将能确保数据可以方便地在所有业务服务中传递。

XML还将越来越多地用于各种分布式客户机与后端服务的通讯中。这进一步把前端的开发与企业服务的开发分离。它还将为更容易地支持现代无线与嵌入设备奠定基础。从这些设备中将诞生新一代的前端工具,它们将使用XML来简化与网络服务的通讯。通过这种方式,这些服务将能够支持HTML台式机以及层出不穷的现代客户机。

确实,单一的服务,例如股票交易,可以同时支持多种类型的前端。XML是这种架构的基础,它支持服务之间的互联,同时它支持的可以访问服务的客户机类型最多。

基本上,每个服务都将有一套描述运行环境的属性,因此开发人员无需事先指定该服务将运行的特定硬件/操作系统平台或使用特定的网络协议,或甚至特定的应用程序服务器,就应该能够创建一个服务。然后,在部署时,工具可以查看目标部署环境并针对其专有特性对代码进行优化。

这种方式将提供可移植性,它还将增强性能,特别是在各种软件层智能地互相借用的集成软件堆栈中。

开发人员如何知道对某个应用程序来说什么服务是可用的？当然,开发人员可能知道其他小组成员以前构建的部件或者储存在本地开发库中的部件。

但对组织内其他小组构建的部件以及那些可从第三方购买的部件如何对待？解决这一难题的基础是“通用描述、发现与集成”(UDDI),它是描述可用部件的协议,以及“简单对象存取协议”(Soap),它是发起与UDDI设备的会话的协议。

调用方法

Soap通过允许应用程序调用驻留在远程服务器上的对象方法或函数简化了对远程对象的存取。Soap应用程序用XML创建请求块,同时提供远程方法所需的数据以及远程对象自己的位置。

因此,网络服务工具将需要使用诸如Soap和UDDI的工具来发现部件描述,不管它们存放在哪。在支持服务的复用方面无疑将会有进一步的发展,但看起来UDDI基础将提供一个对元数据的通用存取方法,元数据用于确定是否有以前开发的代码可用以及若有则如何存取它。

网络服务将各种层次种类的软件连到一起,而符合标准则是确保不会出现新的专有边界的关键。确保未来成功的一条途径是尽可能利用公开源代码的软件。公开源代码可以让软件开发商参与开发多个供应商的解决方案,同时相信谁都不会改变底层基础。它还允许用户组织扩展开发框架以满足他们自己的特殊需求。未来的开发工具很可能会基于公开源代码的工具框架。