关注Rod Johnson最近的沟通很有趣，你可以清楚地了解SpringSource的策略。我本想在假期时写一篇博客，但从未完成（毕竟那是假期）。一些元素已经过时（包括SpringSource收购Covalent），但这里就是更新后的链接。
Rod Johnson最近几周在攻击JBoss AS。这本身并没有真正打扰到我，但这种举动很有意思。虽然众所周知，一些JBoss人士和Interface21人士过去一直有紧张关系，但Rod加入竞争场令人惊讶。由于Rod不会像其他人那样出于情绪原因攻击别人，让我们猜测一下发生了什么。
Interface21（现在是SpringSource）去年获得了风险投资。别天真了，风险投资会改变公司，他们寻求快速的投资回报。Interface21主要是围绕Spring产品组合的咨询公司（从业务角度来看）。虽然这是一个非常稳定且高尚的业务，但它不能提供风险投资者想要得到的回报率：SpringSource的策略必须进行调整，最明显、最安全和最明确的解决方案是遵循JBoss Inc模式：追求支持费用。
嗯，要销售支持，你需要运行时。不幸的是，对于SpringSource来说，Spring作为一个框架，对客户来说并不具有足够的吸引力，让他们愿意转向支持模式。我认为SpringSource与IBM、BEA以及可能还有Oracle（由于直接的竞争，JBoss从未真正擅长此方面）达成了一些有趣的合作伙伴关系/支持协议，但扩大业务的唯一合理方式是拥有并支持自己的运行时。顺便说一句，你可以在Rod的博客中看到正在进行的合作，他对IBM、BEA和Sun（我稍后会谈到Sun）的态度非常同情。总的来说，你的平台越广泛，你销售支持的可能性就越大。所以SpringSource需要有一个平台来销售和支持。
编写自己的专有平台API集并不是那么“空中楼阁”（引用史蒂夫·乔布斯的话）。这就是为什么SpringSource加入了JCP，并开始支持Sun和Java EE 6的努力，特别是配置文件的努力。他们需要一个在实现上可以触及的“迷你EE”。如果我是SpringSource，我会尝试从Java EE专家小组中获取尽可能小的Web-like配置文件，实现它，然后举起Java EE兼容的旗帜来销售支持。
关于配置文件的旁白。虽然大家都认为Java EE需要一些配置文件，但我敢肯定没有人同意将什么放入哪个配置文件：每个应用程序都有不同的需求。人们真正需要的是能够按需部署和购买基础设施组件（无论是一个供应商还是几个供应商）的能力，以及确保有良好定义的API/ SPI的保修，这样整个平台就能保持一致性的愿景，从而让客户免于任何集成工作（组件集成或程序模型集成）。这是任何严格的配置文件集都无法做到的。但这是一项艰巨的任务。
回到主要故事。即使是最小的Java EE配置文件，SpringSource也缺少一些重要的部件，首先是servlet容器。这就是为什么Rod一直在试图巧妙地传达这样一个信息：[链接](http://blog.springsource.com/main/2007/12/24/is-it-a-tomcat-or-the-elephant-in-the-room/)（我在这里总结）JBoss AS很糟糕（Tomcat很棒）。对SpringSource来说，唯一明显的选择就是Tomcat。他们需要通过低端进入平台/运行时并获取市场份额（就像支持市场份额一样）。我不惊讶如果SpringSource宣布一个基于Tomcat和Spring的全面支持平台项目。当然，他们需要聘请一些Tomcat的关键贡献者来获得一些可信度。让我们设想这一切都完成了，他们认为他们将会面对的第一个竞争者是JBoss AS，所以看到Rod对JBoss AS和EJB 3的批评并不奇怪。但他们将面对的第一个竞争者将是那些不需要Tomcat支持的人：JBoss已经提供了一段时间的Tomcat支持，但不出所料，Tomcat从未成功实现货币化。大多数部署在Tomcat上的应用程序不需要（当然，也有例外）。也许Tomcat + Spring将是银弹，但我严重怀疑这一点，有多个原因。第二大竞争者可能是他们自己的生态系统。当你开始与他们竞争时，你的合作伙伴往往会生气，这就是生活。问问Larry就知道了。
顺便说一下，Rod似乎不知道JBoss使用的是Tomcat的一个增强版本作为名为JBoss Web的web容器。Remy（Tomcat）和Mladen（Apache httpd）坐下来编写了Tomcat和APR之间的本地集成，使这个服务器成为Tomcat和Apache httpd的最佳结合。也许他想检查一下并分叉它 :) 哦，还有一件事，任何被大象撞过的人都会对猫与象的类比微笑。
Tomcat + Spring仍然是一个薄弱的平台，SpringSource将不得不通过添加一些额外的组件来加强它
- 一个持久化框架（Spring不是一个持久化框架）
- 一个事务管理器
- 一个消息系统
- 可能是一些网络服务组件
以及更多组件。他们可能还需要围绕这些组件制定开发者工具策略。由于我对这个领域相当熟悉，我只会评论他们平台上的持久性部分。他们在技术上可以选择Hibernate、OpenJPA和Toplink。Hibernate对他们来说可能是最明智的选择，并且与他们的客户群体最为契合，但这对Rod来说可能是一个艰难的决定。两种替代策略是Toplink（又称EclipseLink）和OpenJPA。如果我是他们，我可能会选择OpenJPA作为第二选择，但他们将不得不在区分OpenJPA和Kodo的不同部分进行研发投资。
Rod，请更开放地分享你的策略。我一直很喜欢Marc Fleury分享他正在采取的策略和下一步行动的方式。对所有人大声疾呼，包括竞争对手：）
无论如何，祝你好运，我非常期待在这个领域看到竞争，因为我认为JBoss AS、Seam、Web Beans以及围绕它们的技术（如JPA、EJB 3、JSF等）对下一阶段的飞跃更具吸引力。
常规免责声明，这代表了我自己的观点，不一定代表我的当前、过去、未来或潜在雇主的立场等。
