JFox 从立项开发到现在已经走过了4个年头, 在这个过程中 , JFox 团队有过遗憾、有过失落、也有过惊喜和收获,可以说 JFox 是在跌跌撞撞中步入 2006年的, JFox 经历了漫长开发和等待过程, 但JFox 的前进步伐却一直没有停止过。

当初 JBoss 在市场和开源社区获得了巨大成功,是开源 J2EE Application Server 的不二选择, JFox 当时也想复制 JBoss 的成功模式,也想打造一个类似的、实现J2EE标准规范的完整 J2EE Application Server , 但我们没有充分认识到这个工作的艰巨性,以2、3年开发人员(早期几乎只有Orbat 一个人在独立开发JFox )要完成这样的开发工作几乎是不可能的,这也是当初定位 JFox 的不谨慎。使JFox的摊子铺得太大,直接影响了JFox开发进度和产品的发布周期。

不过可喜的是,我们最初计划先实现 JMX 规范的策略还是正确的,随后我们就成功发布了JMX规范实现: JFoxMX, 且JFoxMX 也通过了SUN的兼容性测试, 成为当时国内第一个实现JMX 1.2 规范的产品,将JMX 1.2 的新功能以第一时间带给国内和全球的Java程序员。这在当时是值得整个Huihoo社区的骄傲的事情。

在JFoxMX的基础上,我们不断开发新的组件和新的功能,这在当时也算是一个合理的开发策略。JFox项目也在 2003年8月实现了 JFox 最核心的部件: JFox 容器, 当时我们的容器策略是只实现了SessionBean,不实现 EntityBean, 而将采用封装JDO来实现数据持久化. 这样的发展策略也使 JFox 获得了一些用户, 这些用户也将他们部署在 Tomcat 上的应用迁移到了 JFox 上,这在当时是最引以为Huihoo自豪的事。选择JFox 是因为有些用户需要使用SessionBean,而 Tomcat 不支持EJB,JBoss 支持EJB,但JBoss又显太庞大,所以 JFox = Web Container + SessionBean 的结构模式开始获得了一些用户的青睐,可以说 JFox 在 Tomcat , JBoss 这两款产品之间找到了一点点生存空间。

接下来的日子,JFox 一个重要的子项目:JFoxSOAF 发布了,JFoxSOAF是JFox Agile J2EE路线的一个重要举措,JFox + JFoxSOAF 形成了目前 JFox 产品线的组成方式和应用模式。

2006年, JFox 继续在 Agile J2EE 路线上有新举措,项目组也于2006.03 发布了 JFox 2.5 m1, 新版 JFox 基于新的 IoC 内核,支持 MessageDrivenBean,支持 TimerBean,支持 EJB 集群, JFox 下一步计划是支持Web集群。我们也将继续这样的开发策略: 提供 EJB 中最好用、最有用的东西:SLSB(无状态 Session Bean) 和 MDB(消息驱动Bean), 而最复杂和基本上没有使用的 Entity Bean 不在 JFox 的开发和支持范畴里。

目前, IoC, AOP 大行其道 , 获得了巨大成功,我们有理由相信 IoC和AOP一起将成为下一代 J2EE 架构的基础。也必然是 JFox Application Server 的架构基础,JFox 将沿着 Agile J2EE,IoC,AOP的路线继续走下去。让我们一起见证 JFox的未来 🙂

JFox 新定位:Agile J2EE Application Server


12 对 “Agile J2EE、IoC、AOP : JFox的发展策略”的想法;

  1. 我想,到目前为止,重要的不光光是选择JFox的发展方向,或者,也应该着重考虑以下JFox的盈利模式。
    —- opensource 不代表完全免费,盈利模式也依然是很紧迫的。至少暂时需要找到一种让huihoo更稳健的发展模式和运营模式。

  2. 先思考一段时间,到时再整理一份 JFox 的运营方式和盈利模式的文章贴出来, 大家若对运营方式和盈利模式有什么好想法和建议,也欢迎提出来。

  3. 我认为,如果想让更多的人使用JFox,应该有一个框架基于JFox,利用这个框架开发人员能够快速的构建出应用程序。
    Appfuse大家都听说过,它的确能够在某些地方提高效率,同时降低了技术门槛。但是,把它用
    在国内的开发还是有些问题。如果,JFox有一个类似的东西,而且充分考虑的国内的情况。大家应该还是比较喜欢使用
    的。仅仅靠实现了某些标准,我想还是不足以使得JFox冲出重围。

    还有,我觉得倒是应该把摊子给摊大一些。当然,不是说让你们核心人员去摊。而是让更多的程序员参与进来。记得
    Huihoo有计划弄一个 sf.net的。不过,到现在我还没有看到这方面的消息。让更多的程序员开发自己的基于JFox的
    上层应用。即使开发不出几个像样的项目,也培养了JFox的潜在用户。

    以上是我的希望,如果错误请指正。

  4. 技术层面上离成功不远了,或者说是已经成功。
    然后开始考虑商业模式。盈利模式。 基于开源软件的实施方案在国内尚未全面展开。
    一旦趋势形成,JFox必将抢占大批市场。加油吧。

  5. 关于JFox关注了一些时间, 但是一直没有动手去做过什么。 刚刚看了这篇文章,感觉到一个人在开发一个这样大的系统, 的确是一个很不容易的事情。 我们公司自己也有自己的分布式framework, 是基于command的。 虽然没有实现EJB这些复杂的规范, 但是用起来已经很不错了。 你也说了现在IOC,AOP大行其道,我们也在搞这个,不过我是做项目开发的,只有内核组在做底层架构相关的事情。现在sun 推出javaEE 5也吸收了很多目前业界比较流行的东西。看看blueprint的petstore和ajax, web2.0,等等全部进入sun的javaEE 框架范围。

    在看看开源界也有很多做的不错的,向做出JIRA的那个公司,像opensymphony的webwork,等等一些产品都得到大家的使用。而且大家可以选择使用不同的server 容器。这样感觉很吸引人的。

    大家都习惯使用tomcat 或者习惯jboss,weblogic等, jfox有什么优势能吸引用户等等,使我想知道的, 如果说JFOX是一个tomcat + sessionbean , 那我觉得,如果我只是像原始的jsp+javabean,或者我想用一些开源的struts, spring, jfs等等比较流向的框架来实现我的应用, JFOX又能给我什么。

    我提出了一些问题,主要是想了解一下jfox,它和其他的容器相比有什么特点!

  6. 感谢朋友joyfire提出的建议:

    1. 确保固定的发布周期,短一些。最好每月一个 milestone版,半年一个final版。人手不够?步子可以迈小一点;变化?把部分feature推迟到下一版……无论如何,版本发布的频率节奏一定要稳定,周期要短。这是很多成功的开源项目的经验,也是Agile最重要的原则之一。
    2. 建立一个子项目,专门用于集成实用的示范应用,演示JFox推荐的体系结构、设计模式用法。这些示范应用必须是实际的完整的解决方案,而不是Hello World式的Demo。用户可以在此基础上修改扩充,形成自己的系统。Pragmatic的开发框架对推广很重要。

    http://spaces.msn.com/joyfire/

发表评论

OpenID

电子邮件地址不会被公开。 必填项已用*标注

Anonymous

电子邮件地址不会被公开。 必填项已用*标注