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 は今後ますます多くの選択肢になるでしょう。
class xx
{
IList
hessian をシリアル化する方法がわかりません ;
}
内の xxx は常にハッシュマップにマッピングされ、IList
rpcfx でも、リスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~
phprpc がそれをどのように処理するかわかりません~
ヘシアン
class xx
{
IList
}
の xxx については、これは同じです。 ハッシュマップへのマッピングは IList
これは C# ですか? C# のジェネリックは Java よりも優れており、xxx の実際の型を取得できるため、デシリアライズするときに、宣言した型に従って正確に復元されます。
{ のクラス xx の複雑なオブジェクト
ヘシアンをシリアル化する方法がわかりません
IList
}
内部の xxx は常に hashmap にマッピングされ、IList
これは C# ですか? C# のジェネリックは Java よりも優れており、xxx の実際の型を取得できるため、デシリアライズするときに、宣言した型に従って正確に復元されます。
間違いは List
phprpc にこれに関する改善があるかどうかはわかりません。結局のところ、ハッシュマップのパフォーマンスは良くありません。
101階 チェンジアンジクス 2009-03-05
102階 アイスウビン 2009-03-05
{ のクラス xx のヘシアン
IList
}
内部の xxx は常に hashmap にマッピングされ、IList
rpcfx でも、リスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~
phprpc がそれをどのように処理するかわかりません~
Java は Erasure スタイルのジェネリックであるため、定義されたジェネリックの xxx 型を実行時に取得できません。
しかし、問題は、getClass メソッドを反映して各要素の Class 型を取得できないかということです。
103階 アンドット 2009-03-05
hessian
class xx
{
IList
}
の場合、それらはすべて hashmap にマッピングされ、IList
これは C# ですか? C# のジェネリックは Java よりも優れており、xxx の実際の型を取得できるため、デシリアライズするときに、宣言した型に従って正確に復元されます。
間違いは List
phprpc にこれに関する改善があるかどうかはわかりません。結局のところ、ハッシュマップのパフォーマンスは良くありません。
Java のジェネリックスは C# ほど優れていないようです (実行時の型情報がありません)。したがって、xxxがカスタムクラスの場合のみ正しく処理できます。コンテナーの場合は、AssocArray にする必要があります。他の基本型の場合は、配列を直接使用することによってのみ、この汎用コンテナー メソッドを使用しないでください。
104階 数学 2009-03-05
class xx
{
IList
}
の場合、それらはすべて hashmap にマッピングされ、IList
私の rpcfx は常にリスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~
phprpc がそれをどのように処理するかわかりません~
Java なのではジェネリックを消去しているため、定義されたジェネリックの xxx タイプを実行時に取得できません。
しかし、問題は、getClass メソッドを反映して各要素の Class 型を取得できないかということです。
うーん....前のプロジェクトではクライアントに C++/cli を使用していました。そこの表示タイプはハッシュテーブルです。今夜 phprpc を試して、それがどのように機能するかを確認してください。
ヘシアン
class xx
{
IList
}
の xxx は、すべてハッシュマップにマッピングされます。 IList
rpcfx でも、リスト コレクションを配列
にシリアル化し、実際の型のタグを追加します~
phprpc がそれをどのように処理するかわかりません~
Java は Erasure スタイルのジェネリックであるため、定義されたジェネリックの xxx 型を実行時に取得できません。
しかし、問題は、getClass メソッドを反映して各要素の Class 型を取得できないかということです。
うーん....前のプロジェクトではクライアントに C++/cli を使用していました。そこの表示タイプはハッシュテーブルです。今夜 phprpc を試して、それがどのように機能するかを確認してください。
私が話しているランタイムは、RPC クライアントのランタイムではなく、シリアライザー (Java 側) のランタイムを指します。
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。
このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコルのフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成する方法
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 つずつ調整し、処理ロジックを自分で記述します。
はは、くそー、真剣に考えないでください
さらに、Tibico をメッセージ キューとして扱っている人もいたのを覚えています。実際、Tibico は中間融合エージェントです。上記のシステム データのいわゆる異種変換は、Tibico などを使用して実行できます。 Tibico はデータ変換とマッピングを行うことができます。SOA のような「偽の、大きな、空の」理論システムの最も有用な部分は、Tibico のようなものであるべきだと思います (IBM には、これと略称されるインターフェイス変更サーバーもあります)。念頭に置いて、最初に提案した a1 システムの統合に問題はありません。たとえば、a1 が ws を使用している場合、統合したい場合は、Tibico を使用して応答アダプターを開発すると、プロトコルを保護できると言えます。
また、投稿者は PHPRPC を SOA に関連付ける必要はありません。PHPRPC の目的は何ですか? SOA向けではなく、PHPRPCには独自の特性と独自のアプリケーションシナリオがあると思います。
もう一つ、PHPRPC の将来の開発は、使いやすさ、利便性、シンプルさに徐々に移行する必要があると思います。性能は十分強力だと思いますが、必ずしもそれが主目的ではありません。石鹸を見てください。その当初の目的は、XML メッセージを使用し、誰でも理解して使用できるようにすることで、使いやすくすることでした。
作者は、wsdl と同様に定義できるように、サービスの定義を統一的に記述する方法をまだ検討する必要があります。結局のところ、サービスを統合する必要がありますが、それでも非常に便利です。
私の意見が正しいかどうかはわかりませんが、たくさんナンセンスなことを言いました。コメント歓迎です。
SOA は現実になりました。
今の問題は、この現実を改善できるかどうかです。
PHPRPC はクロスランゲージですか?ただ、より多くの言語をサポートし続けているというだけです
私の意見では、PHPRPC は RPC フレームワークに似ています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。
このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコル上でフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成するにはどうすればよいですか?
JMS は非同期ですが、WS と一緒に議論できますか?概念とアプリケーションのシナリオは大きく異なります。
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。
このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコル上でフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成するにはどうすればよいですか?
JMS は非同期ですが、WS と一緒に議論できますか?概念とアプリケーションのシナリオは大きく異なります。
なぜすべてをまとめることができないのですか...それは、経験が少なく、大きな商用製品を見たことがないからです
たとえば、SAP の pi はこのシナリオをサポートしています
SOA は基礎となるプロトコルの制約から解放され、真の意味での成果が得られるべきですサービスとサービス統合の考え方について。
このフレームワークは、SOA の 3 つの問題をいずれも解決していません:
1) 構成を通じて Java、Spring、または BPEL をこのプロトコルに素早く変更するにはどうすればよいですか?
2) このプロトコルを使用して、JMS および WS を使用して他の人が作成したサービスにアクセスするにはどうすればよいですか?
3) このプロトコル上でフレームワークを使用して、関連する通信プロトコルを満たすプロセスを形成するにはどうすればよいですか?
JMS は非同期ですが、WS と一緒に議論できますか?概念とアプリケーションのシナリオは大きく異なります。
なぜすべてをまとめることができないのですか...それは、あなたには経験が少なく、大きな商用製品を見たことがないからです
たとえば、SAP の pi はこのシナリオをサポートしています
お願いします文脈を踏まえて投稿を読み、鶏のように話さないでください。
私が言いたいのは、PHPRPC は非同期ではないということです。どうやって JMS と比較できるのでしょうか? SOAP (Web サービス) と比較されます。
私は現在、投稿者の他の傑作でも相談した同様のジレンマに遭遇しています。phprpc を推進できるのであれば、そうします。すべての利益になります。笑
例:
クライアントでデータをフェッチするとき、
List list = user.getList();
データは実際にリスト内にあり、次のようにすることができます。 list を介して渡される size() はリストのサイズを知っていますが、リスト内の文字列データにアクセスすると、常に java.lang.ClassCastException: [B...
これの理由は何ですか?
個人的には、クライアントはサーバーからどのような種類のリストデータが返されるのか全く分かっていないのではないかと思います(サーバーから渡されたリストデータが文字列リストであることは分かっていても、強制変換するとエラーになります)。それはバイト配列の形式で渡される必要があります。
リストの文字列を取得したい場合、各バイト配列を文字列に変換する必要がありますか?この場合、カスタム オブジェクト リストを渡します
非常に面倒ではありませんか?
確かに、文字列の型が明確にわからない場合、文字列は byte[] の形式で返されます。の。
Java のジェネリックは単なる構文糖であるため、そのジェネリック要素の型をリフレクションによって取得することはできません (これは .NET のジェネリックとはまったく異なります)。したがって、Java のジェネリック要素の型が基本型 (String を含む) に設定されている場合。カスタム タイプ オブジェクトにはシリアル化時に正確なタイプ情報が含まれるため、ジェネリック コンテナで受信できるのはカスタム タイプ オブジェクトのみです。
ただし、この型の場合は、String[] として宣言することでクライアントでそれを受け取ることができます。これにより、要素の型を取得し、正しい変換を自動的に実行できるためです。それ以外の場合、受信には非ジェネリック インターフェイス (List など) または非ジェネリック クラス (ArrayList など) のみを使用できます。受信後、org.phprpc.util.Cast.cast メソッドを使用して型変換を実行する必要があります。要素について。
私もテスト中にこの状況に遭遇しました。作者はそれを解決できますか?そうしないと、変換が非常に面倒になります
例:
クライアントでデータをフェッチするとき、
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 倍以上のパフォーマンスが大幅に向上しており、使いやすさも大幅に向上しています。興味のある方はぜひお試しください。