Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。様々なバージョンのデータ・サービスについて記した多くの記事が出回っていますが、どのバージョンを選んだらいいのかを明確に示した記事は見当たりません。同様にエンドポイントやチャンネルがアプリケーションの性能にどのように影響を与えるのかについて詳細を記した記事も見当たりません。Adobeでは4つのバージョンのデータ・サービスを挙げているものの、それらは大きく2つのバージョンに分けられます。Services(LCDS)と呼ばれるプロプライエティ版です。どちらの製品もメッセージ仲介サーブレットを通してFlexとJavaとの間の接続を確立するという最も重要な機能を提供しています。呼ばれるバイナリ・プロトコルを通したメッセージングを使ってサーバと通信を行います。Adobeではこれら2つの中心的な製品の上にサポートを付加したバージョンや拡張機能を含むスイーツ製品を提供しているのです。Logicにおける私達の経験ではこれら2つの製品間の主な違いはサポートの有無とデータ・マネジメント*機能です。性能と拡張性の違いについては議論の余地があります。LCDSは追加的なエンドポイントやクライアント通信のためのチャンネルを提供しています。Adobeはこれら追加機能の主な優位性は改善された拡張性にあると公言しています。ところが通信の基本的な手段はどれもHTTP上のAMFなので、サーバやクライアントの設定に依らず同じ性能なのです。LCDSが提供する別の付加機能はデータ・マネジメント*です。この機能はFlexで作られたクライアントとJavaで作られたサーバ・アプリケーションの間でリアル・タイムによる競合を回避しながらデータを同期する処理を提供します。JDBCやHibernate、その他のアダプタ*を通した永続化機構へデータ・サービスを接続するためのアセンブラやアダプタ*も提供します。4つのバージョンとはどのようなものでしょうか。Suiteと呼ぶスイーツ製品もあります。Signaturesといったツールを使ったドキュメント出力出来るようになっています。して見ると、論理的に考えて主に以下の三つの着眼点から(どの製品を選択するかという)判断をすることになります。サポートが必要でしょうか。(作成する)アプリケーションが、例えばミッション・クリティカルなアプリケーションのようなサポートを必要とするアプリケーションであるかどうかということです。データ・マネジメント・サービス*が必要でしょうか。(作成する)アプリケーションがデータの同期処理やマネジメント・サービスを必要とするかどうかということです。LCDSの提供する追加的なエンドポイントやチャンネルが必要でしょうか。Adobeによると同時接続数百を超える可能性がある場合にはLCDSの追加的なエンドポイントやチャンネルが必要になるとのことです。これについては議論の余地があります。サーバが処理することの出来る同時接続数は、例えばスレッド数やI/Oのスループットなどいろいろな要素に依存します。Javaのアプリケーション・サーバをスケールアウトするように、複数のサーバに対してロード・バランスをすることで大量の同時接続を処理することも出来るのです。この記事の最後にある比較表は異なるバージョン間の概要を示しています。ServletとNIOデータ・サービスにおけるエンドポイントとはサーバがクライアントからの接続を監視する方法のことです。DSとLCDSの両方における標準のエンドポイントはアプリケーション・サーバ上で動くサーブレット・ベースのエンドポイントです。これはweb.xmlで設定されたメッセージ仲介サーブレットを使うもので、通常のサーブレット・チェーンの一部に含まれます。DSやLCDSは既存のJavaアプリケーション・サーバ上にデプロイすることが出来るのです。他のJavaサーブレットによるエンドポイントと同様にクライアントからの接続一つずつに対してサーバ上では別々のスレッドが必要となります。NIOエンドポイントはまったく別の動きをします。Output(Javaの新しい入出力)を意味します。NIOエンドポイントはスタンドアロンで稼働するNIOベースのソケット・サーバを生成します。NIOの利点は一つのスレッドが複数の入出力ストリームを管理することが出来るのでより少ないスレッド数でより多くの数のクライアントをさばけるという点です。NIOを使う際に問題となる点は以下のようなものです。:クライアントはクライアント側のプロキシを通してNIOエンドポイントにアクセスすることが出来ません。(NIOエンドポイントとの)接続は標準のサーブレット・チェーンを通らないので、システム内でサーブレットの処理に依存している部分は破綻する恐れがあります。私達はあるプロジェクトでサーバにファイルをアップロードするのにサーブレットを使いました。NIOを使う際には通常、独自の認証機構を使う必要があります。ソケット・サーバはサーブレット・コンテナとは別のプロセスで実行されるからです。NIOサーバは80番ポートを監視するように設定することも出来ますが、通常は別のポートを使います。これによってネットワーク設定に問題が生じます。いうのも新しいポートに対する入力を受け付けるようにネットワークを設定する必要があるからです。このことはサーバが置かれているネットワークと別のネットワークにあるクライアントの状態によっては問題となり得ます。sessionを使ったロード・バランサを利用することで対応できる可能性があります。NIOの優位性については議論の余地があります。NIOは一つのスレッドで複数の接続を処理するために開発されました。一つのスレッドがコネクション・プールを巡回し読み取りや書き込みをする必要のある新たなデータがないかどうかをチェックすることでこの目的を達成しています。1.4で提供されたもので、JVMやLinuxにおけるスレッド処理はその時点から劇的に改善されました。JavaやLinuxで扱うことの出来るスレッドの量は劇的に増加したのです。Linuxカーネルは2.6で新たなスレッド処理ライブラリを提供しました。(NPTL)と呼ばれるものです。NPTLのテストによるとIA-32上で100,000コのスレッドを立ち上げるのに要する時間は2秒です1。NPTLがない場合、Linuxカーネルで同じ数量のスレッドを生成するのに15分かかります。NIOによって不利になるという議論に関するものです。一連のベンチマークを通してPaul氏はNIOに関する以下の点について示しました。NIOは20%から30%スループットが落ちるスレッド・コンテキストの切り替えは高価な処理ではない同期処理は高価な処理ではないこれらのテスト結果を基にPaul氏は1コネクションに1スレッドという方法は拡張性があることを示しました。1.6を使うとJVMは15Kから30Kのスレッドを処理することが出来ます。これはつまりサーブレット・エンドポイントの限界は数百程度の接続数ではないということを意味しています。多くて、15Kを超える接続数なのです。実際の限界数は、メモリやCPUといったハードウェアの設定にも依存します。基本的なネットワーク接続ではクライアントとサーバ間の通信に多くの異なる種類のチャンネルを使うことができます。通常のリモート・プロシージャ・コールでは標準のAMFチャンネルが使われます。別の通信方法としてメッセージングがあります。この方法を使うとサーバ側からメッセージをプッシュする疑似リアルタイム通信を実現することができます。例としてチャット(システムの)サーバ、オークション(システムの)クライアント、そしてコラボレーション・サービス*などのアプリケーションが挙げられます。データ・サービスがメッセージングをする主な方法はポーリングを使った方法です。HTTP上の標準的な通信では通信チャンネルを開放し続けておくことはないので、ポーリング用のチャンネルがサーバ側でデータの準備が整うまでクライアントの要求を保留しておきます。待ち時間は数ミリ秒から数分まで調整出来ます。この仕組みによってサーバ側からデータがプッシュされているように見せることが出来るのです。二種類の基本的なポーリング用のチャンネルがあります。短期のポーリングと長期のポーリングです。両者の主な違いはサーバ側がクライアント・データの準備が整うまでどれだけの時間待つかという点になります。進歩的なチャンネルはストリーミングAMFです。これはサーバに対してHTTP接続を開放することでサーバが絶えずメッセージを送信することを可能にするものです。この方法にはクライアント側からポーリングするオーバーヘッドがなくなるということと標準的なネットワーク設定を使うという利点があります。疑似リアルタイム・ストリーミングとしてはこの方法が最も精密でしょう。Alive機能を使っているという点です。DSでしか使えません。Adobeは最近RTMPの仕様を公開すると発表しました。他の製品でも使えるようになって行くものと思われます。RTMPは大きなサイズのマルチ・メディア・データやデータを二重のチャンネルを使ってストリーミング配信するために設計されました。RTMPの一つの利点はクライアントとの接続が開放されたままなのでサーバからデータをプッシュすることが出来るという点です。これによってRTMPはCometスタイルの通信やリアル・タイムでのデータ・プッシュに使うことが出来るのです。RTMPには3種類あります。一つ目はTCP上で機能するもので1935番ポートを使います。この種類のRTMPのマイナス面はクライアントのブラウザ側から接続を開始しなければならないということです。標準でないポートを使うので、しばしばクライアント側のファイアーウォールでブロックされてしまいます。他の2種類のRTMPはRTMPのメッセージをHTTPリクエストでカプセル化したものです。このことでRTMPはファイヤーウォールを通過し、通常のポートを使うことが出来るようになります。2種類とは普通のHTTPを利用するRTMPTとセキュアなHTTPSを利用するRTMPSのことです。Flexではサーバに対する全ての呼び出しは非同期に処理されるので、これらのどのチャンネルもクライアントの性能に影響することはありません。サーバ側の性能に影響を与えることはあります。大量のクライアント接続が同時に開始されたときには影響を与えます。ストリーミングAMFは大量にクライアントからの同時接続を発生させる可能性があり、これはつまり大量のスレッドが生成されるということです。先に述べたように、大量のスレッドによる影響は最小化することが出来ます。全てのクライアント接続はデフォルトのチャンネルとその接続が失敗した場合の代替となるチャンネルが設定されています。サーバの通信内容により、異なる種類のチャンネルの組み合わせを指定することが出来ます。RTMPチャンネルを指定してその接続が失敗した場合には長期のポーリング用チャンネルに切り替えるということです。DSに対する本当の優位性は主にサポートを受けられることとデータ・マネジメント*が出来るということになります。追加的なエンドポイントとチャンネルの利点については議論の余地があります。Logicで私達が体験したプロジェクトではNIOエンドポイントやRTMPの必要性は感じませんでした。他の全ての技術同様、明確な答えなどありません。ArchitectでFlexとJavaに関するコンサルティングをしています。Flexという、企業がFlex開発を始めるのを助けるオープン・ソースのプロジェクトの中心的な貢献者でもあります。12年に渡って開発者からコンサルティングまで様々な立場からJavaに携わってきました。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。