我们经常喜欢这样认为,大多数联合的IT组织多年以来与各种科技革新在某种程度上保持着同步,并且在这方面已经做得越来越好了。然而,现实情况相差甚远。你也许(或许不)感到惊奇, 有多少 IT 组织由于这种或那种原因而不参与这种带有"血腥味"的冲浪。
我们经常喜欢这样认为,大多数联合的IT组织多年以来与各种科技革新在某种程度上保持着同步,并且在这方面已经做得越来越好了。然而,现实情况相差甚远。你也许(或许不)感到惊奇, 有多少 IT 组织由于这种或那种原因而不参与这种带"血腥味"的冲浪。
那并不意味着这些IT公司对他们有用的东西漠不关心。现在,体系结构已经平稳地跨越了一代或两代。 这些IT公司正忙于检查他们的IT基础设施和评测新的体系结构途径。然而,他们该选择哪种体系结构平台和标准呢?
对于大多数IT公司来说, 他们倾向于在两派最具有实力的竞争对手做选择 --一种选择是基于 J2EE的应用服务器公司,如BEA,他们具有面向企业计算的开放式标准; 另一种选择是在这个领域中资格更老的公司,如 Microsoft,他们具有.NET强大的服务系列和开发工具。
在Web服务出现以前,从整体上比较轻易区分Java派系和Microsoft派系。在那个时候普遍认为Java语言和平台是众多问题的一种解决方案,包括软件的可移植性。曾经,普天盖地的颂歌使得我们相信Java是我们所有痛楚的良药。此外,基于J2EE的Web服务器技术使得基于浏览器的应用程序成为可能,从而也使我们的软件分布式问题得以最终解决。就这样,Java像是成为了解决许多阻碍应用程序开发生命周期的典型问题的整体方案。
当然,技术也不是停滞不前的,Microsoft 也不会坐以待毙,眼睁睁地看着J2EE抢占联合企业标准这个位置。他们的工作成果就是推出了我们今天所熟悉的达到登峰造极的.NET平台--一种与J2EE有点相似但又有很大改进的技术方案。顷刻间,IT公司在做选择时,变得很复杂了,并且J2EE和 .NET 的区别也不像以前那样明显了。
现在,我们必须在更高的层次上来理解他们之间真正的差异在哪里。 因为大多数的J2EE平台的供给商和Microsoft现在都提供业务过程治理引擎(比如BEA WebLogic Integrator与BizTalk),这些引擎是不能用来当作区分标志的。我们必须从别的方面加以区分,考虑他们各自的平台在集成业务过程治理(BPM)和人工工作流程活动方面的表现如何。
在不久的将来,公司将寻找整合自动化操作和人工过程新的途径,这种途径对于用户来说是非常自然和友好的,与此同时还能实时治理和更新业务流程。几年前,在Windows桌面上激烈的竞争仍记忆犹新,新的争夺联合IT企业标准的战斗又在桌面系统上打响,但是这次我们讨论的是工作流生产力工具与发布空间,以及一个具体的业务过程治理(BPM)方案在把用户和雇员融合成一个密不可分的整体 方面表现如何。
BEA已经在这个领域成为了领头羊,他首次提供以BEA WebLogic Workshop为中心的集成开发环境,他通过基于Java的API把所有的内容粘合在一起,从而使你在业务过程安排和门户治理的接口问题上变得轻松自如。BEA WebLogic Platform 8.1 的实现就是这样的,并且它也是BEA WebLogic Server 9.0的基石和所要超越的地方。