PHP は Web アプリケーション開発で最も広く使用されている環境ですが、かつてはエンタープライズ レベルの開発には手が届かないと考えられていました。
Q: エンタープライズ ソフトウェアの重要な要素は相互運用性です。これにより、ソフトウェアは他のプラットフォームと情報を交換できます。 PHP の WS-* サポートは比較的新しく、機能が少なく、十分に成熟していないため、この点では PHP のパフォーマンスが低いと誰もが考えています。これについてどう思いますか？変わりますか？
Zeev: 相互運用性には WS-* だけではないと思います。実際、SOAP ベースの Web サービス リクエストはほとんどなく、他の標準からのリクエストが多くなっています。これは主に、SOAP の展開プロセスがより複雑であるためです。 PHP は相互運用性を非常によくサポートしており、そのためのさまざまなインターフェイス (REST、優れた XML サポート、SOAP、Web サービス用の ZF コンポーネントなど) を提供します。 PHP は 2004 年から SOAP に対して非常に優れた基本サポートを提供し、2006 年からは Axis2 拡張機能による WS-* の広範なサポートを提供していると言われています。私が言えるのは、相互運用性の欠如についてユーザーから苦情を言われたことは一度もないし、もしそうならそれは褒め言葉だということだけだ。
ロブ: これは一部の人たちの見解にすぎないと思います。 PHP はそのシンプルさから生まれます。必要なだけの複雑さで「Webの問題を解決」できる言語です。したがって、PHP プログラマーは SOAP よりも REST を選択するでしょう。従来のエンタープライズ ソフトウェアは、徐々に中間の PHP に近づきつつあります。たとえば、IBM のエンタープライズ レベルのソフトウェア製品の多くは昨年、Atom 公開プロトコルを含む RESTful インタラクション サポートを提供したため、選択肢が 1 つ増えました。必要に応じて WS-* を使用し、開発の単純さと速度が重要な場合は REST を使用します。また、エンタープライズ接続を直接強化するために PHP が使用されることに興味を持っています。 IBM の Message Broker は、あるものを別のものに接続できる「ユニバーサル コンバータ」として使用でき、そのメッセージ変換フローは PHP コンピューティング ノードのサポートも提供するようになりました。そのため、エンタープライズ ソフトウェア内で PHP 言語のシンプルかつ強力な構文とステートメントを使用できるようになりました。最近、PHP 言語をサポートする IBM の CISC トランザクション プロセッサ用の SupportPac をリリースしました。 CISC は、ソフトウェアと同様に「エンタープライズ レベル」の性質を持っています。これはメインフレーム上で実行され、銀行、政府、医療分野などの組織が日常生活に影響を与える最も重要な問題のいくつかを処理するために使用できます。
デリック: ここにはそれほど問題はないと思います。 PHP はすでに、SOAP、XML-RPC、JSON などのすべての WS テクノロジーのサポートを提供しています。
Q: ここ数年、スクリプト言語を JVM に移植して、その豊富な監視、セキュリティ、その他の機能を活用することがトレンドになっています。現実世界では多くの PHP アプリケーションが JVM で実行されているため、これは PHP 開発にとって新しいことではありません。メーカーは、パフォーマンスの向上というテーマに関して独自の意見を持っています。この傾向についてどう思いますか?
Zeev: .Net でも同様の傾向が見られますが、これらのスクリプト言語は元の実装からそれほど離れていません。 JVM 上の PHP にも同じことが当てはまると思います。実際、包括的に変更された PHP と比較して、ネイティブに実装された PHP のパフォーマンス上の利点、特にメモリ要件と現実世界における長期実行パフォーマンスの点で優れていることがわかります。それにもかかわらず、標準実装の最大の利点は、他の実装にはない強力なコミュニティ サポート (コードの貢献と使用の両方の点で) であることです。
ロブ: すべてがとてもエキサイティングで、素晴らしい未来があると信じています。実装されている何千もの言語のうち、特定の目的に特に適していたために自然選択の過程を生き延びた言語はほんのわずかです。したがって、開発者が特定の言語の実装を改善し、革新するのは自然なことです。 Ruby コミュニティに目を向けると、この言語の成功は少なくとも 6 個の実装と、言語の仕様を定義し相互に最適に連携するのに役立った、それらの実装内でのテストとパフォーマンスの調整の共有に起因すると考えられます。 「Quick Ruby」というタイトルも大きく貢献しました。私たちは同じことが PHP でも起こっているのを目の当たりにしていると思います。過去 2 年間にコミュニティによって生成された多数の新しいテスト ケースや特定の API を改善する取り組みなど、PHP 実装間のコラボレーションから大きなメリットがすでに得られており、この現象は今後も続くと考えています。私は現在、JVM 上での PHP の実装に取り組んでいます。これは、IBM の ProjectZero インキュベーター、WebSphere sMush 製品、および前述した CISC PHP SupportPac および MessageBroker コンピューティング ノードですでに使用されています。特定の種類の問題に対しては、JVM 上で PHP を実行することが非常に合理的だと思います。当社のパートナーや顧客がこれを使用して既存の Java ベースのシステムを結合し、PHP の利便性を享受しながら Java ライブラリや API を簡単に再利用できるようになっているのを目にします。
Derick: パフォーマンスは向上する「可能性」がありますが、スケーラビリティは常に問題になります。 PHP の全体的な考え方は、シェアードナッシング アーキテクチャでスケーラビリティを簡単に実現することです。 JVM 上で PHP を実行すると、シェアードナッシング アーキテクチャが削除されます。残念ながら、PHP コミュニティには、できるだけ多くのテスト ケースを提供する PHP-on-JVM と呼ばれるプロジェクトが 1 つしかありません。
Q: PHP 4 から PHP 5 へのアップグレードは、単純な移行プロセスではありません。次期リリースの PHP 6 への投資を躊躇している企業に一言お願いします。
Zeev: 4 から 5 への移行は非常に困難なプロセスであるという意見には、実際には同意しません。プロセス全体は、互換性を損なうほどの問題ではなく、アプリケーションにパッチを適用するという比較的単純な問題です。実際、新しい機能を利用したい場合は、もう少し作業がかかることは避けられず、多少の作業が必要になることが予想されます。実際、バージョン 6 では、互換性を損なう問題についてさらに考慮しました。この問題は現在、5 よりも 6 の方が深刻です。これには時間をかけて取り組む必要があります。
ロブ: PHP5 は今後も長く存在すると思います。次期バージョン 5.3 は、可能な限り簡単にアップグレードできるように設計されており、PHP 6.0 で使用されていない機能の削除と Unicode の追加を除き、当初 PHP 6.0 で予定されていたほぼすべての機能が追加されています。私は、PHP の Unicode バージョンを非常に望んでいます。これにより、PHP ベースの JVM がより直接的な互換性を持つことができるようになります。なぜなら、PHP がより直接的な理由は、JVM が文字列を表現するためにネイティブに Unicode を採用しているからです。導入プロセスは PHP 5 で行われ、PHP 6 は非常に時間がかかり、何年もかかります。
Derick: 人々はこれについて常に懐疑的ですが、私たちは PHP 6 に移行するための前方互換性のある機能を導入することで、これらの問題を軽減するために懸命に取り組んでいきます。現在の開発バージョンで発生した問題についてフィードバックをお寄せいただければ、移行プロセスを容易にすることができます。
Q: 確立されたすべての言語において、コミュニティの人々は多くの高度な機能の追加を推進してきました。一方、PHP は学習が容易であり、機能が少ないと常に考えられてきました。この状況は変える必要があると思いますか?
Zeev: これは PHP の成功の重要な要素であるため、変更すべきではないと思います。ヘブライ語には次のようなことわざがあります。「与えれば与えるほど、より多くのものを受け取ることができる。」この文は、少なくとも言語構造と文法の観点からは PHP にも当てはまると私は確信しています。 PHP は、拡張機能やフレームワークを使用することで無限に拡張できます。これが、PHP の最良かつ最も興味深い「最後のフロンティア」であると私は考えています。 PHP を完全に使用している大規模で複雑な Web サイト (Facebook、Yahoo、Flickr)、PHP のみに基づいた複雑な既存のアプリケーション (SugarCRM、OpenPro、CMS)、企業 Web サイトや内部システムを PHP に依存している企業は、次のような証拠であると私は感じています。事実: PHP の機能セットは成熟しており、その方向に進むべきです。
Rob: IBM のスクリプト製品 WebSphere sSmash 用のスクリプト言語の選択に着手したとき、特に PHP を選択したのは、用途が広いためです。私たちは、何百万人もの PHP プログラマーをエンタープライズまたはエンタープライズ ソフトウェアと結び付けたいと考えており、新しいプログラマーがすぐに始められる言語をサポートしたいと考えています。 PHP の強みはそのシンプルさにあります。言語が消滅したくない場合は、進化し続けなければなりません。 PHP 5 がオブジェクト指向プログラミングをサポートしない場合、PHP 5 の魅力は間違いなく大きく失われます。 PHP 5.3 のリリースにより、これらの新機能により PHP は確実に複雑さを増す可能性があります。今後は、それらの使い方を理解し、それに基づいて文章を作成することがさらに重要になると思います。新しいバージョンの採用に遅れがあることを考えると、ほとんどの主流アプリケーションが 5.3 の機能を使用するようになるまでには数年かかるでしょう。この間に、PHP プログラマーはこれらの新機能を習得し、使用する実践的な経験を豊富に積むことになると思います。これらを使用して、一般的なプログラミング タスクを簡素化します。
Derick: いいえ、変更する必要はありません。両方のタイプの開発者が存在します。新しい機能を追加するのに、必ずしも参入障壁を高める必要はありません。
Q: 言語としての PHP は、長年にわたって優れたパラダイムに従って進化しており、単純なプリプロセッサから強力な OO 言語に進化しました。関数型プログラミングのスタイルが台頭してきた今、このパラダイムが将来 PHP の世界にも入ってくると思いますか?
ジーヴ: いいえ。 PHP はまだ手続き型開発をサポートしており、廃止される可能性は低いです。PHP (PHP 3) のリリース時に OO サポートが追加されましたが、現在は PHP 5 に移行しています。ラムダはおそらく関数型パラダイムに最も近いものであり、まさにそれが私たちが達成する必要があるものです。これは、私が以前に答えた質問も反映しています。私たちは、一度で完了する言語を望んでいません。単に仕事を完了できるシンプルな言語を望んでいます。
ロブ: これはすでにある程度起こっています。 PHP 5.3 のクロージャの概念は、関数型プログラミングの世界から来ています。 PHP コミュニティは、「古典的な訓練を受けた」コンピューター サイエンスの専門家と、独学で訓練を受けたアマチュア プログラマーの混合体です。この多様なコミュニティにおけるクロージャの誕生と共通のステートメントの進化を見るのは実際興味深いです。最終的には、プログラマーがすべてが関数型プログラミングに由来していることに気付かずに、Web 開発における一般的な問題をエレガントに解決する、広く受け入れられるパターンとステートメントのセットが得られると私は信じています。
デリック: よくわかりませんが、特にぴったりだとは思いません。しかし、それが PHP アプリケーションにとって意味のあるものであれば、PHP への道が見つかるかもしれません。 PHP は、他の言語からの興味深く役立つアイデアを統合するという素晴らしい仕事を常に行ってきました。
企業にとって PHP を選択するのは賢明な選択だと思いますか?
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
