[随意神侃01]ESB SOAは、すべてを包容し、すべてを超えている.
6517 ワード
このフォーマットはきれいではありませんて、wpsファイルのフォーマットをダウンロードして見ることができます
前言
ESBとSOAは、かつて、約2年前にも、ほんの少ししか知らなかったので、知っているとしか言えません.しかもほんの少しです.WebServiceを使ったことがある以外に、どんなSOAもESB製品も使ったことがありません.その実現方法も研究したことがありません.
だから、私の論調はとても正しくない可能性があって、これは重要ではありませんて、誤った観点、とても価値があるかもしれなくて、とても力があるかもしれません.
次に、私はまずソフトウェア技術、あるいはプログラム言語の発展の缘由を述べて、それからSOAとSOAを実現する前提を引き出して、ESB.
インタフェースのプログラミング仕様の例を取って、この例は私が以前JavaEyeで送ったことがありますが、投稿の中で他の人と議論しすぎて、調和がとれています.この例はSOAとは何の関係もないが、SOAと同じ気持ちを持っている.
ページをめくる.
IT、アセンブリ言語から
この時代にプログラムを書くのは一般的な困難な任務ではなく、すべての機能は非常に細粒度の指令から構成されており、1つのサイクルでも10行のコードが必要で、ソートを完成できるプログラマーは達人です.各機能のコードは、前のコードと後のコード、およびコードの組織方式に高度に依存しているので、この時代の結合度は最も高い.
さて、今はCの時代になって、今でもCという高度に厳格なプログラム言語は過去式になっていません.その出現は、絶対的に大きく前の状況を変えたので、それは、よく使われる論理をカプセル化して、結合を大きく除いて、あなたが今循環を書くため、あなたは循環の文法を書くだけで、Copy以前の循環を実現するコードを書く必要はありません.もっとすごいのは、関数という牛が追い詰めたものがあって、あなたが任務を完成したとき、この関数を呼び出すだけでOkになりました.
さらに結合を解除しました
ここを見ると、興味がないかもしれません.これはSOAとかと何の関係があるのでしょうか?辛抱強く、本当にとても関係がある、あるいは共通点です.
さあ、今はオブジェクト向けの時代です.これはCパッケージよりもすごいです.このようなものを提案して、お互いの関係、あるいは連絡の方法とデータをパッケージしました(これがオブジェクト向けの本質です).以前はプロセスに向いていたが、システムを完成するには、大量のグローバル変数を定義する必要があり、その後、間の関係を組織する必要があり、関数の多重化率が低下した.なぜなら、彼らはグローバル変数に依存する可能性があるため、同じグローバル変数が欠けている環境では、関数は正常に実行できない.つまり、結合の程度は非常に高い. このように見ると,オブジェクト向けは驚くべきプログラミング戦略である.
また、対象に向かうのはこれだけではなく、従来の考え方を変えて、ソフトウェアの仮想的なものを現実世界の実物で見ることができます.
ここまで来てこそ、ソフトウェアは仮想世界であり、仮想世界は現実世界であると言える.
プログラム言語、最高級、オブジェクト向けですが、これはITのゴールではありません.
異なるシステムの共通機能を多重化しやすいモジュールに開発することを考え始めました
その後、再開発する必要がなく、直接使用することが容易になり、ミドルウェア、コンポーネント向けのプログラミング、EJBなどができました.しかし、多重化はそんなに簡単ではありません.世界には無条件に多重化できるコンポーネントは何もないと言えます.そして、複雑な配置を行い、時間をかけて勉強しなければなりません.これは、滅亡に向かうゴミ解決策にすぎません.EJBの悪名高い問題は、効率をもたらすのではなく、効率を下げ、最大の代価で、最小限の収穫を得ることだ.だから、中間部品の多くは醜いと思っています.
次に、ITは正道に戻り、今回はインターネットの出現と同じように世界を変えるだろう.もちろん、数年後だ.
これは、WEB Seriveのようなサービス向けであり、機能はサービスとして提供され、
私たちが共通のプロトコル(SOAP)を遵守すれば、私は同じ機能を使用するとき、
特定のクラスライブラリや環境に依存する必要はありません.同じプログラミング言語を使用する必要はありません.
このような機能を導入する必要はなく、このサービスにアクセスしてこの機能を呼び出すだけでOKです.このようにシステム開発は,また配置と,構成,パケット依存,ツール,デバッグの結合から解放され,オブジェクト向け以降の強力なデカップリングを完了した.
もう一度飛躍する.
はい、ここを見てSOAが必要です.もし前のものが、知らないし、読めないなら、SOAはできません.
一般的なサービス向けは、まだ終点ではありません.SOA、すなわちサービス向けアーキテクチャは、製品ではなく方法であり、SOAはスーパーサービス向けである.彼は一般的なサービス向けに再結合し、パッケージ化しなければならない.
前述したように、WEB Seriveのようなサービス向けは、SOAPプロトコルを遵守してこそ機能し、soapサービスのClientはJMSプロトコルとRMIプロトコルのServiceにアクセスできず、SOAはこのような状況を可能にしなければならない.SOAは、どんなプロトコルを使っても、正常にサービスを利用できると主張しています.
SOA:
-1、機能はサービス形式で提供されます.
0、アルゴリズムはサービス形式で提供されます.
1、ソフトウェアはサービスの形式で提供されます.(SAAS)
2、開発プラットフォームはサービスの形式で提供されています.(PAAS)
3、XXX、すべてのすべて、明日の明日の明日、すべてサービスの形式であなたに提供します.
4、どんな技術を使っても、サービスを呼び出すことができます.
5、どのようなフォーマットでも、サービスを使用できます.
6、どのようなプロトコルを使用しても、Servicesを使用します.
SOAは上記のいくつかをしようとしていますが、ESBはその一環です.
サービスにアクセスすると、直接サービスを呼び出すわけではありません.なぜなら、あなたの呼び出しプロトコルは、サービスのプロトコルと一致しない可能性があります.どうすればいいのでしょうか.これらの雑多なことはすべてESBに解決され、ESBはエンタープライズクラスのサービスバスであり、アクセス時に直接ESBにアクセスし、ESBはゲートウェイに相当し、このように動作します.
1、それはあなたのプロトコルを分析して、あなたがアクセスするサービスを確定します
2、そして、あなたのリクエストを、ターゲットサービスのプロトコルでリクエストを再表現し、サービスを呼び出します.
3,サービスの応答もESBに応答して、ESBは呼び出し先を確認して、更に応答を呼び出し先のプロトコルデータに変換して、呼び出し先に返して、このようにプロトコルをデカップリングしました
私たちはESBをこのように見ることができます.Clientは中国人、フランス人で、Servcieはアメリカ人、ロシア人です.だから、clientとServcieはコミュニケーションができません.
ESBはすべての言語に精通しているマスターで、Clientはサービスに仕事をしてESBに伝え、ESBはサービスに伝え、結果をClientにフィードバックします.
SOAの道:
SOAはこれらのことを解決して、webサービスを超えて、甚だしきに至っては一度最も先進的な理念と思想になって、方法はとても簡単です.一つだけ.
すべてを包容すれば、すべてを超える.
次に、いくつかのクラスを使って、インタフェースの正しい使い方を説明して、解釈します.
すべてを包み込むから、すべてを超えて.
SOAではありませんが、理念が一致していて、殊途同帰!
これは万能プレーヤーで、暴風の影音の実現方式で、簡単な信じられない、通りはジェーンまでです.
遠い昔、専用プレーヤーしかなく、mp 3ファイルはmp 3 Playerでしか再生できず、mpgファイルはmpgplayerでしか再生できず、wavファイルはwavプレーヤーでしか再生できなかったが、その後暴風影音が現れ、すべてのファイルが再生でき、最強のプレーヤーだった.
結論:暴風の影音はどのように他のプレーヤーを超えて、すべてのプレーヤーを包容するだけでいいです.
すべてを包容して、すべてを超えて、私の中にあなたがいて、自然はあなたに勝っています.
この点では、SOAのマクロアーキテクチャ方式と同様に、SOAはすべてのプロトコルを包容し、他の技術を超える技術である.
しかし、すべては理想にすぎない...実はまだ本当のSOAはありません.
このフォーマットはきれいではありませんて、wpsファイルのフォーマットをダウンロードして見ることができます
前言
ESBとSOAは、かつて、約2年前にも、ほんの少ししか知らなかったので、知っているとしか言えません.しかもほんの少しです.WebServiceを使ったことがある以外に、どんなSOAもESB製品も使ったことがありません.その実現方法も研究したことがありません.
だから、私の論調はとても正しくない可能性があって、これは重要ではありませんて、誤った観点、とても価値があるかもしれなくて、とても力があるかもしれません.
次に、私はまずソフトウェア技術、あるいはプログラム言語の発展の缘由を述べて、それからSOAとSOAを実現する前提を引き出して、ESB.
インタフェースのプログラミング仕様の例を取って、この例は私が以前JavaEyeで送ったことがありますが、投稿の中で他の人と議論しすぎて、調和がとれています.この例はSOAとは何の関係もないが、SOAと同じ気持ちを持っている.
ページをめくる.
IT、アセンブリ言語から
この時代にプログラムを書くのは一般的な困難な任務ではなく、すべての機能は非常に細粒度の指令から構成されており、1つのサイクルでも10行のコードが必要で、ソートを完成できるプログラマーは達人です.各機能のコードは、前のコードと後のコード、およびコードの組織方式に高度に依存しているので、この時代の結合度は最も高い.
さて、今はCの時代になって、今でもCという高度に厳格なプログラム言語は過去式になっていません.その出現は、絶対的に大きく前の状況を変えたので、それは、よく使われる論理をカプセル化して、結合を大きく除いて、あなたが今循環を書くため、あなたは循環の文法を書くだけで、Copy以前の循環を実現するコードを書く必要はありません.もっとすごいのは、関数という牛が追い詰めたものがあって、あなたが任務を完成したとき、この関数を呼び出すだけでOkになりました.
さらに結合を解除しました
ここを見ると、興味がないかもしれません.これはSOAとかと何の関係があるのでしょうか?辛抱強く、本当にとても関係がある、あるいは共通点です.
さあ、今はオブジェクト向けの時代です.これはCパッケージよりもすごいです.このようなものを提案して、お互いの関係、あるいは連絡の方法とデータをパッケージしました(これがオブジェクト向けの本質です).以前はプロセスに向いていたが、システムを完成するには、大量のグローバル変数を定義する必要があり、その後、間の関係を組織する必要があり、関数の多重化率が低下した.なぜなら、彼らはグローバル変数に依存する可能性があるため、同じグローバル変数が欠けている環境では、関数は正常に実行できない.つまり、結合の程度は非常に高い. このように見ると,オブジェクト向けは驚くべきプログラミング戦略である.
また、対象に向かうのはこれだけではなく、従来の考え方を変えて、ソフトウェアの仮想的なものを現実世界の実物で見ることができます.
ここまで来てこそ、ソフトウェアは仮想世界であり、仮想世界は現実世界であると言える.
プログラム言語、最高級、オブジェクト向けですが、これはITのゴールではありません.
異なるシステムの共通機能を多重化しやすいモジュールに開発することを考え始めました
その後、再開発する必要がなく、直接使用することが容易になり、ミドルウェア、コンポーネント向けのプログラミング、EJBなどができました.しかし、多重化はそんなに簡単ではありません.世界には無条件に多重化できるコンポーネントは何もないと言えます.そして、複雑な配置を行い、時間をかけて勉強しなければなりません.これは、滅亡に向かうゴミ解決策にすぎません.EJBの悪名高い問題は、効率をもたらすのではなく、効率を下げ、最大の代価で、最小限の収穫を得ることだ.だから、中間部品の多くは醜いと思っています.
次に、ITは正道に戻り、今回はインターネットの出現と同じように世界を変えるだろう.もちろん、数年後だ.
これは、WEB Seriveのようなサービス向けであり、機能はサービスとして提供され、
私たちが共通のプロトコル(SOAP)を遵守すれば、私は同じ機能を使用するとき、
特定のクラスライブラリや環境に依存する必要はありません.同じプログラミング言語を使用する必要はありません.
このような機能を導入する必要はなく、このサービスにアクセスしてこの機能を呼び出すだけでOKです.このようにシステム開発は,また配置と,構成,パケット依存,ツール,デバッグの結合から解放され,オブジェクト向け以降の強力なデカップリングを完了した.
もう一度飛躍する.
はい、ここを見てSOAが必要です.もし前のものが、知らないし、読めないなら、SOAはできません.
一般的なサービス向けは、まだ終点ではありません.SOA、すなわちサービス向けアーキテクチャは、製品ではなく方法であり、SOAはスーパーサービス向けである.彼は一般的なサービス向けに再結合し、パッケージ化しなければならない.
前述したように、WEB Seriveのようなサービス向けは、SOAPプロトコルを遵守してこそ機能し、soapサービスのClientはJMSプロトコルとRMIプロトコルのServiceにアクセスできず、SOAはこのような状況を可能にしなければならない.SOAは、どんなプロトコルを使っても、正常にサービスを利用できると主張しています.
SOA:
-1、機能はサービス形式で提供されます.
0、アルゴリズムはサービス形式で提供されます.
1、ソフトウェアはサービスの形式で提供されます.(SAAS)
2、開発プラットフォームはサービスの形式で提供されています.(PAAS)
3、XXX、すべてのすべて、明日の明日の明日、すべてサービスの形式であなたに提供します.
4、どんな技術を使っても、サービスを呼び出すことができます.
5、どのようなフォーマットでも、サービスを使用できます.
6、どのようなプロトコルを使用しても、Servicesを使用します.
SOAは上記のいくつかをしようとしていますが、ESBはその一環です.
サービスにアクセスすると、直接サービスを呼び出すわけではありません.なぜなら、あなたの呼び出しプロトコルは、サービスのプロトコルと一致しない可能性があります.どうすればいいのでしょうか.これらの雑多なことはすべてESBに解決され、ESBはエンタープライズクラスのサービスバスであり、アクセス時に直接ESBにアクセスし、ESBはゲートウェイに相当し、このように動作します.
1、それはあなたのプロトコルを分析して、あなたがアクセスするサービスを確定します
2、そして、あなたのリクエストを、ターゲットサービスのプロトコルでリクエストを再表現し、サービスを呼び出します.
3,サービスの応答もESBに応答して、ESBは呼び出し先を確認して、更に応答を呼び出し先のプロトコルデータに変換して、呼び出し先に返して、このようにプロトコルをデカップリングしました
私たちはESBをこのように見ることができます.Clientは中国人、フランス人で、Servcieはアメリカ人、ロシア人です.だから、clientとServcieはコミュニケーションができません.
ESBはすべての言語に精通しているマスターで、Clientはサービスに仕事をしてESBに伝え、ESBはサービスに伝え、結果をClientにフィードバックします.
SOAの道:
SOAはこれらのことを解決して、webサービスを超えて、甚だしきに至っては一度最も先進的な理念と思想になって、方法はとても簡単です.一つだけ.
すべてを包容すれば、すべてを超える.
次に、いくつかのクラスを使って、インタフェースの正しい使い方を説明して、解釈します.
すべてを包み込むから、すべてを超えて.
SOAではありませんが、理念が一致していて、殊途同帰!
これは万能プレーヤーで、暴風の影音の実現方式で、簡単な信じられない、通りはジェーンまでです.
遠い昔、専用プレーヤーしかなく、mp 3ファイルはmp 3 Playerでしか再生できず、mpgファイルはmpgplayerでしか再生できず、wavファイルはwavプレーヤーでしか再生できなかったが、その後暴風影音が現れ、すべてのファイルが再生でき、最強のプレーヤーだった.
// ， mp3,avi,mpeg
interface PlayableFile
{
public String getData();//
}
//
public interface Player
{
public void play(PlayableFile file);//
}
// Mp3
class Mp3 implements PlayableFile{
public String getData() {
return " MP3...";
}
}
// Avi
class Avi implements PlayableFile{
public String getData() {
return " Avi...";
}
}
// Mpeg
class Mpeg implements PlayableFile{
public String getData() {
return " Mpeg...";
}
}
// Mp3 Mp3
class Mp3Player implements Player{
public void play(PlayableFile file)
{
if(file instanceof Mp3){
System.out.println(" > "+file.getData());
}else{
System.out.println(" ");
}
}
}
// Avi Avi
class AviPlayer implements Player{
public void play(PlayableFile file)
{
if(file instanceof Avi){
System.out.println(" > "+file.getData());
}else{
System.out.println(" ");
}
}
}
// Mpeg Mpeg
class MpegPlayer implements Player{
public void play(PlayableFile file)
{
if(file instanceof Mpeg){
System.out.println(" > "+file.getData());
}else{
System.out.println(" ");
}
}
}
， AllPlayer
// ,
class AllPlayer implements Player
{
//
private Map<Class<?>,Player> map=new HashMap<Class<?>,Player>();
public AllPlayer()
{
map.put(Mp3.class, new Mp3Player());
map.put(Mpeg.class, new MpegPlayer());
map.put(Avi.class, new AviPlayer());
}
public void play(PlayableFile file)
{
map.get(file.getClass()).play(file);
}
}
AllPlayer player=new AllPlayer();
player.play(new Mp3());
player.play(new Avi());
player.play(new Mpeg());
new Mp3Player().play(new Mpeg());
：
> MP3...
> Avi...
> Mpeg...
結論:暴風の影音はどのように他のプレーヤーを超えて、すべてのプレーヤーを包容するだけでいいです.
すべてを包容して、すべてを超えて、私の中にあなたがいて、自然はあなたに勝っています.
この点では、SOAのマクロアーキテクチャ方式と同様に、SOAはすべてのプロトコルを包容し、他の技術を超える技術である.
しかし、すべては理想にすぎない...実はまだ本当のSOAはありません.
このフォーマットはきれいではありませんて、wpsファイルのフォーマットをダウンロードして見ることができます