レベル: 中級 Gary Bist (bist@ca.ibm.com), Staff Technical Writer, IBM
Mikhail Genkin (genkin@ca.ibm.com), Certified IT Architect, IBM
John Green, Advisory Staff Member, IBM
2002年 6月 01日 急激に変化するe-businessの世界で競争上の優位性を保つには、新しい機能をいち早く市場に出す必要があります。今日注目されている新規のエンタープライズ・アプリケーション ("若造") は、しばしば、各種の言語 (例えば "年寄り" のCやCOBOL) でコード化された既存のプログラムを活用しますが、これらのプログラムは、エンタープライズ情報システム (EIS) (CICS、IMS、その他さまざまなERPシステムなど) 上で実行されます。このような環境において、Webサービスは、これらのプログラムを均一のオープン方式で活用するためのメカニズムを提供します。この記事では、WebSphere Studio Application Developer Integration Edition, V4.1のツールと機能を使ってWebサービスを作成する方法について説明します。また、2つの企業がそれぞれのプロセスを統合し、既存のCICSプログラムにアクセスする方法について、例を挙げて説明します。
概要
IBM WebSphere Studio Application Developer Integration Edition, V4.1(以後Application Developer Integration Editionと呼びます) は、Simple Object Access Protocol (SOAP)、Web Services Description Language (WSDL)、Web Service Invocation Framework (WSIF) などのオープン・スタンダードに基づくツールを提供します。これらのツールは、既存の非リレーショナルEISシステムへのアクセスに不可欠なJ2EE Connector Architecture (JCA) に対しても広範囲のサポートを提供します。
この記事では、Application Developer Integration Editionコンポーネントを使用してWebサービスを作成する方法について説明します。2つの企業がそれぞれのプロセスを統合する例を使って、Webサービス・ベースの企業間 (B2B) 統合を実現するための1つのアプローチを提示し、既存のCICSプログラムへのアクセス方法を示します。
WebSphere Studio Application Developer Integration Edition
WebSphere Studio Application Developerには、基本版とIntegration Editionの2種類があります。基本版は、基本的な開発作業用のツールを備えています。Integration Editionは、基本版のツールの他に、より大型のエンタープライズ・アプリケーションを作成するためのサポートも提供します。
-
基本版
- 標準のJ2EEアプリケーションを作成するために必要なすべての機能を備えています。例えば、以下のような操作を行うためのツールです。
- Javaコードを作成、デバッグ、およびテストする
- Webアプリケーションを開発する (HTML、JavaServer Pages (JSP) テクノロジー、およびサーブレットを含む)
- エンタープライズJavaBeans (EJB) を開発する
- XML文書を作成し処理する
-
Application Developer Integration Edition
- すべての基本機能を備えているほか、B2B統合に基づく強力なWebサービス用に設計されたツールが追加されています。エンタープライズ・サービス・ツールキットは、デベロッパーの生産性を最大化するための革新的なツールを提供します。例えば、次のようなものです。
- デベロッパーをEJBプログラミングの複雑な作業から解放する高水準サービス中心型プログラミング・モデル(EJBコンポーネントの上に構築)。
- サービス・ディスカバリーおよびトランザクション・メタデータ・キャプチャー用のツール。
- WSDLファイルを処理するための専用エディター。
- Javaエンタープライズ・サービスからJava実装スケルトンを作成するためのツール。
- EISシステムへのトランザクション・ベース・アクセスを行うためのJCA準拠リソース・アダプター。
- Application Developer Integration Editionツールとの互換性を持たせるために、ユーザー独自のリソース・アダプターに追加できる拡張機能のセット。
- エンタープライズ・アプリケーション・デベロッパーのアクティビティーをサポートするための、このIDEにおける特別のパースペクティブ (つまり、エンタープライズ・サービス・パースペクティブ)。このパースペクティブによって生成されるサービスは再利用可能コンポーネントです。
- 複数サービスを扱い、それらのサービス間のビジネス・ロジックの作成を可能にするエディター。
- 自動化サービス・パッケージングおよび配備のためのウィザード。
- Javaエンタープライズ・サービスを起動するJavaプロキシーを作成するためのツール。
Application Developer Integration Editionは、以下のJCA準拠リソース・アダプターと一緒に出荷されます。
- CICS ECIリソース・アダプター (CICSサーバー上のプログラムにアクセスする)
- CICS EPIリソース・アダプター (CICSサーバー上の3270プログラムにアクセスする)
- HOD 3270リソース・アダプター (3270画面を持つホスト・システムにアクセスする)
- IMSリソース・アダプター (IMSサーバー上のIMSプログラムにアクセスする)
これらの開発リソース・アダプターを使えばエンタープライズ・サービスの開発やテストが可能になりますが、実稼働環境に配備する場合は、ランタイム・リソース・アダプターの使用のためのライセンスが必要です。
ここで、上記リストに含まれていないリソース・アダプターを持っていると仮定します。Application Developer Integration Editionには、いくつかの拡張機能 (JCAプラグイン と総称されます) が組み込まれています。これらの拡張機能は、JCAに準拠するすべての既存のリソース・アダプターに追加できます。これらの拡張機能を追加されたリソース・アダプターは、Application Developer Integration Edition開発ツールと互換性を持ちます。参考文献の "Enabling a J2EE Resource Adapter" は、これらの拡張機能を詳しく説明しています。
図1 は、Application Developer (基本版) とApplication Developer Integration Editionコンポーネントの関係を示しています。
図1. Application DeveloperとApplication Developer Integration Editionの関係
サービスにおけるEISシステムの統合
EISシステムのプログラム (多くの場合、レガシー・アプリケーションに入っています) を統合するには、通常、以下のステップを実行する必要があります。
- プログラム・ソース (例えば、COBOLコピーブック) をインポートし、プログラムの入出力を記述するメタデータを生成する。生成したWSDLコードは直列化（serialize）される。
- サービスのためのEJBベースの配備されるコードを生成する(レガシー・プログラムのプロキシーとして働くコードを含む)。
- トランザクションを起動するサービスを記述するWSDLサービス定義を作成する。このサービス定義を使えば、単体テスト環境または実稼働環境から配備されたサービスを起動することができる。
- サービスの単体テストを実行し、それを実稼働環境に配備する。
次のセクションでは、B2Bとエンタープライズ統合の両方を取り入れたケース・スタディーを使ってこれらの点について話を発展させていきます。
ケース・スタディー: Travel Simplified社
Travel Simplified社は、カスタマー用のWebサイトを作りたいと考えている架空の旅行代理店です。このWebサイトは、ブラウザーを使ってどのインターネット・ユーザーもアクセスすることができます。このサイトは以下のユース・ケースをサポートする必要があります。
- ユーザーがログオンし、サイト上の使用可能なサービスをブラウズする。
- サイトは、ユーザーが指定した出発地と目的地、および時刻に基づいて旅行オプションを生成する。
- ユーザーは、飛行機、バス、および列車を予約する。
- ユーザーは、クレジット・カード番号を入力して予約を完了する。
図2 は、Travel Simplified社が、上記のユース・ケースをサポートするために、アクセスし統合しなければならないサービス (他の組織が提供) とEISシステムの集合を示しています。
図2. 統合するEISシステムとサービスの集合
Travel Simplified社Webサイトの主要目的、つまり課題は、カスタマーの観点に立ったシームレスなビューを作ることです。このWebサイトを使用するカスタマーは、サービスが、別のEISシステムを操作している他の組織からデータを入手しているということを知りません。Webサービスは、理想的な一様のB2B統合ストーリーを提供します。
図3 は、Travel Simplified社Webサイトのアーキテクチャーを示しています。
図3. サイトのアーキテクチャー: Travel Simplified社
プロバイダーを構築する: Simplified Airlines社
Travel Simplified社が航空予約サービスをカスタマーに提供できるようになるには、誰かがこのサービスを提供しなければなりません。そのサービスを提供するのがSimplified Airlines社です。Simplified Airlines社は、インターネットを介して自社の予約システムを提携先に提供することに決定した架空の会社です。
図4 は、Simplified Airlines社Webサイトのアーキテクチャーを示しています。この会社の提携先が作成したアプリケーションは、SOAPおよびHTTPプロトコルを使ってSimplified Airlines社のサービスにアクセスできます。
図4. サイト・アーキテクチャー: Simplified Airlines社
Simplified Airlines社のITインフラストラクチャーは、CICSのもとでCOBOLプログラムを実行するメインフレームの周りに構築されています。これらのプログラムは、この会社が提携先に公開する必要がある機能を備えています。例えば、以下のようなものです。
- 予約番号による予約情報の検索
- 予約
- 予約の取り消し
- 予約情報の変更 (日付、時刻、フライト・ナンバー)
これらの機能は、Simplified Airlines社サービス・インターフェースの基礎を形成しています。以下のセクションでは、ある単一の機能、つまり予約IDによる予約検索を可能にする機能の統合方法に焦点を絞って説明します。他の機能を組み込むステップも同じことだからです。トランザクション名はRESBYIDです。この機能にアクセスするには、CICS ECIプロトコルを使用します。また、この新規のサービスが、SOAPプロトコルを使ってインターネットからアクセスできるということも確認します。
以下のステップは、Application Developer Integration Editionを使用してこのサービスを構築し、テストするために行ったものです。各ステップについては、この例を進めながらさらに詳しく説明します。
CICS ECIサービスを作成する
エンタープライズ・サービスにおける最初の一連の作業には、サービスの定義が含まれます。サービスを定義するというのは、そのサービスのためのプロジェクトが作成され、ネームスペースやポート・タイプ (インターフェース) 名などの詳細を指定したWSDLファイルが作成されるということです。また、接続ファクトリー情報も指定する必要があります。この情報は、WSDLサービスとCICSサーバー間の接続を確立するために使用されます。次に、CICSサーバーの入出力構造が入っているCICS COBOLまたはCプログラムをインポートして、WSDLファイルに操作（operation）を埋め込んでいきます。
サービス・プロジェクトを作成する
Application Developer Integration Editionを始動すると、デフォルトでEnterprise Servicesパースペクティブが立ち上がります。パースペクティブは、参照のためのフレーム（枠）のようなものです。サービスのナビゲーションには、以下の3つのフォルダーが表示されます。
- サービス・プロジェクト -- ユーザーが作成したエンタープライズ・サービスのリスト。
- 配備済みサービス -- ユーザーが配備したサービスのリスト。
- リソース・アダプター -- 各種EISにアクセスするために使用されるリソース・アダプターのリスト。
サービスの作成を開始するには、サービス・プロジェクト・ウィザードを立ち上げ、プロジェクト名を指定します。このウィザードが終了すると、Service Providers Browserツールが立ち上がります (図5 を参照)。このツールはサービス作成タスクの開始点です。例えば、CICS ECIリンクを選択すると、CICS ECIプログラムにアクセスするサービスを作成するためのツールが表示されます。
図5. サービス・プロジェクトの作成とService Providersブラウザーのオープン
COBOLまたはCファイルをインポートする
CICS ECIプログラムの操作を定義する場合は、COBOLまたはCファイルをインポートして入力および出力メッセージをWSDLで定義します。操作の定義に入る前に、COBOLまたはCファイルをローカル・ファイル・システムからワークベンチにインポートする必要があります。
Application Developer Integration Editionでは、インポート操作が容易になります。新たに作成したプロジェクトを選択し、Application Developer Integration Editionツールバーの「Create a Java package (Javaパッケージの作成)」アイコンをクリックします。パッケージを作成したら、インポート機能を使ってCOBOLまたはCファイルを読み込みます。COBOLファイルをワークベンチにインポートしたら、サービス定義を開発できます。
CICS ECIサービス定義を作成する
CICS ECIサービス定義の作成はエンタープライズ・サービス開発作業の核心をなし、Application Developer Integration Editionには、その作業をできるだけ簡単にするためのツールが用意されています。
まず、サービス・プロバイダーのリストからCICS ECIを選択します(図5 を参照)。サービス定義は、Application Developer Integration Editionで生成されたWSDLファイルによって記述されます。(WSDLの詳細については、参考文献のWSDL仕様を参照してください。) 要するに、XMLを使用してサービスを定義します。WSDLで作成されたサービス定義は、実行時のインプリメンテーションには関係なく、システム要求のフォーマットを記述します。サービス定義では、サービスを配備する場所と、サービスを利用するアプリケーションで実行できる操作が記述されます。
CICS ECIをサービス・プロバイダーとして選択すると、「connection properties (接続プロパティー)」ページが開きます。ユーザーのCICSサーバーの接続値を入力します (図6 を参照)。
図6. CICS ECIサービスの接続プロパティー
「Add Service (サービスの追加)」を選択すると、WSDLに必要な名前 (ネームスペースなど) を入力するよう要求されます。これは、サービスおよびポート・タイプに固有の論理ネームスペースであり、関連する操作をグループ化します。このネームスペースはJavaパッケージの生成に使用されます。例えば、指定するネームスペースがhttp://sample.ibm.com/ であれば、生成されるコードのJavaパッケージは逆のcom.ibm.sample になります。
このツールを使用する際には、多少の柔軟性が許されます。例えば、生成されたXSDスキーマをインラインにする (つまり生成されたWSDLファイルの中に含める) ことも、WSDLファイルから分離することもできます。COBOLまたはCインポート・ツールを処理する場合は、これらのタイプのXSDスキーマが常にインラインになります。図7 は、サービスのフォルダーと名前を持つページを示しています。
図7. サービスのネームスペースとポート・タイプの定義
「Add Service (サービスの追加)」機能を完了すると、WSDLインプリメンテーション (サービス) およびインターフェース・ファイルが作成されます。WSDLインプリメンテーション・ファイルは、WSDLエディターの「Binding (バインディング)」ページで開かれます。通常、関連する操作はポート・タイプにグループ化されます (例えば、銀行口座の照会と更新を行うすべての操作をグループ化します)。「Binding (バインディング)」ページでは、アクセスしたい各CICS ECIプログラムに対応する操作群を定義することができます。これを行うには、新規の操作を作成、すなわち、インターフェースWSDLには、そのポート・タイプの中の操作、メッセージ、およびXSDタイプを挿入し、該当するバインディングのインプリメンテーションWSDLには、一致する操作、typeMap、および各タイプごとのマーシャリング情報を挿入します。
操作を作成する場合、最初に実行するステップは、ECI操作バインディング・プロパティーの指定です。これらのプロパティーは、ECI対話仕様 (ECIInteractionSpec) のプロパティーにマップされます。これらのプロパティーには、入出力情報をCICSサーバーと交換するためにサービスが知っておく必要がある詳細情報が含まれています (CICSサーバーで起動するCICSプログラムを識別する機能名を指定します)。次に、入出力操作をCICSプログラムにマップする入出力メッセージをWSDLで作成します。これらのステップを組み合わせると、CICSトランザクションを起動する方法が作成されます。
サービス定義の中では、Application Developer Integration Editionは、WSDL操作と先にインポートしたCOBOL構造とを関連付けるツールを使用します。ではまず、このツールを使用して機能名を識別します (図8 を参照)。
図8. プロパティーと機能名のバインディング
サービス操作の名前を指定して、その操作の作成へ進みます。この名前は、通常、機能のアクションを表します。私たちは、予約データを検索するので、getReservationInfoを使用しました。入出力メッセージを定義するには、インポート機能を使用し、先にワークベンチにインポートしたファイルを選択します。このファイルには、この機能のための入出力タイプが含まれています。COBOLまたはCファイルを識別すると、コード・ページ、浮動小数点フォーマット、エンディアンなどの任意のプラットフォーム固有のプロパティーを指定することができます(図9 参照)。
図9. プラットフォーム固有のプロパティー
プラットフォーム・プロパティーを指定したら、サービスが使用するCOBOLレベル1またはC構造共通域をCOBOLまたはCファイルから選択します。これでサービス定義はほぼ完了ですが、ツールが複数の可能なオプションを提示します。例えば、入力メッセージを出力メッセージとして使用するオプションを選択することもできます。CICSプログラムが別の出力データを戻すことができる場合は、操作用にいくつかの出力を作成することができます。
最後のステップとして、ツールは、インプリメンテーションおよびインターフェースWSDLファイルに操作、入出力メッセージ、およびタイプを挿入します。Application Developer Integration Editionはコードをビジュアル・フォーマットで提示しますので(図10 を参照)、それをWSDLソース・コードとして表示することもできます。ところで、Application Developer Integration Editionが、ユーザーに代わって (ユーザーには見えないように) マーシャリング・コードを処理したことは明らかです。実行時にCICSサーバーから渡されたデータは、ネットワークでの移送に適したストリームに入れられ、必要なときに、マーシャリングを解除して元に戻すことができます。
図10. ビジュアル・フォーマットのサービス定義
サービスをテスト環境に配備する
配備には2つの局面があります。すなわち、サービス・ファイルをエンタープライズ・アーカイブ (EAR) ファイルにパッケージする局面と、そのEARファイルをアプリケーション・サーバーに配置する局面です。どちらの局面も、しばしばアプリケーション・サーバーへの配備と呼ばれます。Application Developer Integration Editionには、配備操作を簡単にするためのツールが用意されています。配備するには、まず、EARファイルの構造を定義するエンタープライズ・アプリケーション・プロジェクトを作成します。配備済みコードの一部をEJBセクションに配置し、一部をWebセクションに配置し、一部をクライアント・コード・セクションに配置することができます。大きなEARファイルの場合、このように分割すると、ファイルの管理がやりやすくなります。
EARファイルの構造を定義したら、前に作成したバインディング・ファイルを選択して、ツールバーから配備ウィザードをクリックします。ユーザーのファイルをEARにパッケージするときに、Application Developer Integration Editionは、必要な情報のほとんどをデフォルトで提供しますが、必要な場合は、それをオーバーライドすることができます。例えば、私たちは、CICSサービスをSOAPサービスとしても公開したいので、SOAPをインバウンド・バインディング・タイプとして選択しました (図11 を参照)。
図11. EAR構造へのサービス・ファイルのマッピング
この時点で、Java Naming and Directory Interface (JNDI) 名も指定する必要があります。この名前は、実行時にCICSサーバーに接続するときに、アプリケーション・サーバーが知っていなければなりません。また、SOAP固有のバインディング・プロパティーを調整することもできます。通常、デフォルト値を使用します。
このようにしてすべての機能を統合したら、Simplified Airlinesサイトの作成は基本的に完了です。残った作業は、テスト環境または実稼働環境へのサービスの配備です。テスト環境と呼ぶのは、Application Developer Integration Editionが、アプリケーション・サーバーをエミュレートする完全なテスト環境を提供するからです。実稼働環境に配備する前に、WebSphereテスト環境を使ってみるのもいいでしょう。テストが終わったら、EARファイルを実稼働環境に配置します。テスト環境であれ実稼働環境であれ、次に必要な作業は、アプリケーションが間接的にサービスにアクセスするために使用するプロキシーの作成です。
Simplified Airlines社とTravel Simplified社のサイトを統合する
これで航空予約サービスが出来上がりましたので、それを全体的な旅行代理店サービスに統合する必要があります。すなわち、サービスの中にサービスを作成します。我々はサーバー側のサービスをクライアント上で代行するためのプロキシーを作成しました。
サービスのSOAPプロキシーを作成する
プロキシーは、関心のあるサービスに対してリモート・プロシージャー呼び出しインターフェースを提供します。このアプリケーションは、プロキシーでローカル・メソッドを起動します。プロキシーは、サーバーとの通信を処理します。多分読者にも推察できるように、Application Developer Integration Editionは、ユーザーに変わってプロキシーを構築してくれるツールを提供します。Simplified Airline社のサービスをTravel Simplified社のサイトに統合するには、そのサービスに関するインターフェースおよびSOAPバインディング情報を定義するWSDLファイルを入手する必要があります。そのためには、これらのファイルを一般に公開して使用できるようにするUniversal Description, Discovery and Integration (UDDI) レジストリーを使用します。このほか、関連する組織に直接連絡する方法もあります。上記の配備ステップでは、エンタープライズ・アプリケーション・プロジェクトのServices_SOAP WebプロジェクトにWSDLファイルを生成しました。次のステップは、単なるプロキシー・ウィザードの実行です。
配備ウィザードと同様に、多くのフィールドが完了しました (図12 を参照)。変更の可能性がある1つのフィールドは「Destination folder (宛先フォルダー)」です。それは、このフォルダーがプロキシーの行き先を決定するからです。このケースでは、ClientSampleフォルダーを選択しました。なぜなら、このフォルダーには、サービスを起動するクライアント・コードが入っているからです。
図12. プロキシー情報の指定
プロキシー情報の重要な部分の1つは、もちろん、サーバーで起動の対象となる操作です。サービスは多くの操作を提供することがあります。プロキシーでは、アプリケーションからアクセスできるようにするために、どの操作を公開するかを選択します。1つまたは複数の操作を選択する必要がある場合は、「client stub (クライアント・スタブ)」スタイルのプロキシーを使用しなければなりません。このプロキシーは、推奨される生成スタイルです。対話仕様 (interactionSpec) などのバインディング操作プロパティーにアクセスする必要がある場合、選択するスタイルは「Command bean (コマンドBean)」になります (図13 を参照)。
図13. プロキシーで公開する操作の選択
Simplified Airline社のサービスをクライアント・コードでテストする
この時点で、SOAPプロキシーを呼び出すクライアント・コードを作成し、それをWebSphereテスト環境で実行します。以下に示すコードは、CICSサーバーから名前を検索し、それをコンソール (標準出力) に出力しました。まず、初めにこういった簡単なプログラムを作成しておいて、サーバーからいくつかのデータを入手できることを確認してみることをお勧めします。1つのトランザクションも処理できない場合、アプリケーションは数千ものトランザクションを処理できるわけがありません。
SOAPプロキシーを呼び出すコード
package sample.cics;
public class TestCustomerSOAP {
public static void main(String[] args){
try { Customer record = new Customer();
record.setCustomernumber("44444");
CustomerInfoSOAPProxy proxy = new CustomerInfoSOAPProxy();
proxy.setCustomerPart(record);
proxy.execute();
record = proxy.getCustomerPart();
System.out.println(record.getCustomernumber());
System.out.println(record.getFirstname());
System.out.println(record.getLastname());
} catch (Exception e) {
e.printStackTrace();
} }
} |
プロキシー・メソッド呼び出しが正しいデータを戻していることを確認できたら、このBeanをアプリケーションの残り (このケースでは、Travel Simplified社Webサイト全体) に簡単に統合することができます。
結論
この記事では、Webサービス、SOAP、およびXMLを使って既存のCICSプログラムをいかに迅速に複合B2Bアプリケーションに統合できるかを示しました。私たちはIBM WebSphere Studio Application Developer Integration Editionを使ってみました。この製品は、特にWebサービス指向のエンタープライズおよびB2B統合アプリケーションを作成するために設計されています。そのコンポーネントを使ってみた後、Application Developer Integration Editionツールを実際的なB2B問題に適用する方法を示すケース・スタディーについて検討しました。いわば、年寄りと若造がすばらしい共同作業をしたことになります。
参考文献
著者について  | | | Gary Bist氏は、IBM Toronto Lab. のスタッフ・テクニカル・ライターです。氏は、Application Developer Integration Editionとその前身であるVisualAge for Java, Enterprise Editionの両方のミドルウェア・ソフトウェアの統合に関する製品文書と記事を書いています。氏は、Javaおよびリレーショナル・データベース・コースを開発し、教壇に立った経験を持つ教育専門家でもあります。ウェスタン・オンタリオ大学から英語の修士号を取得しています。氏のEメール・アドレスはbist@ca.ibm.com です。 |
| 
| | Mikhail Genkin氏は、テクニカル・ソリューション・デザイナーとして、IBM Toronto Software Development Lab. のIBM WebSphere System Houseグループと一緒に働いています。JavaおよびWebサービス・ベースのエンタープライズ・アクセス用のIBMおよび競合他社ツールに対して専門的なレビューを行っています。また、J2EE、Webサービス、RDBMS、およびEISアクセス用のWebSphereツールの作成を担当している、いくつかのIBM開発チームに対して、それぞれの製品の使いやすさ、パフォーマンス、および相互運用性の観点から助言を与えています。氏は、VisualAge for Java、Enterprise Edition、WebSphere Studio Application Developer、およびWebSphere Studio Application Developer Integration Editionのいくつかのリリースの開発にかかわりました。氏は、カールトン大学 (カナダ、オタワ) から地球物理学の学士号、オタワ大学から地学の修士号を取得しています。氏は、Sun認定Javaプログラマーであり、かつIBM認定デベロッパー・アソシエイト (IBM Visual Age for Java) です。氏のEメール・アドレスはgenkin@ca.ibm.com です。 |
| | | John Green氏は、IBM Toronto Laboratoryのアドバイザリー・スタッフ・メンバーであり、コネクター・アーキテクチャーとツールの開発に当たっています。J2EE Connector Architectureのエキスパートであり、レガシーEISにアクセスしています。1987年にIBMに入り、現在は、Javaからエンタープライズ・アプリケーションにアクセスするためのツールやライブラリーの開発に携わっていますが、それ以前は、他のいくつかのプロジェクトを担当していました。氏は、VisualAge for Java Enterprise Access Builderのいくつかのリリースの開発にかかわったこともあります。最近、WebSphere Studio Application Developer Integration EditionのJ2EEコネクター・ツール・コンポーネント・チームのテクニカル・リーダーになりました。1987年に、キングストンのクイーン大学からコンピューター・サイエンスの理学士号を取得しています。 |
記事の評価
| 
