Jt - Java パターン指向フレームワーク

メッセージング・デザイン・パターンの適用

Jt は Java アプリケーションを迅速に実装するためのデザイン・パターン・フレームワークです。Jt フレームワークのアーキテクチャーはメッセージング・デザイン・パターンに基づいています。メッセージング・デザイン・パターンは、SOA 機能や ESB 機能の他、多くの有名なデザイン・パターンの実装に使われています。

Al Galvis, Consultant, IBM

Al Galvis は長年コンピューター業界におり、いくつかの役職を経験してきました。それらの中には、コンピューター・サイエンスの教授、研究機関でのコンピューター・サイエンス研究者、数社の大企業に対する技術コンサルタントおよび技術アーキテクトなどがあります。



2010年 5月 27日

概要

Jt は Java アプリケーションを迅速に実装するためのデザイン・パターン・フレームワークです。Jt は、いくつかの大規模な基幹システムで利用されています。Jt フレームワークは以下の内容を実現することを目標としています。

  1. Jt フレームワークのアーキテクチャーはメッセージング・デザイン・パターンに基づいているため、フレームワークの各コンポーネントはメッセージを送信、受信、処理することにより、情報交換や計算をすることができます。またメッセージング API を利用することで、各コンポーネントは単純なものになり、強力なカプセル化や疎結合が実現されます。こうしたフレームワークのコンポーネントは、「レゴ/メッセージング」アーキテクチャーの特徴を活かし、複雑なフレームワーク・アプリケーションにプラグインすることができ、しかもコンポーネントを容易に交換することができます。フレームワーク・メッセージは非同期で処理することも同期処理をすることもできます。Jt フレームワークは、メッセージング・デザイン・パターンおよびその API の強力さと単純さをフルに活用します。
  2. Jt デザイン・パターン・フレームワークはメッセージングを利用して、GoF (Gang Of Four) や J2EE などの有名なデザイン・パターンを実装し、さらにはその実装を容易に行えるようにもします。Jt フレームワーク自体はデザイン・パターンを基にゼロから設計されて実装されており、Jt フレームワークにより、デザイン・パターンに基づいたアプリケーションの実装を容易にしかも迅速に行えるようになります。
  3. Jt フレームワークのレゴ/メッセージング・アーキテクチャーを利用すると、リモートであることを意識せず、セキュアにリモート・コンポーネントにアクセスできるようになり、リモート・フレームワークのオブジェクトはローカル・オブジェクトとして扱われるようになります。これが可能になるのは、Jt フレームワークによって実装されたデザイン・パターン (メッセージング、アダプター、リモート・プロキシー、ファサード) により、リモート API に関する複雑さが隠されるためです。メッセージの暗号化と認証用には、組み込みのコンポーネントが用意されています。
  4. Jt フレームワークは、フレームワーク・アダプターやプロキシーを利用したり、関連デザイン・パターンの実装を利用したりすることで、他の技術とそのまま統合することができます。統合可能な技術には、BPM、DAO (Data Access Object) 実装、MVC (Model View Controller) 実装、EJB、JSP、Ajax、ESB、JMS、XML、REST、Web サービスなどがあります。
  5. Jt フレームワークは軽量で高速な動作をするように設計されています (低オーバーヘッド、小フットプリント)。
  6. Jt フレームワークのメッセージング/レゴ・アーキテクチャーにより、設計や開発の作業を改善、単純化することができます。UML による設計図と Jt フレームワーク・メッセージング・ベースのアプリケーション、そして実装に必要なコンポーネントは、緊密に対応しています。Jt フレームワークには、フレームワーク・アプリケーションを生成するためのウィザードと自動機能が用意されています。フレームワークのコンポーネントは BPM/BPEL プロセス図に容易に追加することができます。今後のバージョンの Jt フレームワークでは、UML による設計図からアプリケーション・モジュールを直接生成できるようになるはずです。この目標に対する作業はまだ進行中です。
  7. Jt フレームワークのメッセージング・アーキテクチャーを利用して、テストやデバッグを容易に行うことができます。Jt フレームワークには独立したユニットとしてコンポーネントをテストする機能があります。この機能を利用するためには、そのコンポーネントにメッセージを送信し、コンポーネントから返される応答メッセージを検証します。

メッセージング・デザイン・パターン (MDP)

目的: メッセージング・デザイン・パターンを利用することで、コンポーネントとアプリケーションとの間での情報交換 (つまりメッセージの交換) が可能になります。

動機 (推進力): このデザイン・パターンを適用することで、数々の多様なシナリオで非常にさまざまな問題を解決することができます。メッセージングの仕組みは自然界を含めた現実の世界でも広く使われています。メッセージは私達の周りの至るところで交換されており、さまざまなものが常にメッセージを送信、受信、処理しています。例えば人間の場合、テレビを見るとき、音楽を聴くとき、電話で話すとき、あるいはインターネットでコミュニケーションするとき、常にメッセージを送信、受信、処理しています。今現在、皆さんは、この記事に書かれたメッセージを読んでいます。コンピューター・アプリケーションは現実の世界をモデル化しようとしているため、メッセージングの手法を使ってアプリケーションを設計、作成することは至って自然なことです。この手法を利用することで、より完全かつ正確に現実の世界を表現 (つまりモデル化) できると言うことができます。つまりメッセージング・デザイン・パターンを利用することで、ソフトウェア・エンジニアリングのプロセスを大幅に改善することができます。

参加者:

メッセージ送信者: メッセージを送信するコンポーネント

メッセージ受信者 (レシーバー): 入力メッセージを受信し、場合によっては入力メッセージの処理後に応答 (出力メッセージ) を生成するコンポーネント。入力メッセージ (実際には一般的なものですが) には、あらゆるタイプの情報が含まれていて構いません。このコンポーネントに対しては、入力メッセージに基づいて計算を行うように指示することができます。

メッセンジャー: 送信者から受信者にメッセージを転送する仲介コンポーネント。メッセンジャーが存在する場合、送信者と受信者はメッセージの転送方法 (通信プロトコル、メッセージ・フォーマット、暗号化やセキュリティーのメカニズム、等々) や、転送途中で実行されるメッセージ変換について、認識している必要はありません。こうしたメッセージの転送や変換は、メッセンジャーが責任を持って行ってくれるものであり、メッセンジャーはそのために存在しているからです。しかし現実の世界と同様、多くの場合にメッセンジャーは必要なく、送信者はメッセージを直接メッセージ受信者に送信することができます。通信モードとしては、同期、非同期、双方向メッセージングによるものなど、いくつかのモードが可能です。

メッセージ: 送信者と受信者の間で交換が必要な任意の情報 (つまりデータ)。通常は、入力メッセージと出力メッセージ (または応答メッセージ) という 2 つのメッセージが関係します。応答メッセージは必須ではありません。

図 1. メッセージング・インターフェース
メッセージング・インターフェース
図 2. メッセージング・デザイン・パターン (同期モード)
メッセージング・デザイン・パターン (同期モード)
図 3. メッセージング・デザイン・パターン (同期モード、メッセンジャーは関係しない)
メッセージング・デザイン・パターン (同期モード、メッセンジャーは関係しない)

結果:

  • カプセル化。メッセージング・デザイン・パターンによって最大限のカプセル化を実現することができます。各コンポーネントは自己完結の独立したユニットです。他のコンポーネントやアプリケーションとの通信メカニズムはメッセージングのみです。
  • 分離。MDP によって結合を最小限にとどめることができます。この場合も各コンポーネントは自己完結したユニットであり、システムの他の部分とは独立して実行することができます。
  • 再利用性。MDP によって再利用性を高めることができます。これは「レゴ (Lego)」セットのブロックを組み立てる場合と似ています。非常に複雑なモデルを、簡単な方法で互いに接続可能な単純なピースを使って構築することができます。この手法の強力さは、こうしたレゴ・ピースの組み合わせの数が非常に多い点にあります。メッセージング・デザイン・パターンを使用するコンポーネントを複雑なアプリケーションにプラグインすることができ、しかもコンポーネントの交換は容易です。コンポーネントの組み合わせによる構成のバリエーションは無限です。コンポーネントのユーザーは、そのコンポーネントが処理する入出力メッセージのみを知っていればよいのです。またアプリケーションも、他のアプリケーションのコンポーネントをコンポーネント・レベルで再利用することができます。つまりメッセージング・デザイン・パターンが使われている限り、別のアプリケーションから 1 つのコンポーネントのみを抽出することができます。
  • QA/テスト・プロセス。MDP によってテストやデバッグが容易になります。コンポーネントにメッセージを送信し、コンポーネントから返される応答メッセージを検証することで、コンポーネントを独立したユニットとしてテストすることができます (ブラックボックス・テスト)。一般に、ユニット・テストはテスト・ハーネスを使って行うことができます。テスト・コードをコンポーネント・コード内部に含める必要はありません (テスト・コードをコンポーネント・コード内部に含めると時間がかかり、予想外のソフトウェアの欠陥が生じがちです)。
  • 設計プロセス。MDP によって設計プロセスを改善、単純化することができます。設計作業の大半は、システム要件を満たすための一連のコンポーネントを定義したり、各コンポーネントが処理する入出力メッセージを定義したりする作業になります。UML による設計図と、実装に必要なコンポーネントは緊密に対応しています。すべてのコンポーネントが同じメッセージング・インターフェースを共有しているため、それらのコンポーネントを BPM/BPEL 図に追加するのも容易です。先ほど触れたように、この作業は多種多様な方法で再利用および接続が可能なブロックを組み立てる作業と似ています。
  • 開発プロセス。メッセージングに依存する各コンポーネントは自己完結であるため、多くの人で構成されるチームが共同で開発作業を行うことができ、お互いのコードや作業が重複することがありません。理想的な状況では、1 つのコンポーネントやパッケージの作業を 1 人で行うことができます。チーム内の他の人達は、自分以外の誰かのコンポーネントが処理するように設計されている入出力メッセージを知っておきさえすれば十分です。誰か他の人のコードを変更する必要はありません。いくつかのバージョンのコードを作成、管理、マージする必要も最小限になるか、あるいはまったくなくなります。テストや QA のエンジニアはテスト・ハーネスを使って独立にテストを行うことができます。一般にテスト・コードを追加する必要はありません。
  • ログとデバッグ。すべてのコンポーネントが同じメッセージング・インターフェースを使用するため、メッセージを自動的にログに記録することができます。そのため、出力したりログに記録したりするためのステートメントをコード内に追加する必要が最小限になります (こうしたステートメントを追加する作業は、時間がかかる上にエラーの原因になりかねません)。ユーザーはログに記録されたメッセージを調べることで、通常は問題の原因となっているメッセージやコンポーネントを即座に特定することができます (追加の作業は最小限で済むか、もしくはまったく必要ありません)。
  • 開発のスピードとコスト。上記のさまざまな理由から、メッセージング・デザイン・パターンによって、開発スピードを大幅に向上させると同時にコストも大きく削減することができます。
  • 品質とソフトウェアの保守。上記のさまざまな要因の結果、品質やソフトウェアの保守の作業も改善されます。
  • このデザイン・パターンをフルに活用するためには、ソフトウェア・アプリケーションをモデリング、設計、作成する際にメッセージングの視点で考える必要があります。独立したエンティティー (つまりコンポーネント) 同士がメッセージを交換するのです。この考え方に慣れるためには学習期間と訓練が必要かもしれません。メッセージングの手法は自然で直感的であり、現実の世界とも調和していますが、従来の手法ではライブラリーを利用したり、(ローカル、リモート両方の) メソッドやプロシージャーの呼び出しを行ったりしています。
  • MDP はステート・マシンのように動作します。従ってMDP を拡張することで、非常に自然で直感的な形で耐障害性機能を実現することができます。そのためにはコンポーネントを複製し、コンポーネント同士のやり取りを合意アルゴリズムによって調整します。MDP を使用しないプログラムに耐障害性機能を追加しようとすると、その作業は一般に困難なものになりがちです。

実装とコードの例

メッセージング・デザイン・パターンの実装には Jt メッセージング・インターフェース (JtInterface) を使用します。このインターフェースは 1 つのメソッドで構成されています。

リスト 1. メッセージング・インターフェース
public interface JtInterface  {

/**
  * Jt messaging interface used for the implementation
  * of the messaging design pattern.
  * Process an input message and return a reply (output message). 
  */

  Object processMessage (Object message); 
}

このメッセージング・インターフェース (JtInterface) は単純ですが強力です。このインターフェースが単純だからと言って甘く見てはけません。このインターフェースには 1 つのメソッドしか必要ないのですが、このメソッドが、リモートとローカルのフレームワークのコンポーネントに適用される汎用メッセージング・インターフェースとして動作します。このインターフェースは、あらゆるタイプのメッセージ (Object クラス) を扱うことができます。ここでは Java による実装を説明しますが、MDP とその関連フレームワークの実装には任意のコンピューター言語や技術を使用することができます。


デザイン・パターンの実装

先ほど触れたように、MDP は GoF (Gang of Four)、DAO、J2EE など、他の有名なデザイン・パターンを実装したり、その実装を容易に行えるようにしたりするために使用されています。それがどのように実現されているかを、2、3のパターンを使って説明しましょう。これらのパターンと同じ概念を他の多くの実装にも適用することができます。Jt フレームワークはこれらのパターンを採用することで、高度な機能を実装しています。

プロキシー

メッセージング・デザイン・パターンでは、プロキシーを容易に実装することができます。メッセージングの手法を使用する場合には、プロキシーは主に、入力メッセージを実際の対象に転送する役割を担います。

図 4. MDP でプロキシーを実装する
MDP でプロキシーを実装する

アダプター

メッセージング・デザイン・パターンでは、アダプターを容易に実装することができます。アダプターの主な目的は、送信者と受信者との間のメッセージを変換し、送信者と受信者を相互に接続することになります。

図 5. MDP でアダプターを実装する
MDP でアダプターを実装する

Web サービスによるアクセス、そして通信手段を意識しないアクセス

MDP の送信者と受信者は、同じホスト上で実行されている必要がないことに注意してください。これは、メッセージをリモート・コンポーネントに送ることができるためであり、MDP ではこの点についての制限はありません。現実の世界のたとえを使うと、皆さんは部屋をまたがって友人とコミュニケーションすることや、何千マイルも離れた友人と電話やインターネットで会話をすることもできます。MDP は、こうしたシナリオをすべて処理することができます。皆さんと友人は、2 人の会話がどのように伝送されるのか (技術、通信プロトコル、セキュリティー・メカニズム、等々) を気にする必要がありません。本来あるべき姿のとおり、皆さんから通信手段は見えません。

図 6 に示すように、メッセージング・デザイン・パターンと、先ほど説明した他のいくつかのデザイン・パターンとを組み合わせ、リモート・コンポーネントへのアクセスを実装することができます。MDP を利用すると、使用されるプロトコルや通信技術にかかわらず、それらの技術を意識せずにセキュアにリモートのコンポーネントやサービスにアクセスすることができます。つまりリモート・コンポーネントはローカル・コンポーネントとして扱われます。メッセージの送信には、Web サービス、REST、EJB、RMI、HTTP、ソケット、SSL、あるいは類似の任意の通信用のインターフェースを使用することができます。これは、上で説明したデザイン・パターンによってリモート API に関する複雑さが見えなくなるためです。

図 6. MDP により、通信手段を意識せずに分散コンポーネントやサービスにアクセスする
MDP により、通信手段を意識せずに分散コンポーネントやサービスにアクセスする

わかりやすくするために、この UML 図やこれ以降に示す UML 図では、メッセンジャー・コンポーネントとその中心である processMessage() メソッドは削除してあります。非同期メッセージングはサポートされていますが、同期メッセージングのみを示してあります。

  1. プロキシー: メッセージは、リモート・コンポーネントのプロキシーを介してリモート・コンポーネントに送信されます。
  2. リモート・アダプター: メッセージを変換することでリモート API とのインターフェースを取れるようにするアダプターです。
  3. ファサード: 適切なリモート・コンポーネントにメッセージを転送します。ファサードには通常、セキュリティー機能も用意されています。

現実の世界のたとえに戻ると、電話会社によって維持されるフレームワークには、他の参加者を見つけるための何らかのレジストリー (電話帳) が必要です。各エンティティーには、電話番号または ID が関連付けられています。必要なものは、簡単な命名規則のみです。場合によると、市外局番や国番号も提供する必要があります。郵便サービスや皆さんのインターネット・サービス・プロバイダーも、比較的簡単な命名規則を使っています。

他のサービス・プロバイダーは、このフレームワークを利用して、カスタムの認証メカニズムや承認メカニズムを使用することができます。例えば銀行には、こうした電話システムを利用した、認証と承認用のアクセス管理メカニズムがあります。私達が口座へアクセスできるようになるには、本人であることを認証するための何らかの情報を提供する必要があります。

そのために追加が必要なフレームワークのコンポーネントは、上記で概説したコンポーネントと大きく異なるわけではありません。ファサード・コンポーネントは通常、セキュリティー (メッセージングの認証と承認) を扱います。メッセージが受信者に転送される前に、ファサードはそのメッセージに対し、復号、承認、認証といった処理を行います。

図 7. MDP によって分散コンポーネント/サービスにセキュアにアクセスする
MDP によって分散コンポーネント/サービスにセキュアにアクセスする

この場合には以下のコンポーネントが関係します。

MessageCipher: 入力メッセージの復号と応答メッセージの暗号化を行うコンポーネント。このコンポーネントを構成することで、特定の暗号化手法を使用することができます。

ComponentRegistry: このコンポーネントによって、システムは ID でコンポーネントの登録と参照を行うことができます。

AccessManager: リモート・コンポーネントへのアクセスに対する許可と拒否を行います。AccessManager は、受信した各メッセージに対する認証と承認を行います。AccessManager がメッセージを認証できない場合には、そのメッセージは受信者には送達されません。


フレームワークのセキュリティー

MDP は直感的かつ自然な方法でセキュリティーの課題に対処することができます。MDP により、否認防止機能を備えたエンドツーエンドのメッセージ・レベルのセキュリティー (トランスポート・レベルのセキュリティーではありません) を実現することができます。また、例えばメッセージの機密部分のみを暗号化するなど、MDP を使って選択的に暗号化することもできます。MDP にはよく知られているセキュリティー・メカニズムを適用することができますが、その一方で、このモデルは特定のメッセージ・フォーマット (XML、SOAP など) に制限されることはありません。あらゆるメッセージ・フォーマットと RESTful なサービスに対応することができます。そうした中には、独自のメッセージ・フォーマットやカスタムのメッセージ・フォーマットも含まれます。

メッセージングの手法を使用する場合には、セキュリティーに関するほとんどの側面がメッセージ送信側と受信側には見えなくなる可能性があることに注意してください。例えば送信側と受信側は、セキュリティーが使用されているかどうか、どのようにセキュリティーが実装されているか、などを過度に意識する必要はありません。必要なセキュリティー・コンポーネントとメカニズムは、フレームワークによって提供されます。現実の世界のたとえを使うと、一般的には、サービス・プロバイダーがプライバシーやセキュリティーを考慮して皆さんの会話を暗号化しているかどうかを皆さんや皆さんの友人は気にする必要がありません。また Jt フレームワークは宣言型のセキュリティーを使用しているため、誤りを起こしやすいセキュリティー・コーディングが必要ありません。最後に、特定の要件に基づくカスタムのセキュリティー・メカニズムにも対応することができます。


非同期メッセージング、双方向メッセージング、マルチスレッド

今度は、皆さんの E メールのメールボックスや郵便箱を考えてみましょう。メッセージは非同期で送られ、皆さんがそうしたメッセージを処理する準備ができるまで、メッセージ・キューに置かれるか、あるいは積み重ねられています。MDP は、非同期メッセージングやマルチスレッドに関わる複雑さを処理することができます。フレームワークの各コンポーネントは独立した別のスレッドで実行することができます。これは現実の世界を自然な形で表現しており、各コンポーネント (エンティティー) はシステムの他の部分とは独立して実行できる自己完結的なユニットです。メッセージはコンポーネント自身の独立したスレッドを使って非同期で処理されます。Jt フレームワークの場合、この機能はメッセージング・キューを使って実装されます。コンポーネントはマルチスレッド処理のために別のロジックを追加する必要はありません (マルチスレッド処理は時間がかかり、複雑で、エラーを起こしがちです)。

また、メッセージを非同期で返送し、双方向通信を確立することもできます。MDP では、コンポーネントとアプリケーションが相互に通信する双方向の非同期メッセージングをモデル化することができます。同期型と非同期型のメッセージングを組み合わせることもできます。皆さんが E メール・メッセージを読んでいる時に、同僚や上司が仕事の進捗を確認するために皆さんのところにやって来るケースを考えてみてください。


パフォーマンス、スケーラビリティー、耐障害性に対する考慮

MDP モデルは単純ながらも堅牢で、さまざまな用途に適用することができます。また、MDP モデルを使用すると、分散型アプリケーションにまつわる複雑な問題を処理することができます。MDP は、スケーラビリティーや可用性に関する一般的なメカニズム (クラスタリング、ロード・バランシング、フェイルオーバー、キャッシング、など) にも対応しています。例えば、MDP をベースとする SOA アプリケーションや ESB アプリケーションを 1 つのコンピューター・クラスター上で実行することで、信頼性や可用性を向上することができます。また MDP を使用する際には、プロトコルや技術の選択や組み合わせを柔軟に行うことができます。特定の技術やプロトコルに制約されることはありません。パフォーマンスや可用性に関する特定の要件に応じて、技術やプロトコルを柔軟に選択することができます。

また MDP を非常に自然な方法で拡張し、耐障害性の機能と手法を実現することもできます。ステート・マシンを複製する手法は耐障害性の高いシステムを実装するための一般的な方法であり、コンポーネントを複製し、コンポーネント同士のやり取りを合意アルゴリズムによって調整します。フレームワークの各コンポーネントは、まさにステート・マシンのように動作します。入力メッセージ、出力メッセージ、コンポーネントの状態は、このモデルの一部です。


ESB (Enterprise Service Bus) 機能

Jt デザイン・パターン・フレームワークはまた、ESB (Enterprise Service Bus) 機能を提供するメッセージング・エンジンでもあります。Jt デザイン・パターン・フレームワークでは、リモート・アプリケーション内部で実行するコンポーネントに対し、それらのコンポーネントから見えない形でアクセスすることができます。(ローカルとリモートの) フレームワークの各コンポーネントは、メッセージをセキュアに交換することができます。また Jt フレームワークでは、アプリケーションで使用される技術 (JMS、Web サービス、EJB、REST、HTTP、EJB など) に関わらず、異機種混成のアプリケーションに接続することができます。それを可能にするのは、Jt フレームワークによって実装されるデザイン・パターン (メッセージング、アダプター、リモート・プロキシー、ストラテジー、ファサードなど) です。Jt による ESB 実装は、以下の主なコンポーネントで構成されています。

  • ESB アダプター
  • JMS アダプター (ポイント・ツー・ポイント型とパブリッシュ/サブスクライブ型)
  • EJB アダプター
  • EJB プロキシー
  • RESTful な Web サービス・アダプター
  • セキュアな Web サービス・アダプター (Axis)
  • Axis プロキシー
  • メッセージ暗号化
  • メッセージ認証
  • アクセス・マネジャー
  • データ・アクセス・オブジェクト
  • Java メール・アダプター
  • XML/コンポーネント変換機能

これらのコンポーネントは「レゴ/メッセージング」アーキテクチャーを使用することで、複雑なフレームワーク・アプリケーションにプラグインすることができ、しかもコンポーネントの交換は容易です。これらのコンポーネントをさまざまに組み合わせ、特定のビジネス要件を満たすことができます。この場合、これらのビルディング・ブロックを組み合わせて ESB (Enterprise Service Bus) 機能を実装することができます。

Jt フレームワークの ESB アダプターにより、さまざまなアプリケーションを Jt の ESB に接続することができます。ESB アダプターを構成することで、メッセージ交換に任意のストラテジーを使うことができます (JMS、セキュアな Axis Web サービス、EJB、セキュアで RESTful な Web サービス、HTTP など)。カスタムのストラテジーやプロトコル、独自のストラテジーやプロトコルを使うこともできます。また ESB アダプターやその他の ESB コンポーネントにより、メッセージは適切なフォーマットやプロトコルに自動的に変換されます。

参考文献

学ぶために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=497396
ArticleTitle=Jt - Java パターン指向フレームワーク
publish-date=05272010