PHPRPC は SOA を夢から現実にします

PHPRPC は SOA を夢から現実に変えます
SOA はプログラミングのアイデアであり、コンピュータの歴史においてはかなり古い時代に登場しました。それはシステムを分解し、データやビジネスロジックの部分を可能な限り独立させ、他のシステムで共有できるサービスとして提供することに他なりません。

当時、DCOM や CORBA などの SOA を実装できるツールもいくつかありましたが、前者は Windows に限定され、後者は複雑すぎて Windows にしか適していませんでした。 C/C++、Delphi、Java などの言語のサポートが充実していますが、オープンソースのスクリプト言語については、サポートが不十分であるか、サポートが存在しないことさえあります。誰もが実装できるわけではなく、CORBA 仕様全体を実装するにはかなりの忍耐が必要であり、完全には理解できない可能性があります。)その後、インターネットが発達し、XML-RPC が登場しましたが、非常にシンプルでしたが (SOAP の実験的なプロトタイプにすぎなかったので)、単純なデータは送信できましたが、より複雑なデータは送信できませんでした。 SOAP は単純な名前を持つ非常に複雑な SOAP に発展しましたが、SOAP はデータ形式を定義するだけなので、後から大量の WS-* が追加されました。このようになると、CORBA と同じになり、誰もが理解でき、誰もが導入できるものではなくなります。つまり、この機能を備えた大企業や大規模な組織を除いて、他の人は基本的に介入することができません。 。そこで人々は、数年前に提案された REST という宝物を発見しようと突然思いつき、再び REST と呼ばれるサービスが大量に登場しました。これは単純に見えますが、実際にはデータの変換や送信などを行っています。ユーザーが自分で解決する必要があります。最終的に、REST の名付け親は、これらのいわゆる REST サービスを拒否しました。もちろん、これらに加えて、Hessian、ICE、Adobe の AMF3 ベースの通信ソリューションなどの他のソリューションもあります。これらは優れたテクノロジーですが、特定の言語に限定されているか、特定の適用範囲に限定されています。 。したがって、SOA に取り組むには、これらの異なるプロトコルとソリューションの間で変換する必要があります。この後、ESB はすでに非常に優れていて強力に見えます。しかし、それで本当に問題は解決できるのでしょうか？本当に新たな問題を生み出していませんか？もちろん、特定の問題は解決されますが、さらに新しい問題も発生します。さまざまなテクノロジーを切り替えられるのは良いことですが、これらの非常に複雑なテクノロジーの 1 つを習得することは非常に困難であり、それらのいくつかを学習して使用することも困難です。もう 1 つの問題は、これらのプロトコルの一部は本質的に遅いこと (SOAP ベースの Web サービスなど) であり、変換プロセスがある場合、どのような効率が得られるでしょうか?ということで、ESBは「ああ、バカ」ということになってしまった！ SOA は、美しく聞こえますが、実行するのが難しいものになっています。

しかし、実際に振り返って考えてみると、SOA で具体的に何を達成したいのでしょうか?システムを分解し、異種混合で再編成する必要があるのではないでしょうか?結局のところ、必要なのは SOAP ベースの Web サービスや、さまざまなプロトコルを変換できる ESB である必要はありません。私たちが必要としているのは、異種システム間でデータを効果的に交換できるテクノロジーであり、SOA システムをすでに構築できるようになります。他のテクノロジーについてはあえて言いませんが、少なくとも PHPRPC は、Java と .NET などの言語間で簡単にデータを交換できるだけでなく、オープンソースのスクリプト言語でも同じ方法を使用できます。 PHP、Ruby、Python、Perl など データを交換するには、Windows インターフェイスのフロントエンドとして Delphi/BCB を使用することも、Web フロントエンドとして JavaScript を使用することもできます。また、Flash を使用することもできます。 /Flex/RIA/WPF/SilverLight を使用して、よりリッチなコンテンツを備えたフロントエンドを作成できます。フロント デスクはすべて同じバックエンドを共有でき、バックエンドがどの言語で実装されているかを心配する必要はありません。携帯電話の J2ME、.NET CF、Flash Lite、およびモバイル ブラウザの JavaScript も完全にサポートできます。 PHPRPC を使用すると、突然非常に多くの選択肢が得られます。PHPRPC の開発によっても、SOA は今後ますます多くの選択肢になるでしょう。

98階 キムキング 2009-03-05

mathgl は

class xx
{
IList xx の複雑なオブジェクト

hessian をシリアル化する方法がわかりません ;
}
内の xxx は常にハッシュマップにマッピングされ、IList になります。これは、一部の言語では処理がさらに面倒です。 phprpc がこの問題を解決できるかどうかはわかりません。
rpcfx でも、リスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~

phprpc がそれをどのように処理するかわかりません~

99階 アンドット 2009-03-05

mathgl が書きました

複雑なオブジェクトをシリアル化する方法がわかりません

ヘシアン
class xx
{
IList xx;
}
の xxx については、これは同じです。 ハッシュマップへのマッピングは IList になります。 言語によっては、これを扱うのがさらに面倒です。 phprpc がこの問題を解決できるかどうかはわかりません。

これは C# ですか? C# のジェネリックは Java よりも優れており、xxx の実際の型を取得できるため、デシリアライズするときに、宣言した型に従って正確に復元されます。

100階 数学 2009-03-05

andot が

mathgl と書きました

{ のクラス xx の複雑なオブジェクト

ヘシアンをシリアル化する方法がわかりません
IList xx;
}
内部の xxx は常に hashmap にマッピングされ、IList になります。これは、一部の言語では扱いが難しくなります。 phprpc がこの問題を解決できるかどうかはわかりません。

これは C# ですか? C# のジェネリックは Java よりも優れており、xxx の実際の型を取得できるため、デシリアライズするときに、宣言した型に従って正確に復元されます。


間違いは List です。サーバーとクライアントが両方とも Java であっても、この list は list にマッピングされます。 >
phprpc にこれに関する改善があるかどうかはわかりません。結局のところ、ハッシュマップのパフォーマンスは良くありません。

101階 チェンジアンジクス 2009-03-05

オリジナルのポスターの最初の段落は非常に優れており、簡潔かつ鮮やかです。

私は軽量のリモート通話に非常に興味があります。元の投稿者に聞きたいのですが、パフォーマンスの問題は別として、XML-RPC や Hession/Burlap と比較した PHPRPC の主な機能上の利点は何ですか?

102階 アイスウビン 2009-03-05

kimmking が書きました

mathgl が書きました

複雑なオブジェクトをシリアル化する方法がわかりません

{ のクラス xx のヘシアン
IList xx;
}
内部の xxx は常に hashmap にマッピングされ、IList になります。これは、一部の言語では扱いが難しくなります。 phprpc がこの問題を解決できるかどうかはわかりません。
rpcfx でも、リスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~

phprpc がそれをどのように処理するかわかりません~
Java は Erasure スタイルのジェネリックであるため、定義されたジェネリックの xxx 型を実行時に取得できません。

しかし、問題は、getClass メソッドを反映して各要素の Class 型を取得できないかということです。

103階 アンドット 2009-03-05

mathgl が書きました

andot が書きました

mathgl が書きました

複雑なオブジェクトをシリアル化する方法がわかりません

hessian
class xx
{
IList xx;
}
の場合、それらはすべて hashmap にマッピングされ、IList になります。対処するのはさらに困難です。 phprpc がこの問題を解決できるかどうかはわかりません。

これは C# ですか? C# のジェネリックは Java よりも優れており、xxx の実際の型を取得できるため、デシリアライズするときに、宣言した型に従って正確に復元されます。


間違いは List です。サーバーとクライアントが両方とも Java であっても、この list は list にマッピングされます。 >
phprpc にこれに関する改善があるかどうかはわかりません。結局のところ、ハッシュマップのパフォーマンスは良くありません。

Java のジェネリックスは C# ほど優れていないようです (実行時の型情報がありません)。したがって、xxx​​がカスタムクラスの場合のみ正しく処理できます。コンテナーの場合は、AssocArray にする必要があります。他の基本型の場合は、配列を直接使用することによってのみ、この汎用コンテナー メソッドを使用しないでください。

104階 数学 2009-03-05

icewubin が書きました

kimmking が書きました

mathgl が書きました

複雑なオブジェクトをシリアル化する方法がわかりません

hessian
class xx
{
IList xx;
}
の場合、それらはすべて hashmap にマッピングされ、IList になります。対処するのはさらに困難です。 phprpc がこの問題を解決できるかどうかはわかりません。

私の rpcfx は常にリスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~

phprpc がそれをどのように処理するかわかりません~
Java なのではジェネリックを消去しているため、定義されたジェネリックの xxx タイプを実行時に取得できません。

しかし、問題は、getClass メソッドを反映して各要素の Class 型を取得できないかということです。

うーん....前のプロジェクトではクライアントに C++/cli を使用していました。そこの表示タイプはハッシュテーブルです。今夜 phprpc を試して、それがどのように機能するかを確認してください。

105階 アイスウビン 2009-03-05

mathgl が書きました

icewubin が書きました

kimmking が書きました

mathgl が書きました

私は知りません複雑なオブジェクトをシリアル化する方法がわかりません

ヘシアン
class xx
{
IList xx;
}
の xxx は、すべてハッシュマップにマッピングされます。 IList になります。言語によっては、これを扱うのがさらに面倒です。 phprpc がこの問題を解決できるかどうかはわかりません。
rpcfx でも、リスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~

phprpc がそれをどのように処理するかわかりません~
Java は Erasure スタイルのジェネリックであるため、定義されたジェネリックの xxx 型を実行時に取得できません。

しかし、問題は、getClass メソッドを反映して各要素の Class 型を取得できないかということです。

うーん....前のプロジェクトではクライアントに C++/cli を使用していました。そこの表示タイプはハッシュテーブルです。今夜 phprpc を試して、それがどのように機能するかを確認してください。

私が話しているランタイムは、RPC クライアントのランタイムではなく、シリアライザー (Java 側) のランタイムを指します。

106階 レイモンド2006k 2009-03-09

著者の分析は理にかなっています。 SOAP や WebService に固有の概念や慣用句のせいで、SOA、ESB などは実際に遅くなり、実装効果は顧客を満足させることが困難になっています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。

107階 ヤンイ 2009-05-06

raymond2006k さんは

と書きました。著者の分析は理にかなっています。 SOAP や WebService に固有の概念や慣用句のせいで、SOA、ESB などは実際に遅くなり、実装効果は顧客を満足させることが困難になっています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。

このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコルのフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成する方法

108階 rEloaD_cn 2009-05-07

yangyi は書きました

raymond2006k は書きました

著者の分析は理にかなっています。 SOAP や WebService に固有の概念や慣用句のせいで、SOA、ESB などは実際に遅くなり、実装効果は顧客を満足させることが困難になっています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。

このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコルのフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成するにはどうすればよいですか?

それに答えてみます

1: コードを書きます。これが phprpc の機能です
2: コードを書き続けます。 phprpc は複数の言語をサポートしているため、使用する言語に関係なく、Java コードを記述して jms を削除するだけで済みます。
3: まだコードを記述しています。
1) ワークフローまたは bepl に似た「プロセス サービス」を定義して、このコンポーネントをカプセル化します (Java で作成する場合は、jbpm を使用することをお勧めします。多言語の場合は、ws インターフェイスを公開することをお勧めします。 bpel を使用して)、phprpc でこの「プロセス サービス」を呼び出すコードを記述します。
2) phprpc を使用して 1 つずつ調整し、処理ロジックを自分で記述します。



はは、くそー、真剣に考えないでください

109階 ロットン 2009-06-02

この記事は最初から最後までとても長いので読みました。しかし、私は多くのことを学び、多くのことを学びました。 PHPRPC にはまだ大きな発展の可能性があると思いますが、私はまだ試していません (今夜試してみます)。 SOA とは何ですか、SOA ではないのですか? 理論などは常に人々を欺くために生まれてきました。 J2EE 仕様と同様です。私の考え方は、それがどのような理論や規範であっても、現実的な問題を解決できるものであればそれは良いことだ、というものです。しかし、そうは言っても、良いものには理論的な裏付けも必要です。しかし、今日の商業社会では理論が変わりました。 IBM は SOA 理論の創始者であると言うべきですが、IBM は SOA の旗の下でふざけています。
さらに、Tibico をメッセージ キューとして扱っている人もいたのを覚えています。実際、Tibico は中間融合エージェントです。上記のシステム データのいわゆる異種変換は、Tibico などを使用して実行できます。 Tibico はデータ変換とマッピングを行うことができます。SOA のような「偽の、大きな、空の」理論システムの最も有用な部分は、Tibico のようなものであるべきだと思います (IBM には、これと略称されるインターフェイス変更サーバーもあります)。念頭に置いて、最初に提案した a1 システムの統合に問題はありません。たとえば、a1 が ws を使用している場合、統合したい場合は、Tibico を使用して応答アダプターを開発すると、プロトコルを保護できると言えます。
また、投稿者は PHPRPC を SOA に関連付ける必要はありません。PHPRPC の目的は何ですか? SOA向けではなく、PHPRPCには独自の特性と独自のアプリケーションシナリオがあると思います。
もう一つ、PHPRPC の将来の開発は、使いやすさ、利便性、シンプルさに徐々に移行する必要があると思います。性能は十分強力だと思いますが、必ずしもそれが主目的ではありません。石鹸を見てください。その当初の目的は、XML メッセージを使用し、誰でも理解して使用できるようにすることで、使いやすくすることでした。
作者は、wsdl と同様に定義できるように、サービスの定義を統一的に記述する方法をまだ検討する必要があります。結局のところ、サービスを統合する必要がありますが、それでも非常に便利です。
私の意見が正しいかどうかはわかりませんが、たくさんナンセンスなことを言いました。コメント歓迎です。

110階 yuzhongzhu110 2009-07-13

私はsoaの初心者です。紹介していただきありがとうございます。午後は勉強します。

111階 何だ 2009-07-13

あなたのトピックは少し大きすぎます
SOA は現実になりました。
今の問題は、この現実を改善できるかどうかです。

PHPRPC はクロスランゲージですか?ただ、より多くの言語をサポートし続けているというだけです

私の意見では、PHPRPC は RPC フレームワークに似ています

112階 アイスウビン 2009-07-23

yangyi は書きました

raymond2006k は書きました

著者の分析は理にかなっています。 SOAP や WebService に固有の概念や慣用句のせいで、SOA、ESB などは実際に遅くなり、実装効果は顧客を満足させることが困難になっています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。

このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコル上でフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成するにはどうすればよいですか?
JMS は非同期ですが、WS と一緒に議論できますか?概念とアプリケーションのシナリオは大きく異なります。

113階 グルジェ 2009-07-23

icewubin が書きました

yangyi が書きました

raymond2006k が書きました

著者の分析は理にかなっています。 SOAP や WebService に固有の概念や慣用句のせいで、SOA、ESB などは実際に遅くなり、実装効果は顧客を満足させることが困難になっています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。

このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコル上でフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成するにはどうすればよいですか?
JMS は非同期ですが、WS と一緒に議論できますか?概念とアプリケーションのシナリオは大きく異なります。
なぜすべてをまとめることができないのですか...それは、経験が少なく、大きな商用製品を見たことがないからです
たとえば、SAP の pi はこのシナリオをサポートしています

114階 アイスウビン 2009-07-24

GRDJE が書きました

icewubin が書きました

yangyi が書きました

raymond2006k が書きました

著者の分析理にかなっています。 SOAP や WebService に固有の概念や慣用句のせいで、SOA、ESB などは実際に遅くなり、実装効果は顧客を満足させることが困難になっています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。

このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコル上でフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成するにはどうすればよいですか?
JMS は非同期ですが、WS と一緒に議論できますか?概念とアプリケーションのシナリオは大きく異なります。
なぜすべてをまとめることができないのですか...それは、あなたには経験が少なく、大きな商用製品を見たことがないからです
たとえば、SAP の pi はこのシナリオをサポートしています
お願いします文脈を踏まえて投稿を読み、鶏のように話さないでください。

私が言いたいのは、PHPRPC は非同期ではないということです。どうやって JMS と比較できるのでしょうか? SOAP (Web サービス) と比較されます。

115階 イヤーボー 2009-09-06

unsid は

と書きました。もちろん、通信プロトコルが言語とは何の関係もないことは理解していますが、私が議論しているのは非常に現実的な問題です。システム全体があなたまたはあなたのチームによって完成されているのであれば、問題はありません。問題ありませんが、A1 製品が関係する場合、「通信プロトコルは言語とは関係ない」ため、A1 を使用した言い訳を自分で実装することしかできませんが、A1 はオープンではなく、サーバーは多くの A1 実装を理解する必要があります。詳細は不可能です....


私は現在、投稿者の他の傑作でも相談した同様のジレンマに遭遇しています。phprpc を推進できるのであれば、そうします。すべての利益になります。笑

116階 さようなら85 2009-11-02

andot write

fansofjava write

JAVA では、サーバーがオブジェクト List を返した場合、なぜ LIST 内のデータを読み取ることができないのですか?毛織物？
例:

List<String> list = new ArrayList<String>();
list.add("dfsfsdf");
list.add("ggwertewr");
list.add("1234ggwertewr");
user.setList(list);
phprpc_server.add("getList", user); 

クライアントでデータをフェッチするとき、
List list = user.getList();
データは実際にリスト内にあり、次のようにすることができます。 list を介して渡される size() はリストのサイズを知っていますが、リスト内の文字列データにアクセスすると、常に java.lang.ClassCastException: [B...
これの理由は何ですか?
個人的には、クライアントはサーバーからどのような種類のリストデータが返されるのか全く分かっていないのではないかと思います（サーバーから渡されたリストデータが文字列リストであることは分かっていても、強制変換するとエラーになります）。それはバイト配列の形式で渡される必要があります。
リストの文字列を取得したい場合、各バイト配列を文字列に変換する必要がありますか?この場合、カスタム オブジェクト リストを渡します
非常に面倒ではありませんか?

確かに、文字列の型が明確にわからない場合、文字列は byte[] の形式で返されます。の。

Java のジェネリックは単なる構文糖であるため、そのジェネリック要素の型をリフレクションによって取得することはできません (これは .NET のジェネリックとはまったく異なります)。したがって、Java のジェネリック要素の型が基本型 (String を含む) に設定されている場合。カスタム タイプ オブジェクトにはシリアル化時に正確なタイプ情報が含まれるため、ジェネリック コンテナで受信できるのはカスタム タイプ オブジェクトのみです。

ただし、この型の場合は、String[] として宣言することでクライアントでそれを受け取ることができます。これにより、要素の型を取得し、正しい変換を自動的に実行できるためです。それ以外の場合、受信には非ジェネリック インターフェイス (List など) または非ジェネリック クラス (ArrayList など) のみを使用できます。受信後、org.phprpc.util.Cast.cast メソッドを使用して型変換を実行する必要があります。要素について。

私もテスト中にこの状況に遭遇しました。作者はそれを解決できますか?そうしないと、変換が非常に面倒になります

117階 アンドット 2009-11-02

thebye85 が書きました

andot が書きました

fansofjava が書きました

JAVA で、サーバーがオブジェクトのリストを返す場合、なぜ LIST 内のデータを読み取れないのかを尋ねてください。
例:

List<String> list = new ArrayList<String>();
list.add("dfsfsdf");
list.add("ggwertewr");
list.add("1234ggwertewr");
user.setList(list);
phprpc_server.add("getList", user); 

クライアントでデータをフェッチするとき、
List list = user.getList();
データは実際にリスト内にあり、次のようにすることができます。 list を介して渡される size() はリストのサイズを知っていますが、リスト内の文字列データにアクセスすると、常に java.lang.ClassCastException: [B...
これの理由は何ですか?
個人的には、クライアントはサーバーから返されるリストデータの種類をまったく知らないのではないかと思います（サーバーから渡されたリストデータが文字列リストであることを知っていても、強制変換するとエラーになります）。はバイト配列の形式で渡されます。
次に、リストの文字列を取得したい場合、各バイト配列を文字列に変換する必要がありますか。その場合は、カスタム オブジェクト リストを渡します
すごく面倒じゃないですか？

確かに、文字列の型が明確にわからない場合、文字列は byte[] の形式で返されます。の。

Java のジェネリックは単なる構文糖であるため、そのジェネリック要素の型をリフレクションによって取得することはできません (これは .NET のジェネリックとはまったく異なります)。したがって、Java のジェネリック要素の型が基本型 (String を含む) に設定されている場合。カスタム タイプ オブジェクトにはシリアル化時に正確なタイプ情報が含まれるため、ジェネリック コンテナで受信できるのはカスタム タイプ オブジェクトのみです。

ただし、この型の場合は、String[] として宣言することでクライアントでそれを受け取ることができます。これにより、要素の型を取得し、正しい変換を自動的に実行できるためです。それ以外の場合、受信には非ジェネリック インターフェイス (List など) または非ジェネリック クラス (ArrayList など) のみを使用できます。受信後、org.phprpc.util.Cast.cast メソッドを使用して型変換を実行する必要があります。要素について。

私もテスト中にこの状況に遭遇しました。作者はそれを解決できますか?そうしないと、変換が非常に面倒になります

この問題の理由は、PHPRPC で使用されるシリアル化形式がバイナリ文字列と Unicode 文字列を区別できないためです。そのため、これは PHPRPC の欠陥であり、変更できません。 。しかし、良いニュースは、ソフトウェア Hprose の商用オープン ソース バージョンでは、この欠陥が解決されており、すべての型 (org.phprpc.util.Cast などのヘルパー クラスも含めて) を型変換する必要がないことです。それらはまったく不要なので、もう存在しません)。 Hprose は PHPRPC の 10 倍以上のパフォーマンスが大幅に向上しており、使いやすさも大幅に向上しています。興味のある方はぜひお試しください。