本次访谈中Sun公司SOA产品负责人Kevin Schmidt把之前的SeeBeyond的技术整合到JavaCAPS的过程，Java商业整合(JBI)的未来，持续的对JavaEE5的批评的反映以及新生的Java EE6的工作……

　　在这次的JavaOne大会上，TechTarget对Sun公司SOA产品负责人Kevin Schmidt进行了采访。在第二部分的访谈中，他谈到了Sun在把SeeBeyond并购到Java组成应用程序平台组件之后在技术方面的不断整合，以及一些关注的重点。他还提到和那些开源软件组织许诺的与商业产品的平衡问题。他还讨论了在关于Java商业整合(JBI)的规范上Sun做到了什么和失去了什么，以及Java EE这个平台在面向服务的架构的世界中的前景的问题。

　　在第一部分，他谈过了有关GlassFish，开放式的ESB，Java SE，JavaFx脚本以及其他和SOA和Web服务相关的Java的内容。

　　我们把目标放回Sun公司收购的SeeBeyond，SeeBeyond公司的代码里面有多大部分是属于开源组织的呢?

Kevin Schmidt:其实我们并没有把SeeBeyond公司的产品交给那些开源代码组织。 我们正在做的事情恰恰是我们所有的新的开发都是在开源代码组织里的。在开放的ESB中，我们正在将SeeBeyond从事的以及Sun公司已经在JBI和JSR-208上做的一些研发进行了整合。因此我们一直在从事开源的工作。而且那也是我们在整合技术中创新所在。我们并没有在这点上做出关于将所有的从SeeBeyond得到的代码交给开源组织的计划。在这一点上有两部分。一些人在开源代码组织和自由获得的概念上发生了混淆。我们前进的方向是让他们可以自由获取，但是，很有可能的，我们并不将所有的得到的代码交给开源代码组织。

　　那么对于你们来说，要想代码能够完全获得的话，要经历多久?

　　Schmidt: 这也是我们正在讨论的问题。很有可能今年晚些时候就能实现。不过确定的是，一定能在开放的ESB中获得。

　　如果 你在开放的ESB中能够很好的工作的话，那么是不是意味着你就会很好的使用JavaCAPS呢?

　　Schmidt: 这也是我们在我们的战略中经过充分考虑的问题。我们的战略是，我们支持的和销售的商业产品都将是JavaCAPS。我们在开放的ESB中开发的，都将是开源的，但是我们将把这些能够给我们的客户提供价值，而且可以作为GA产品进行发布的技术和组件合并到JavaCAPS里面去。

　　用批评的眼光去观察JBI，你认为还有哪些是你还没有做到的呢?

　　Schmidt:大概有两件事情是我们现在还没有做到的。一件是到目前为止， 我们还没有将一件产品推向市场。我们可以指向SeeBeyond这次兼并，但是这并不是借口。我们需要得到一些门外的东西。一些和他们相关的东西，部分上受了我们没有尽快的将我们的产品推向市场的影响。我们还没有做到像我们宣传所要求的那么好。毫无疑问的是，有一些其他的软件厂商建立了他，他们在其中看见了商业价值。但是主要的软件厂商还没有支持他。我们将继续和那些厂商进行讨论，而且很有可能的在某种程度上获得他们的支持。这两点是我们应该做的更好的事情。

　　为什么JBI依然是重要的?

　　Schmidt: JBI依然很重要的原因是因为他标准化了整合平台的管道。这是有非常重要的价值的。将其解释给用户并不是一件容易的事情。但是，拥有这种标准将给用户更多的灵活性以及更多的选择。通过JBI，以及规范化的管道，它允许在有很多可供选择的软件厂商的系统中进行开发。

　　十年以前，如果你想要做集成的话，你必须购买单独的能帮你实现目标的产品，而且还要解决他们如何在一起工作的问题。集成软件厂商看到了这部分的问题，认为这部分问题是要通过他们提供一整套的集成软件包来解决的，但是，每个软件厂商提供的产品都来源于截然不同的形式。他们都在某些领域功能比较强大，因此，经常出现的情况是，集成工具包并不能完成你想要的全部东西，你还需要某方面拥有erp特长，又有很强的独立性的best-of-breed软件来补充你的集成软件包。这就是最后这种集成软件包是如何服务客户的，它将客户从软件厂商的限制当中解放了出来。

　　那么，是什么样的因素在驱动着JBI2.0呢?

　　Schmidt:JBI2.0驱动着标准不断的前进，并且将我们在过去一些年里学到的有关可靠性和聚类的经验进行一些运用。而且，我们还相信，JBI以及SCA(服务组成架构，现在正在OASIS的标准讨论的过程中)都是值得称赞的。因此，我们想要保证的事情之一就是，我们所做的事情，一直是广受好评的。也许会有JBI可以利用的从SCA的元数据方面提取出来的东西。

　　我们进行了一些展望，一些工作是在Java EE6的基础上进行的。你可以告诉我们一些对这些事的评价以及Java EE6的时间表吗?

　　Schmidt:在关于GlassFish3的工作中是包含了一些考虑使用JavaEE6的东西。有一种你不需要拥有EJB容器的网络轮廓。他利用了一些更为先进的模型结构。至于时间表的问题，我想，他们将会在零八年末或者是零九年的某个时间会提到的。

　　那会出现这样的情况吗：那些在Java EE6上工作的人看上去好像对Java EE5提出了自己的反应，认为里面的由于成分过多而导致的膨胀进行了很多的批评?

　　Schmidt:肯定是有一部分这样的情况的。我们暂且不管这公平与否，现在的确有一种观点认为Java EE应用程序服务器实在是太沉重了。在某种程度上，事实的确如此。因此可以说，反馈情况的很大一部分是这样的。但我们的确要着眼于市场，观察人们究竟想要什么样的产品。在市场上的确有Java EE和EJB开发的一席之地，但是毫无疑问的，也有Tomcat——不是一个完全的Java EE容器，也是一个servlet容器——广泛使用的现象存在。最清晰的概述是有一个有相当重要意义的采用。拥有一个支持不需要完整的Java EE栈的方法是大家现在正在关注的。

　　IBM公司依然不支持Java EE5 ，这是我们关心的一个问题吗?

　　Schmidt:有点是吧。我不知道具体的讨论或者是他们的计划。不过，我猜他们最后一定还是会支持它的。当然，现在Oracle公司和BEA公司已经支持他了。我认为，IBM公司某种程度上是那种已开始并不支持，而市场需求最总会推向他们支持Java EE的企业。

　　说道Web服务栈方面，你也拥有一个，那就是AXSIS，Jboss。我们先把微软放在一边，如果只有一个Web服务栈的话，生活不就能简单一些了吗?

　　Schmidt:其实我也是这么认为的。在这方面我们愿意和其他的厂商贡献和合作。在我们负责的Tango项目的部分当中，我们已经在开源组织里完成了。他也是GlassFish的一部分。而且已经是公开的了。其他的人正在使用它们，并把它们整合到他们的产品当中去。因此，可以说，我们拥有了这种合作的开始。我们已经和BEA公司和Oracle公司进行了合作。他们不会离开去做他们自己的事情去。他们看到了合作的价值。我也愿意看到这个价值。这将会是在Web服务平台之间拥有的意义重大的能够进行协同工作的能力。而我们和微软合作也是有原因的。就像你说的那样，我们并没有在那里拥有相同的栈，因为我们是在不同的技术上的，但是可以保证的是，在工作中，协同工作能力是关键的驱动因素。

　　你可以为人们描述一下Mammoth项目是什么吗?你可以提供一些具体的例子或者是具体的由其生成的东西吗?

　　Schmidt:在Mammoth项目中，我只涉及到了外围。这个项目的重点是放在我们软件基础设施产品，我们的认证产品，我们的商业集成产品上的。他们主要从事将服务进行整合，并提供能够让顾客使用我们产品和技术的服务。在JavaOne会议的发言中，你已经听到了治理随着越来越多的客户和企业建立自己的面向服务的架构而变得越来越重要。他们发现，随着你有越来越多的服务，你必须要有方法来管理他们，智力他们，确保他们的安全。这就是Mammoth项目早期阶段我们关键注意的问题。但是我们期待还有一些事情可以被确定下来，像什么创造一系列关于使用我们产品的最佳实践方法。我们对于这点是相当激动的。我们正在做这件事的一些简单的类型。这并不是我们和埃森哲工作的的事情。

　　如果我画一幅关于JavaCAPS的画的话，特别是在SOA方面你想让人们拥有的部分，在注册/仓库方面似乎是一片空白，你能谈一下这方面的情况吗?

　　Schmidt:Sun公司拥有Sun服务仓库，但是，毫无疑问的是，有很多我们需要合作的或者是在上面操作的占有很大市场份额的其他公司的产品。我们将要保证我们能和这些产品合作，并提供相应的支持。

　　你们是不是正在寻找一个能够为UDDI3.0提供更好的鲁棒性注册/仓库支持?

　　Schmidt:使得，我们绝对是这样的。现在，我们并没有确定我们如何去做这件事，我们正在寻找最佳的做这件事的方法，而不论它是否是在我们拥有的产品上构建的或者是在一些Web服务组织的产品上构建的。在这件事上，我们正在运用一些在这方面能够提供一些有价值的输入的服务治理框架。