Sun用AppServer8.0反击对手

核心提示：在最近的一次采访中，Sun公司的软件执行副总裁Jonathan Schwartz对ZDNet的执行编辑David Berlind的一个栏目就其关于最近IBM和BEA的合作是否会标志着java标准的末日的开始的问题做了答复，Sun用AppServer8.0反击对手，在采访中， Schwartz谈了IBM和BEA的动作，更

　　在最近的一次采访中，Sun公司的软件执行副总裁Jonathan Schwartz对ZDNet的执行编辑David Berlind的一个栏目就其关于最近IBM和BEA的合作是否会标志着java标准的末日的开始的问题做了答复。
　　
　　在采访中， Schwartz谈了IBM和BEA的动作， Java标准化组织（Java Community PRocess）的完善，因为它属于linux和开放源码，其责任的免除， 以及Sun如何计划让它更便于企业从Microsoft Windows和Office转向基于浏览器和Java的其它选择。
　　
　　IBM和BEA最近在取得JCP的认可前合作生产和支持了一些J2EE扩展模块。两家成员，凑巧也是市场份额的主要占有者，一起认可了JCP还没有时间考虑的J2EE扩展模块时，JCP是否被排斥在外了？
　　我不能肯定这与JCP的目的无关。JCP是为了确保在多种应用间有一个标准。它也是一个定义下一代JCP规范的地方[编者按：JCP规范被称为JSRs或"Java请求规范"]，但是还有其它的途径。这与JCP没什么关系，因为它是对我们新的应用服务器的一个回应。
　　
　　不管如何衡量，IBM和BEA在市场份额方面都是遥遥领先的。你认为新的应用服务器的什么方面引起了这样的结果？
　　IBM和BEA都受到了我们的AppServer 8.0的压力，因为它是免费的并且可配置的。它同时符合J2EE 1.4和WS-I基本概要，你可以在上面经营业务。它可以在Solaris， Linux， HP-UX 和Windows上使用。
　　
　　它在所有这些平台上都是完全免费的吗？没有附带条件？
　　没有附带条件。令人兴奋的是JBoss也签约获得了许可。所以，在我们之间，JBoss和Apache之间， IBM和BEA将很难向市场收取每台CPU数万美元的费用。这个压力促使IBM和BEA要创新。
　　
　　但是为什么要在提交给JCP之前公布扩展模块，而不是之后呢？
　　[IBM和BEA最终]把它们提交给了JCP，因为市场寄希望于JCP给出他们认为安全的标准。因为有了这些标准，JCP使得用一台符合标准的应用服务器来替换另一台成为可能，同样这也引起了应用程序服务器提供商之间的竞争。 我知道这破坏了IBM的计划，他们更喜欢与微软在网络服务互操作组织（WS-I）中合作，但是那似乎停滞不前了。
　　
　　你为什么认为WS-I停滞不前了？
　　我没有看到它在市场上有很多的推动。有段时间Java和网络服务是互不相干的。现在它们彼此是相通的。另外，微软在WS-I之外做的事要多得多，他们把精力放在了对微软更具战略性的事情上，例如Longhorn的发展及他们的应用程序服务器基础设施。一切都是为了推动微软，而不是WS-I。所以，现在，只有一个跨平台的组织在推动网络开发，那就是JCP。
　　
　　IBM过去抱怨过JCP动作太慢。IBM和BEA首先着手这些规范，然后再向JCP建议的做法，是否会是对这一问题的应对呢？
　　IBM和其它公司抱怨JCP动作太慢。那真是个可笑的说法。IBM嫌JCP慢是因为IBM想要提供专有技术，并想以标准为托词这么做。他们说等待和遵循标准放慢了他们的速度。然而，假如速度对他们真是如此重要，他们为什么没能尽快交出符合J2EE 1.4的WebSphere版本呢？我们是第一家交出符合1.4标准的服务器的公司，同时它也支持WS-I的基本概要。我们甚至比微软先支持WS-I基本概要。IBM始终不怀好意地将JCP与其竞争者对比，而这就是证实JCP的速度快过其竞争者的证据。 [编者按: Schwartz没有明确指出他指的是哪家机构。在极大程度上，IBM与网络服务相关的工业合作都发生在WS-I或结构化信息标准推进组织（OASIS）。]
　　
　　规范发布后多久你们发布了对J2EE 1.4的支持？
　　我想我们在它被批准的当天就赶出来了。假如不是的话，那也是之后很短的时间里。
　　
　　经一位开发人员提供的技术查询， IBM上月发布了符合J2EE 1.4和WS-I基本概要的应用程序服务器。Sun在2003年11月的第二个星期发布了其符合J2EE 1.4标准的应用程序服务器的开发人员版， 大约是在JCP对J2EE 1.4规范最终投票过程于11月11日结束后一周。两周后，11月25日，也就是J2EE 1.4的JSR 151最终版本在JCP的网站上贴出供下载这天，IBM和BEA公布他们共同开发的三个J2EE扩展模块对JCP的共同预支持。]
　　
　　目前有谁支持了J2EE 1.4？
　　只有我们和IBM。
　　
　　BEA和IBM向JCP提议的三个扩展模块需要经过多长时间的程序？
　　那要取决于JCP了。JCP内没有竞争的议程。JCP的唯一议程就是向客户保证他们所依靠的标准将使他们得到他们想要的灵活性，同时向他们提供一种避免任何专利锁定的方法。这就是为什么开发人员必须避免那些不被JCP承认的专有技术的，指定销售商的应用程序服务器的API。
　　
　　ZDNet：那么Eclipse以及IBM没有参加最近成立的Java Tools Community这件事呢？
　　对于IBM的意图有很多怀疑。这就是为什么人们对Eclipse持怀疑态度。它真的就是为了推动WebSphere。
　　
　　Eclipse什么地方是Sun觉得不喜欢的？
　　IBM用Eclipse来把开发人员拉回到WebSphere和一个非标准的GUI的Java库，叫做SWT。它不象SWING那么便于携带，而SWING是标准。这很聪明，他们也做了一些不错的东西。
　　
　　不过假如开发人员愿意的话，他们不能用Eclipse来根据SWING编写吗？好象Eclipse并没有阻止他们与SWING标准相配。
　　
　　没错。假如你愿意，你可以根据SWING来写。但是当为SWING开发时不象为SWT那么匹配。与标准J2EE规范对立，根据IBM的WebSphere编写也是一样的情况。这就是为什么我们要推介应用验证工具包 （AVK）。这使客户可以带着他们的应用程序来，免费对应一个参考应用-- 我们的AppServer 8.0来运行-来看看它们是否会被任何专有的API捕捉到。
　　
　　假如它遇上了任何专有技术的API会发生什么？
　　Schwartz：它会出现错误，并说这些特定的代码行对该应用程序意味着风险。
　　
　　我们再来谈Linux，SCO和免责。去年，你是首先提出免责问题的人之一。你当时问有这样一个潜在的责任，各公司应该如何前进，还指出Sun愿意如何提供免责。可结果，这不是针对Linux的，而是对Solaris的。既然你的策略与Linux的关系比过去大大增加，Sun对于免责问题的立场是否有改变？
　　今天，假如你运行我们的桌面-Java桌面系统（JDS）--我们会免责整个解决方案。
　　
　　那是基于什么版本的Linux呢？
　　目前是SuSE的版本.
　　
　　Sun是否会有自己的Linux版本？
　　我们始终在寻找机会为用户将成本保持在低水平。现在，我们没有较大的意愿要改变。与SuSE的交易非常好。有爱好的一家公司是IBM。IBM是全世界最大的知识产权起诉方，但是他们拒绝对他们的Linux客户提供免责。
　　
　　HP和IBM很象。他们在他们的产品中提供Linux，但那不是他们公司自己的Linux版本。尽管HP只是做了整合，它还是愿意免责。那么Sun呢？与HP和IBM一样， Sun也是个整合者。那么在你的产品上运行Linux的人呢？
　　当我们生产整合的解决方案，如JDS时，我们提供免责。但是，假如一台服务器，他们在上面运行比如Red Hat Linux，他们需要去找Red Hat。我们希望看到Linux的销售商提供免责。假如你不能为你的知识产权做后援，那么你带给你的客户的价值是什么？你最近看到过Red Hat的10-Q表格吗？看看它的表格中风险因素栏是如何在不断增加。所以，我们希望看到Red Hat和Hp及Novell一起提供免责。
　　
　　Sun是否有任何计划对JDS以外的产品提供免责？
　　Java企业系统会有可能。
　　
　　那是在Linux上的？
　　就要支持Linux了。现在，它是在Solaris上。我们正研究免责问题。
　　
　　我作为一个在业余时间依靠Office， Outlook和Windows API做许多重活的开发人员，我想知道我要怎样可以用Java达到同样的目的。但是，Java不能访问那些API。Sun对微软提出了诉讼，因为它基本关闭了这一访问。那不仅剥夺了我转到Java的机会（除非我完全停止使用），但同时也剥夺了平稳地脱离Office或Windows的机会，假如我想要这么做的话。假如在MS-Office和StarOffice之间没有那些API或提取层来方便变动的话，你要如何让客户从Office移过来呢？事后想想，也许微软最初提供的道路是件好事。
　　
　　你想要写一次，在任何地方可以运行。微软的一个问题就是写一次，在任何地方运行的想法，以及让客户转移的机会根本不存在。但是既然我们已经推出了Java桌面系统，我们看到了在基于浏览器和Java环境下的为应用程序开辟趋势，这一切我们都已经在Sun做了。结果，当世界的其它地方深受[MyDoom病毒]之苦时，我们在Sun却未受丝毫影响，而且我们运行的是我们在Windows上会运行的同样类型的生产应用程序。对于那些感觉他们不能承受重建这些应用程序开支的公司来说，他们应该更仔细地看看Java企业系统。我们定价为$100的一个原因就是这样各企业可以省下数百万美元，使用其中一部分钱来承担迁移的开支，还能省下不少的钱。但是说到提供一个迁移的路径，客户想要的是可以安全地迁移到一个新的，更安全的环境中。所以，我们正寻找办法来提供在Java运行时对[Windows 和Office]的类库的访问。