关于PHP在企业级开发领域的访谈——企业级开发,PHP准备好了吗?

关于PHP在企业级开发领域的访谈

                         ——企业级开发,PHP准备好了吗?

 

转自:http://www.nowamagic.net/librarys/veda/detail/256

 

虽然PHP是Web应用开发中最广泛使用的环境,但它还是一度被认为无缘企业级开发。

  • Zeev Suraski,Zend Technologies公司创始人,该公司主要关注PHP的进展
  • Rob Nicholson,高级技术研员, 曾为IBM编写过程序设计语言运行时
  • Derick Rethans,PHP开发小组成员,eZ组件的项目负责人

Q:企业软件的一个关键元素就是互操作性,它可以让软件与其他平台交换信息。大家都认为PHP在这方面表现欠佳,因为它的WS-*支持相对来说比较新且功能较少,成熟度不高。关于这点你们是怎么考虑的?它会不会有所改变?

Zeev:我觉得相比WS-*而言,互操作性涉及的要更加多些。事实上,我们只看到了很少的基于SOAP的Web服务请求,而更多的则来自于其他标准,这主要是因为部署SOAP的过程较为复杂。PHP极好地支持了互操作,并且为此提供了很多不同的接口(REST,优秀的XML支持,SOAP,以及为web服务提供的 ZF组件等等)。据说PHP从2004年开始就为SOAP提供了非常好的基础支持,从2006年开始就通过Axis2扩展为WS-*提供了广泛的支持。我只能说我还从没有碰到过用户抱怨缺乏互操作性的情况,如果真的有,那也一定是赞美吧。

Rob:我觉得这只是部分人的观点。PHP源于其简单性。它是一门只需必要的复杂度,就能“解决web问题”的语言。因此PHP程序员会更多的选择REST 而不是SOAP。传统的企业软件正逐步向位于中间的PHP靠拢。比方说,IBM的许多企业级软件产品在去年都提供了RESTful交互支持,包括Atom 发布协议,这样的话就多了一个选择。在该用WS-*的地方使用它,而在开发的简单性和速度至关重要时,应使用REST。我们也饶有兴趣的看到了PHP被用来直接加强企业连通性。IBM的Message Broker可以当作一个“万能转换器”,它能够将一个东西连接到另外一个东西,而现在它的消息转化流中也提供了对PHP计算节点的支持。所以现在是可以在企业软件内部中使用PHP语言简单而又强大的语法和语句的。我们最近为IBM的CISC事务处理器发布了一个SupportPac,用以支持PHP语言。CISC正如软件一样,具有“企业级“的性质。它运行于主机上,可以由一些像银行,政府和医疗保健部门的组织来使用,用以处理一些最重要的可能影响到日常生活的事务。

Derick:我觉得这里没什么太大问题。PHP已经为所有的WS技术如SOAP,XML-RPC和JSON提供了支持。

Q:过去的几年里,将脚本语言移植到JVM中并以利用它丰富的监控,安全等功能已经成为了一种趋势。这对于PHP开发而言并不陌生,因为现实世界中存在好些个运行在JVM中的PHP应用。制造商们对于提升性能的话题各抒己见。你们是怎么看待这种趋势的?

Zeev:我们在.Net中也看到了类似的趋势,但是这些脚本语言并没有很远地脱离原始的实现。我想对于JVM上的PHP也是同样的道理。事实上我们可以看到原生实现的PHP相比综合改造后的PHP所拥有的性能优势——尤其是对内存的需要以及在现实世界中长期运行的表现。尽管如此,标准实现最大的优势是在于它所拥有的强大社区支持(包括在代码贡献和使用上),这是其他实现所缺少的一个东西。

Rob:它的一切都令人如此兴奋,我相信它会有很好的未来。在数以千计的已经被实现的语言中,只有少量语言在自然选择过程中幸存下来,原因是它们特别适合于某个用途。因此开发者改进创新某种语言的实现是一个很自然的事情。如果我们看看Ruby社区就会发现,这门语言的成功归因于至少半打以上的实现,还有这些实现中的共享测试和性能调整,它们帮助明确了语言的规范,而相互间”最快Ruby“头衔的竞争也功不可没。我想我们正在PHP上见证同样的事情发生。我们已经看到了PHP实现间协作所带来的巨大好处,例如在过去两年里由社区产生了大量的全新测试用例以及为改善某些API而作的努力,我相信这种现象在未来会持续下去。我现在正工作于PHP在JVM上的一个实现,它已经用在了IBM的ProjectZero孵化器(incubator )中,WebSphere sMush产品,以及我前面提到的CISC PHP SupportPac和MessageBroker计算节点中。我认为对于某些类型的问题,在JVM上运行PHP会非常有意义。我们看到我们的合作伙伴和客户正在使用它来耦合现有的基于Java的系统,这样做他们可以在轻松重用Java库和API的同时,享受PHP所带来的便捷。

Derick:尽管性能方面“可能”会有所提高,但是可扩展性却始终是个问题。PHP的整体思想是在无共享架构的情况下轻松实现可扩展性。在JVM上跑PHP会移除掉它的无共享架构。不幸的是PHP社区中只有一个叫做PHP-on-JVM的项目在尽可能的贡献着测试用例。

Q:从PHP 4到PHP 5的升级不是一个简单的迁移过程。关于那些犹豫是否对即将发布的PHP 6进行投资的公司,你们想说些什么?

Zeev: 实际上我并不同意关于4->5迁移是个非常困难过程的说法。整个过程并没有太多的兼容性破坏问题,而只是相对简单地修补应用程序。事实上想要利用新的功能,多花一点工作是在所难免的,也是意料之中的。在6的版本中我们实际上更多的考虑了兼容性破坏问题——目前这个问题在6中要比在5中更具实质性。这就是我们需要花时间去做的事情。

Rob:我认为PHP5在今后很长一段时间都会存在。即将发布的5.3版本已经尽可能的设计为无痛升级,且增加了原本定在PHP6.0中的几乎全部的功能,只差移除掉一些不用的功能和增加PHP 6.0中的unicode了。我非常渴望看到unicode版本的的PHP,因为它可以让基于PHP的JVM具有更加直接的兼容性,之所以更加直接是因为 JVM原生地采用了unicode来表示字符串,但是我怀疑采纳过程在PHP 5和PHP 6中都将会非常缓慢且持续许多年。

Derick:虽然大家对此总是怀疑,但是我们会努力减少这些问题,通过引入向前兼容的功能来转移到PHP 6。如果大家能够向我们反馈一下自己在当前开发版本中碰到的问题的话,那么可以帮助我们将迁移过程变得更加简单。

Q:在所有的建立的语言中,社区中的人们都推动增加了许多高级的功能。而另一方面PHP一直被认为易学的功能较少。你们认为这种情况需要改变吗?

Zeev:我绝对不认为它应该改变,因为它是PHP成功的一个关键因素。希伯来语中有句谚语大致这么说“给的越多,拿的越多”,我坚信这句话对于 PHP是适用的,至少在语言结构与语法上如此。通过使用扩展和框架,PHP可以无止境的扩展,在我来看,这些扩展和框架正是PHP最佳和最有趣的“最后前沿”。我觉得完全使用PHP的大型复杂网站(Facebook,Yahoo,Flickr),完全基于PHP的复杂现有应用(SugarCRM,OpenPro,CMS‘s),以及公司网站或内部系统依赖于PHP的企业证明了这样一个事实:PHP的功能集已经成熟,并且我们应该朝着这个方向走下去。

Rob:在我们着手为IBM的脚本产品WebSphere sSmash选择脚本语言时,就因为PHP如此广泛的使用面而特别选择了它。我们希望能够让数以百万的PHP程序员们能与企业或者企业软件紧密联系在一起,并且我们希望支持一种能够让新人程序员快速上手的语言。PHP的强大在于它的简单性。一门语言如果不想灭亡的话就一定需要不断的演变。如果PHP 5没有支持面向对象编程的话,肯定会丧失很多吸引力。伴随着PHP 5.3的发布,PHP肯定可以在这些新的特性上潜在的增加其复杂性。我想未来更多的工作是去了解怎样使用它们和在此之上形成的语句。鉴于新版本被采纳的滞后性,因此在大部分主流应用程序转移到使用5.3功能之前,还需要等上若干年,我想在这段时间里PHP程序员将会用大量实例来掌握这些新功能,并将它们用在简化常见的编程任务上。

Derick:不,它不需要改变,这两类开发人员都存在。增加新功能并不一定需要提高入门的门槛。

Q:PHP作为一门语言,在这些年里一直追随优秀的范型而演变,并从一个简单的预处理器演变成了一个强大的OO语言。随着函数式编程风格崭露头角,你们觉得这种这种范式是否会走进未来PHP的世界?

Zeev:不会。PHP仍然支持过程式开发,并且不太可能会消失;我们早在启动PHP(PHP 3)中就增加了OO的支持,虽然它现在跨越到了PHP 5中。lambda大概是最接近函数式范式的东西了,而这正是我们需要完成的。这也映衬了我前面回答的一个问题——我们不想要一个一劳永逸的语言,只是想要一个能够完成工作的简单语言。

Rob:这在一定程度上已经发生了。PHP 5.3中闭包的概念就是来源于函数式编程的世界里。PHP社区混杂了大量经过“经典训练”的计算机科学专业人员以及一些业余自我训练的程序员。看到这个多样的社区中闭包的诞生和常用语句的演化其实是一件很有趣的事。我相信我们最终会完成一套被广泛接受的模式和语句,它可以很优雅的解决web开发中的常见问题,而程序员在使用时都不会想到其实这一切都源于函数式编程。

Derick:我不确定,我认为它不会特别合适。但是如果它对PHP应用程序有意义的话,也许可以找到进入PHP的出路。PHP在集成其他语言中有趣和有用的理念方面一直做得很优秀。

你是怎么认为的呢,选择PHP是企业的明智之举吗?

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。