Red Hat首席软件工程师方越(Freeman)访谈

 由  milkfan 发布

Q: 你是如何成为一个自由的开源软件工程师的? 很多人都对这样一种职业心生向往,对想进入这一领域的人你有什么建议?

走上开源道路,要从2006年谈起,当时源于ObjectWeb社区的Celtix和源于Codehaus社区的Xfire合并,成为了Apache旗下的一个新项目CXF。我当时所服务的公司IONA是开源项目Celtix的主要推动者,我也是Celtix的代码提交者(Committer),因此成为了Apache CXF的Initial Committer。从那之后,我一直从事开源软件开发工作,期间伴随着IONA被Progress收购,以及Progress成立独立的专门从事开源项目的子公司FuseSource,以及FuseSource被Red Hat收购。根据项目发展的需要,我从事的工作也从最初的Apache CXF扩展到了Apache旗下的多个开源项目。目前,我是Apache CXF、Servicemix、Karaf、Camel、Felix的Committer(在Apache开源社区中我使用Freeman Fang这个名字),并且是Apache CXF、Servicemix、Karaf的PMC member(项目管理委员会成员)。目前我在Red Hat从事JBoss Fuse产品的研发。

对于想成为开源软件工程师的人,我想最好是将兴趣和工作需要相结合。兴趣是最好的老师,有了兴趣才会持续的投入时间来学习,才能不断的提高,因此兴趣是第一出发点。将兴趣和工作相结合是说软件工程师的工作中实际有大量的机会接触到开源软件,面对这样的机会,如果我们能从使用开源软件更进一步,主动到社区提问题,参与讨论,甚至提交patch来fix bug和实现新的feature,成为committer,走上为开源做贡献的道路,这样对公司和个人都有好处。

这样的好处有对于个人有:

  1. 更好的完成了本职工作
  2. 在开源社区的工作拓展了眼界,技术能力的提高
  3. 自身价值得到提升

对公司有:

  1. 培养了人才,更全面的了解自己使用的开源软件,遇到问题心里有底
  2. 通过开源社区的visibility显示了公司的技术实力,这是一个很好的宣传

Q:能否跟我们说一说你一天的工作状态是怎么样的?作为一名开源软件开发者工作和生活与普通程序员有什么不同呢?

因为team里面的成员分布在全球各地,因此我基本天天都在家工作。

每天起床第一件事就是收邮件回邮件,每天要过大概两百封邮件,这些邮件主要来自我参与的开源项目的社区。

然后是上JBoss FUSE论坛来回答JBoss FUSE产品的相关问题, 然后根据手头问题的优先级来安排具体的开发工作。由于Red Hat JBoss Fuse产品本身就基于我参与的开源项目,所以我在开源社区的贡献就是我本职工作的一部分。从技术的角度讲,我写的代码都会先进入到开源社区的代码仓库里面。

我的工作和生活与别的程序员我觉得本质上没有不同,形式上的不同:

  1. 开源的代码
  2. 讨论通过邮件列表,irc,jira,github这些远程协作的方式而非面对面的方式
  3. 我可以在家工作

Q: 我们对开源软件开发的协作过程非常感兴趣,能否介绍一下?

由于开源软件的开发者通常来自世界各地,很多从来都没有见过面,因此有高效的工具来完成远程协作很重要。

主要的讨论通过邮件列表来完成,订阅相应的邮件列表可以收到jira变动和代码提交的通知邮件。irc提供了实时讨论的途径,主要用于开发人员内部的快速讨论,但是重要的讨论内容即使在irc上面发生了,也会发到邮件列表里面,保证所有的人都知晓。代码就是用svn或者git,现在越来越多的Apache项目都从svn迁移到了git上去,任何代码提交都会发通知邮件到邮件列表里面。jira用来跟踪issue,任何jira内容上面的变动都会发通知邮件到邮件列表里面。因此我说开源项目以社区为中心,开源社区以邮件列表为中心。

这里我想提一下Github, Github提供了代码仓库,邮件列表, issue, wiki等一揽子的解决方案,所有开源项目交流所用到的工具都可以在统一的界面里面解决了,我参与的fabric8[1]就是在Github里面,这是一个很高效的协作开发工具。


Q:Karaf在国内的应用情况如何?主要被哪些类型的公司以及哪些领域所采用?

Karaf作为一个基于OSGi的轻量级通用容器,可以用在很多领域。之前用的最多的领域应该是企业级中间件领域,例如JBoss FUSE和Apache Geronimo都是用Karaf作为底层框架。从发展来看,基于OSGi的轻量级的Karaf很适合作为微服务的载体,部署到云端,例如Docker这样的容器里面。我一直坚持认为OSGi以及Karaf部署到云端在互联网领域会有更广泛的应用。

有点儿遗憾的是,从我Karaf社区的工作经验来看,并没有太多来自国内的用户。如果OSGi中文社区的读者有谁在用Karaf,请告诉我。


Q:除了Apache社区,Eclipse社区也有不少OSGi相关的项目,但是我们注意到像Virgo、Gemini这些项目活跃度远远不如以前了,甚至一度出现没有Leader的情况,你对它们的前景是怎么看的?

专注做好自己的事情,不评论其它项目,:-)。


Q: 我们看到你是OPS4J Pax Web的committer,pax web实现了Web Application Spec吗?是否可以无缝地将一个传统的war包放入Pax web运行?另外就是pax web是否可以支持tomcat?

确切的说,OPS4J Pax Web实现了OSGi R4 Http Service和OSGi Enterprise Release规范中定义的Web Applications Specification。具体的对应pax-web发布的版本所支持的Web Applications Specification版本请看[2]。

通常来讲,你需要OSGi-fy这个war包,就是把war变成wab,主要的工作就是在MENIFEST中引入引入正确的OSGi metadata header,同时将war中lib目录下的jar变成一个个独立的bundle安装,也就是你的wab中最好不要embed jar,使用container中的bundle。

目前所发布的pax-web的版本都是基于jetty的,未来pax-web 4.x计划引入tomcat的支持。


Q: 对于Web层的模块化,即Web层如何拆分为多个Bundle是否有好的建议? 除了Package,Web层模块化可能涉及到HTML/JS/CSS等资源的共享,是否有什么好的解决方案?现在Spring4已经移除了OSGi Metadata,要想在OSGi环境中引入Spring4,有什么比较简单的方法?现有的Blueprint实现(Aries, Gemini Blueprint)是否有办法和Spring4集成在一起工作?

上个问题已经讲到了将war中lib目录下的jar变成一个个独立的bundle安装,也就是你的wab中最好不要嵌入jar,使用container中的bundle。这样同一版本的bundle可以被多个wab(通过Import-Package)使用, 这也是OSGi的一个思想,尽量的共享,不要嵌入jar,当然,由于OSGi独特的module机制保证了不同版本的bundle可以部署在容器这个层面,并且通过Import-Package(加version的形式)被不同的wab使用,这样即使有多个wab用不同版本的第三方库也不会有冲突,不需要classloader隔离而在wab中嵌入jar。

关于资源,其实OSGi里面对于资源的处理和class并没有本质不同,比如你可以做一个单独的bundle A,专门用来放资源文件,注意这些资源文件在一个unique的package下面,例如a.b.c, 这个package下面都是你想共享的资源文件,然后bundle A Export-Package a.b.c, 然后其它任何需要使用这些资源文件的wab Import-Package a.b.c, 这样就实现了资源的共享。

自从Spring中移除了OSGi Metadata header后,Apache Servicemix就一直提供OSGi-fy的spring bundle,请看这里[3]

Spring-DM 2.0 之后更名为Blueprint,现在主要有Apache Aries 和Eclipse Gemini两个实现,因此熟悉Spring配置文件格式的应该很容易迁移到blueprint上面来,但是需要更改一些xml语法,例如tag和namespace的写法。


Q: 关于Blueprint和DS,这两种技术如何选择?

这两个技术有都能提供OSGi service的引用和发布,从这个层面上有共同点。实际这两个技术侧重还是很不同的,如果你需要一个全功能的类似spring的DI容器,你用blueprint,如果你更关心OSGi service的动态引用和发布,你就用更轻量级的Declarative Services。


Q: Maven可以描述模块间关系,OSGi也体现了模块间关系以及跟细粒度的包的关系,用Maven来构建OSGi应用时,依赖关系在Maven和OSGi元数据中重复体现了,是否可能出现或者已经有一种专门针对OSGi的项目管理和构建工具?

我对这个问题有不同的看法。

在我看来,maven 是一个build time tool,因此Maven元数据(pom.xml)描述的是build time的依赖关系。 而OSGi元数据描述的是runtime的依赖关系,maven中build time的依赖通过maven-bundle-plugin(BND tool based)映射成为表示runtime的OSGi元数据。因此maven本身就是一个强有力的OSGi的项目管理和构建工具,当然,其中maven-bundle-plugin居功至伟。像Apache Servicemix里面OSGi-fy bundle都是一个个简单的maven project。


Q: 社区很多用户觉得OSGi学习起来有一定的门槛略,能否介绍一下你学习OSGi的过程,同时给初学者一些建议?

确实,OSGi学习有一定的门槛。我学习OSGi主要是从实战出发,边用边学,开发中遇到问题再去查资料,这样一段时间后对OSGi有了非常具体的认知,然后系统的看了《OSGi in Action》这本书, 对OSGi的概念的理解又上了一个层次。

我也建议想学习OSGi的同学除了系统的看书,还是争取在项目中先用上OSGi。例如OSGi的难点体现在动态服务上,其实如果不考虑动态服务,单单OSGi module层面带来的好处已经足够多,例如在复杂系统中经常遇到的毒瘤,第三方库的多版本依赖冲突问题,OSGi可以很好的解决这个问题。先使用OSGi,用其中最简单实用的部分,让自己的系统获得好处, 同时增加自己的信心,再渐增的模式使用OSGi的高级功能,用敏捷的思想来使用OSGi。


Q: 你对OSGi中文社区有什么建议?

很高兴有OSGi中文社区这个阵地来推广OSGi。希望通过你们的努力来使国内更多的开发人员认识到OSGi的威力,接受OSGi,国内有更多的系统基于OSGi来实现。让我们共同努力!


[1] http://fabric8.io/

[2] https://ops4j1.jira.com/wiki/display/paxweb/Pax+Web

[3] http://repo2.maven.org/maven2/org/apache/servicemix/bundles/

暂无相关文章

wmz 2015-08-13 08:43

开源插件化开发平台JXADF,就是相当不错的一个选择。<br><br>http://osgi.jxtech.net

顶(12) 踩(0) 回复
查看评论