设计以网络为中心的计算和控制产品的开发人员必须应付产品本身的一大堆实现问题,同时还要面对一系列与外部的连接问题,以及许许多多的编程语言和环境。为了降低这种复杂性,业界正在几个前沿领域开展行动以推广“Web服务”概念,所谓的Web服务也就是可在整个Web空间上进行互操作的互联网应用。
Web服务采用模块化结构进行设计,它们可以很多种方式组合起来,而且几乎可以为在Web的任何位置上提出申请的客户提供服务,以完成一项本地任务。不管在客户机或服务器上运行的应用采用何种语言,程序员现在所看到的仅是一个提供服务的统一机制,它基于可扩展标识语言(XML)和简单对象访问协议(SOAP)。
尽管这个新兴的框架已经出现了破裂的迹象(因为一些竞争对手在开发无法互操作的互联网应用),但许多人仍然相信Web服务的思想还是很有前景的,因为它至少是一种快速完成修复工作的手段。不过,根据近期一次关于Web编程的研讨会上多位发言者的意见,如果工程师和软件开发人员想确保他们的设计能够在以网络为中心的世界里正确工作的话,服务环境只是其中许多必须解决的问题中的一个。
在客户机方面,这些问题涉及使用何种版本的Java(是Java业界正式批准的版本还是刚推出的实时版本),IBM/Object Technology International公司的项目经理Marc Erickson表示。系统设计人员必须考虑Java协议是否合适及用哪种方法实现协议:即时编译、纯Java码、C/C++和Java的混合码、或者许多硬件Java虚拟机加速器。
虽然Web服务框架的思想有望简化开发人员的工作,但多种新的连接选择、协议和环境更让人困惑。在客户机方面,用户接口变得更加重要,实现问题也变得更加复杂。
在客户机和服务器之间缺乏处理互操作中间件的行业标准情况下,开发人员必须在客户机设备上使用所谓的静态码转换机制,Erickson指出。随着Web中间件标准的出现,他说,实现驻留于服务器上的动态转换码机制将变得更容易,这减轻了客户机的负担,使得客户机的处理能力可以释放出来用在具体的应用方面。
虽然新兴的中间件框架看起来很有前景,但针对Web服务的行业标准已经显露出分化的迹象。最明显的分化来自于微软公司新推出的不含Java的.Net框架,它暴露出整个行业内的根本性差异,特别是在需要何种开发支持方面。
另外一个公共约定是:XML应该用作捆绑器,它可以对从多个不同连接环境中来的程序代码进行捆绑。除此之外,在实现框架方面,业内公司出现了分歧。一方面,Sun、IBM和其它六个Web开发工具的销售商已经建立了基于XML和Java的Web服务开发框架,而且根本不打算采纳微软的C-sharp和.Net机制。另一方面,尽管微软大谈其标准之好,甚至到了将其C-sharp/运行时间可执行代码交给国际标准组织的地步,但至今它的.Net框架下仍未给Java留有余地。
加拿大Intrinsyc公司高级开发工程师Mark Gibbons表示,这个分歧使得服务器和客户机两方面的开发人员均深感忧虑。“我们遇到的问题就是双方无法沟通,”Gibbons认为,双方都承诺遵守标准,不管是事实上的标准,还是行业推行的标准,但他们都止步不前,不愿为某些语言和工具留有余地。
寻找共识
“在企业环境中,服务器应用的开发人员必须面对这样的事实:一些公司承诺使用Java/XML,而另一些公司承诺使用基于C-sharp、Basic和XML的工具,”Gibbons指出,“他们面临的问题是寻找某种统一的编程环境。”
Sun公司的Forte和IBM公司的Websphere均提供了在Web服务环境中的运行机制,它们使用包含在一种XML捆绑器中的传统代码。与此相似的是,微软公司的.Net在其框架内开发应用时允许使用几乎所有的语言,包括它自己的C-sharp,但把Java排除在外。这两种框架内的工具均允许将以前的传统编程语言集成到一个统一的执行环境之中。
随着微软公司用它的下一代与.Net友好的实时操作系统Windows CE来开发嵌入式设备,这种分歧有可能影响客户机的设计。这种操作系统以前叫做Talisker,现在的正式名称是。
由于.Net不含有任何运行Java的架构,因此摆在那些准备放弃基于CE应用的开发人员面前的是,许多公司,例如IBM、Intrinsyc和风河,正开始引入某些“桥接件(bridgeware)”作为这两种框架之间的过渡产品。此外,由于Web服务Linux开发人员的兴趣不断增长,开放源代码的桥接件产品,例如Mono和dotGNU,也在开发之中。







京公网安备 11011202001138号
