Java 和 XML 为何将成功

2008-02-23 10:01:47来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

在过去几年中,计算的注意力已经逐渐远离原始技术,并且最近大多数已经在确定一个总体拥有成本 (TCO) 的解决方案上。但是什么构成 TCO 呢?本文讨论了一个典型计算机系统中的互连复杂性是如何影响 TCO 的。而这种互连复杂性正是 Java 技术和 XML 能够处理的。
x
什么构成了总体拥有成本 (TCO) 呢?这很难说,每个人都有不同的答案。通常取决于他们找到的最方便解决问题的方法。大多数人都同意 TCO 并不只是组成系统各零件价格的总和。最初是这样,但到最后大部分成本来自支持环境中的系统的成本。一种受欢迎的减少 TCO 的方法是尝试集中管理独立系统、客户台式机或这两者,但这也只是答案的一部分。最好将通信量减到最小,但实际上是什么导致需要管理呢?当然,答案是变更。但不在于它本身。孤立的变更只会影响变更本身。我们都知道变更系统的一部分会导致遍及整个系统的支持需要。

普通的计算机系统通常会导致“熵死亡”,即成本超过预期值,而有序的简易性会变成互连复杂性。治愈这种症状的方法可能是集中管理,实际弊病将避免具有依赖性的复杂网络放在首要位置。Java 和 XML 通过帮助排除系统、软件和数据之间的自动互相依赖性来避免这种情况的发生。

一个新世界
大多数支持和管理的需求来自由计算机上的软件交织成的具有依赖性的网络。要重新获得简易性,我们需要除去依赖性。依赖性都存在于何处呢?有以下几种分类:

软件对平台
软件对数据
软件对软件
平台对平台
要解除这些依赖性的束缚并不容易,但十年来逐渐发展起来的计算新世界最终日趋成熟并使之成为可能。

让我们首先考虑已经在忍受的计算模式。当计算处于起步阶段时,很容易做出选择。我可以获取任意一种有限范围的计算机,编写在这种计算机上运行的软件,并创建用来存储数据的文件格式。麻烦是软件和数据只能在这种计算机上工作,使用另一种计算机时,就必须使用另一种软件,或者在同一种计算机上使用另一种软件时,就不能使用相同的数据,而且必须了解新的用户界面。

通过两个标准化步骤可以解决许多问题:许多人开始使用 IBM PC,最初使用 DOS,然后使用 Microsoft Windows。一定程度的简易性回来了。但随着时间的流逝,却越来越清楚地发现许多范围的复杂性仍然悄悄地混了进来。特别是,对平台的认可并没有打破软件的平台依赖性;这恰恰意味着它完全是互相依赖的。因此当更新发生时,一切可能破裂!另外,数据世界的垄断力量并没有标准化。就像软件依赖于特定级别的平台,数据也与特定级别的特别品牌软件相关。于是就交织成具有依赖性的复杂网,在其中任何一点所做的更改都可能导致不稳定,也许还会引起整个网络的崩溃。

互相依赖性
计算的头号敌人是无心造成的互相依赖性。在构建计算机解决方案时,它们都涉及到软件、硬件、平台以及开发工具等之间的关系。它们之间都通过看不见的具有互相依赖性的连接线索连接起来。随着时间的推移,拥有任何解决方案的成本与所支持的各部分间的依赖性数量成正比。但因为有了许多无心创建的互相依赖性,成本将以指数级增长,而不是线性增长。其结果就是更多的互相依赖元素所引出的附加成本可能会不成比例地增加终身成本。这种不成比例增长的起始点叫做冲刺点,而冲刺点以上的情况就叫做熵死亡。在冲刺点之前,就已经通过选择具有互相依赖性的系统原理、系统中一部分对另一部分的无意依赖(可能是由其它元素引起的)为熵死亡打下了坚实的基础。最常见的无意互相依赖性存在于软件和其宣称的操作系统之间。

这并不是说可以或者应该避免所有互相依赖性;有一些互相依赖性是不可避免的。但在现代系统规范和设计中,应该用与其它成本驱动因素相同的方法来标识和调整它们,请注意图 1 中不仅显示了直接成本,还显示了连接到具有依赖性的网络的终身成本。通常,需要将软件与使用它的环境隔离开。在某些情况下,使用本机接口和二进制是不可避免的,但在这些情况中本机代码外围的平台无关的“封装器”几乎总是有价值的。

图 1. 成本 vs. 节点数量



例如,假设一家公司使用办公套件的宏语言作为办公自动化系统的基础。一天,公司的 IT 小组安装了另一套软件,并无意中更新了办公套件所使用的一个 DLL 文件。他们发现有一个宏不能使用了。经过了大量工作以后,他们设法使这个宏再次工作,但新版本要求使用电子表格程序的更新版本。为了使用该程序,他们不得不安装办公套件的全新级别,而在那以后所有宏都不起作用了!接着,他们逐个调试所有宏,更新并修复它们。在这些修复所涉及的其它部分中,他们发现需要使用一个数据库驱动程序的新版本。可悲的是,那需要使用最新版本的数据库。于是,他们升级了数据库,并且……,哎,您可以猜得出其余部分。

新基础
问题是由在将变更的影响从子系统到子系统传送引起的。大多数系统当前使用的集成计算基础可以充当传输媒体,它可以让某一处的更改影响其它地方。

如何避开这个陷阱?最关键的就是切断数据与平台上软件的连接,对所有这些使用基于标准的选择,以便版本变化所带来的影响有可能降到最低。要达到这一步,我们就将变更与传输媒体(底层平台)隔离,并防止变更影响引起成本的剧烈震荡;我们添加前面提到的隔离层。那么,理想的标准基础是什么呢?图 2 中显示的技术领域,这样的基础应该涵盖的是:

将系统连接到一起并提供访问的网络协议
给需要的用户带来解决方案的传递模型
用来创建解决方案的编程模型
解决方案所使用的信息的数据结构模型
允许合适的用户访问合适的数据和解决方案的安全性模型
图 2. 技术领域



十年来计算机界的变化主要是重新发现技术思想,并将它们制定成模型内的标准。图 3 中显示以下这些映射:

网络:TCP/IP
现在 TCP/IP 的使用是如此广泛,以至于它不再是谈论的主题。
传递:Web 模型无状态客户机/服务器
无状态客户机/服务器计算是许多商业计算机用户选择的传递机制,且使用的用户量不断增长。与创建全状态客户机相比,它不需要昂贵的维护和支持费用,状态并不在服务器上维护,而是将大部分状态“贷”给了客户机。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:XML和J2EE的完美结合

下一篇:由于struts配置文件没有定义头文件引起的问题