レベル: 初級 Bob Moore (remoore@us.ibm.com), Advisory Software Enginner, IBM
Brad Topol (btopol@us.ibm.com), Senior software engineer, IBM
Jie Xing (jiexing@us.ibm.com), Advisory Software Engineer, IBM
Thomas McElroy (tmcelroy@us.ibm.com), Advisory Software Engineer, IBM
Belinda Chang (belchang@us.ibm.com), Software Engineer, IBM
2005年 11月 05日
2006年 3月 16日 更新 自動問題判別ツールを使って、IBM WebSphere® PortalあるいはWebSphere Application Serverのログ・ファイルからのログ・ファイルを分析しましょう。これらのログ・ファイルには、コモン・ベース・イベントを含んだXML文書が含まれていますが、それだけが含まれているわけではありません。
はじめに
この記事は、前回の記事、「シンプトン分析の概要」で始まった、自動問題判別ツールによるシンプトン（症状）分析に関する説明を締めくくります。このツールがどのようにシンプトンを分析するかの詳細に入る前に、少し前に戻り、自動問題判別ツールのシンプトンが、オートノミック・コンピューティング・アーキテクチャーで記述されるシンプトンと、どのように関係するのかを調べることにします。
自動問題判別ツールでのシンプトンと、オートノミック・コンピューティングでのシンプトンとの関係
IBMが推進するオートノミック・コンピューティングでは、シンプトン・フォーマットも定義しています。このフォーマットは、標準フォーマットとして使われることを意図しています。つまり、様々なアプリケーションや製品で生成され、使用されるシンプトンを定義するための、デファクト・スタンダードとなることを意図しているのです。オートノミック・コンピューティングのシンプトン・フォーマットは、表現力豊富であり、より柔軟で高度な分析をサポートでき、ある特定なシンプトンに関連付けて推奨事項やアクションを定義することができます。オートノミック・コンピューティングのシンプトン・フォーマットについて詳しくは、参考文献を見てください。
自動問題判別ツールでのシンプトンは、シンプトンの定義や分析のための、エントリー・レベルのソリューションとして位置づけられています。将来、自動問題判別ツールでのシンプトンは、ナレッジ・ベースを機能向上させ、より良い問題判別機能を提供するために、オートノミック・コンピューティングのシンプトンを利用するようになるかも知れません。さらに、自動問題判別ツールがサポートしていない、より高度な分析が必要となった場合には、自動問題判別ツールのユーザーは、自動問題判別ツールへの投資を生かしながら、（標準のシンプトン・フォーマットを使って）オートノミック・コンピューティングのツールや技術を利用することができます。
自動問題判別ツールは、どのようにシンプトン分析に役立つのか
自動問題判別ツールのシンプトン分析機能は、経験豊富なサポート担当が問題を診断する際に行うことを自動的に行います。つまり、大量の、そして巨大であるかも知れないログ・ファイルから、その問題に関係した情報を抽出するのです。前回の記事では、そうしたことを、XML文書ではないログ・ファイルに対して行うための、ツールのコンフィギュレーション方法について解説しました。今回は、XML（Extensible Markup Language）文書であるログ・ファイルに注意を向けることにします。こうしたログ・ファイルには、コモン・ベース・イベント要素を含んだXML文書が含まれていますが、それだけが含まれているわけではありません。
対象とするログ・ファイルがXML文書である場合には、ツールによるシンプトン分析全体としてのゴールと実質的な結果は同じままですが、機能をコントロールするために使われる内部実装と言語は、大幅に異なります。ゴールそのものは、単純に記述することができます。つまり、（通常は、非常に大きな）ログ・ファイルから『興味深い』ログ・レコードを抽出し、選択された各ログ・レコードから得られた必要情報を、読みやすいフォーマットで提示することです。ですから、この場合も以前と同様、ツールに対して次の4つの質問に対する答え方を指示する必要があります。
- ログ・レコードを構成するものは何か
- ログ・レコードを興味深いものとしているのは何か
- 興味深いログ・レコードの中の、どの部分を分析レポートの中に含めるべきか
- そうした、ログ・レコードの部分を、レポートの中でどのようにフォーマットすべきか
こうした質問に対する答えは、シンプトン・データベース・スキーマに追加された新しいXML要素である、<xmlDelimiter>要素を使って規定されます。この要素がXML文書であるログ・ファイルに対して果たす役割は、XML文書ではないログ・ファイルに対して<delimiter>要素が果たした役割とまったく同じです。またこれは、ツール全体としての処理の面から見ても、まったく同じです。ツールは、前回の記事で説明した4つのスコーピング変数を使って特定な<delimiterId>要素を探し、この要素が、ある特定なログ・ファイルに対してツールが使うべき<xmlDelimiter>要素を指すのです。
<xmlDelimiter>要素
リスト1は、実際にツールに含まれている、単純な<xmlDelimiter>要素の例を示しています。この要素は、WebSphere® Application ServerとWebSphere Portalが作成するevent.historyログ・ファイルに対する抽出基準を規定しています。documentXsd属性の値（event-history）はこれを、<xmlDelimiter>要素を適用すべき文書型として特定しています。
リスト1. <xmlDelimiter>要素
<xmlDelimiter id="eventhistorydelim" documentXsd="event-history">
<xmlLogRecord elementType="update-event" level="top"/>
<xmlMatch matchAll="true"/>
<xmlGroups>
<xmlGroup xmlTarget="updateEventId" displayName="Fix"/>
<xmlGroup xmlTarget="updateEventResult" displayName="Status"/>
<xmlGroup xmlTarget="updateAction" displayName="Action"/>
<xmlGroup xmlTarget="updateEventStartTimestamp"
displayName="Date/Time"/>
<formatref outputName="html-1" formatName="format-eh1"
</xmlGroups>
</xmlDelimiter>
|
まず、先に挙げた4つの質問に対して<xmlDelimiter>要素はどう答えるのか、を要約するところから始めます。その後で、それぞれを詳細に検証して行きます。
- ログ・レコードを構成するものは何か。この質問には、
<xmlLogRecord>要素が答えます。
- ログ・レコードを興味深いものとしているのは何か。この質問には、
<xmlMatch>要素が答えます。
- 興味深いログ・レコードの中の、どの部分を分析レポートの中に含めるべきか。この質問には、
<xmlGroups>要素が答えます。
- そうした、ログ・レコードの部分を、レポートの中でどのようにフォーマットすべきか。この質問にも
<xmlGroups>要素が答えます。
<xmlLogRecord>要素
XML文書が本来的に持っている構造から、XML文書の中のログ・レコードを特定する作業は、対象とするログ・ファイルがXML文書ではない場合よりも容易です。ログ・レコードの最初の部分に一致する正規表現を構築する代わりに、どのXML要素がログ・レコードとしての要件を満たすかを単純に特定します。そして標準のXML構文解析手法を使って、こうした要素をログ・ファイルから抽出します。<xmlLogRecord>要素は、ログ・ファイル中のログ・レコードを特定するために、2つの属性（elementType属性とlevel属性）を持っています。後者は、他の要素内にネストしている要素を、それ自体ログ・レコードと考えるかどうかによって、「top」あるいは「all」として指定されます。
<xmlMatch>要素
<xmlMatch>要素は、ログ・レコードを『興味深いもの』と考えるための基準を規定します。この点で考えると、データベース・テーブルの、ある行を興味深いものと考えるための基準を規定する、SQLの「WHERE」文と似ています。上記の例は、<xmlLogRecord>要素によって規定されるログ・レコードは『すべて』興味深いと言っているので、少し特別なケースです。もしmatchAll属性が偽に設定されていると（あるいはデフォルトで偽になるようになっていると）、<xmlMatch>要素は、ANDやOR、NOTなどを含んだ詳細な一致基準を規定することができます。
リスト2は、自動問題判別ツールのシンプトン分析文書に対するXMLスキーマのうち、<xmlMatch>要素を定義する部分を示しています。
リスト2. <xmlMatch>要素の定義
<xsd:element name="xmlMatch">
<xsd:complexType>
<xsd:sequence>
<!-- Multiple >choice> elements are ANDed together -->
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="xmlStringAtom"/>
<xsd:element ref="xmlNumericAtom"/>
<xsd:element ref="xmlOr"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="matchAll" type="xsd:boolean"
default="false"/>
</xsd:complexType>
</xsd:element>
|
「matchAll」という特別な場合を除いて、<xmlMatch>要素は、ゼロ以上あるブール条件群を（暗黙的に）ANDしたものを含んでいます。各条件は、atomであるか、あるいは否定されたatomであるか、あるいは2つ以上のatomあるいは否定されたatomのORです。ここでは、まずatomを紹介します。それから<xmlMatch>要素に戻り、こうした選択肢それぞれの例を挙げることにします。こうした例は、リスト8の中で見ることができます。
XML atom
XMLatomを理解するためには、その背景にある設計ゴールをまず理解する必要があります。つまり、自動問題判別ツールのユーザーが、自分たちが必要とするシンプトン分析条件を特定しやすくすることがXMLatomの設計ゴールなのです。私達は、典型的な場合に確実に規定できるようにするために、強力さと一般性を多少犠牲にすることにしました。そのため、<xmlMatch>要素と<xmlGroup>要素はXPath構文に基づいていません。大部分のユーザーが適切に使うには、XPathはあまりにも複雑すぎるのです。
リスト3は、XMLatomの最初の2つのタイプである、ストリング・atomに対する定義を示しています。
リスト3. XMLストリング・atomの定義
<!-- The <xmlStringAtom> element identifies one field of an
XML record to match against. The value is a regular expression,
against which the corresponding field of the XML record is
tested. The attribute "negated" determines whether
the match should be negated, so that XML records that do not
satisfy the indicated match are selected.
-->
<xsd:element name="xmlStringAtom">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="xmlTarget" type="XmlTargetType"
use="required"/>
<xsd:attribute name="negated" type="xsd:boolean"
use="optional" default="false"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
|
ストリング・atomの値は正規表現であり、このatomのxmlTarget属性によって規定される、ログ・レコード中のフィールドに適用されます。negatedというブール属性を使うと、比較結果を「matches」から「doesn't match」に反転することができます。リスト4のストリング・atomの例を見ると、ログ・レコードを選択するための条件が、いかに容易かつ直感的に書けるかが分かると思います。
リスト4. ストリング・atomの例
<!-- CBE situation category equals "StopSituation" -->
<xmlStringAtom
xmlTarget="cbeSituationCategory">StopSituation</xmlStringAtom>
<!-- CBE situation category does not equal "ReportSituation" -->
<xmlStringAtom xmlTarget="cbeSituationCategory"
negated="true">ReportSituation</xmlStringAtom>
<!-- CBE was created in November 2005 -->
<xmlStringAtom xmlTarget="cbeTimestamp">2005-11-.*</xmlStringAtom>
<!-- Update action (in the event.history log) equals "install" -->
<xmlStringAtom xmlTarget="updateAction">install</xmlStringAtom>
|
リスト5は、もう一方のタイプのXML atomである、ニューメリック・atomに対する定義を示しています。このatomの動作は、文字列比較ではなく数値比較を行う点を除けば、ストリング・atomの動作とほとんど同じです。
リスト5. XMLニューメリック・atomの定義
<!-- The <xmlNumericAtom> element identifies one field of an
XML record to match against. The value is an integer, against
which the corresponding field of the XML record is tested.
The attribute "comparisonOperator" indicates the test
to be performed - for example, the comparisonOperator value
"greaterThan" tests whether the value of the field in
the XML record is greater than the value of this element. The
attribute "negated" determines whether the match should
be negated, so that XML records that do not satisfy the indicated
match are selected.
-->
<xsd:element name="xmlNumericAtom">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:integer">
<xsd:attribute name="xmlTarget" type="XmlTargetType"
use="required"/>
<xsd:attribute name="comparisonOperator"
type="ComparisonOperatorType" use="required"/>
<xsd:attribute name="negated" type="xsd:boolean"
use="optional" default="false"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
|
リスト6は、ニューメリック・atomの例を幾つか挙げています。comparisonOperator属性は、皆さんが想像される通り、5つの列挙値（「equalTo」、「lessThan」、「lessThanOrEqualTo」、「greaterThan」、「greaterThanOrEqualTo」）をサポートしています。
リスト6. ニューメリック・atomの例
<!-- CBE severity greater than 10 -->
<xmlNumericAtom xmlTarget="cbeSeverity"
comparisonOperator="greaterThan">10</xmlNumericAtom>
<!-- CBE severity other than 20 -->
<xmlNumericAtom xmlTarget="cbeSeverity"
comparisonOperator="equalTo"
negated="true">20</xmlNumericAtom>
<!-- CBE severity less than or equal to 40 -->
<xmlNumericAtom xmlTarget="cbeSeverity"
comparisonOperator="lessThanOrEqualTo">40</xmlNumericAtom>
|
一致条件を書くための作業を単純化する鍵は、xmlTarget属性にあります。この属性は、一致条件に参加するログ・レコードの「一断片」を特定します。xmlTarget属性の値は、自動問題判別ツール自体に幾つか組み込まれている、特定な値の中から選ばれます。これらの値は一般的に選ばれるたわけではなく、<xmlDelimiter>要素の構築に使いやすいように選ばれています。従ってこれらの値は、XPathのような機構の背景にある設計判断とは非常に異なる設計判断を表します。
 |
歴史的な背景
私達が最初に自動問題判別ツールでXMLログ・レコードをサポートできるようにした時の唯一の要求事項は、ツールがコモン・ベース・イベントを分析できるようにする、ということだけでした。従って、実装全体がコモン・ベース・イベントの分析に焦点を当てていました。後になって、他のXMLログ・ファイル（イベント・ヒストリー・ログなど）も分析するという要求が加わってから気が付いてみると、オリジナル実装の中で本当にコモン・ベース・イベント特有の実装は、ごく僅かしかありませんでした。リファクタリングを行うことによって、実装の大部分を任意のXMLログ・ファイルに適用できるように汎用化でき、コモン・ベース・イベント特有の部分はごく一部分にとどまったのです。リスト7は、この、コモン・ベース・イベント特有のサポートのなごりを示しています。 |
|
この点は、コモン・ベース・イベントの例を使ったリスト4とリスト6の中を見ると、よく分かります。自動問題判別ツールは、「cbeSeverity」という名前のxmlTargetを見つけるように命令されると、コモン・ベース・イベントの「severity」属性の値を返すロジックを呼び出します。しかし、「cbeSituationCategory」という名前のxmlTargetを見つけるように命令されると、非常に異なった動作をします。つまりコモン・ベース・イベントの子要素、<situation>を見つけ、次にその<situation>要素のcategoryName属性の値を返します。この2つの場合の違いはシンプトンを書く人から隠れて見えないため、その人は単純に、「severity equals 10」そして「situation category other than ReportSituation」と考えます。
リスト7は、自動問題判別ツールのシンプトン・スキーマの一部であり、xmlTarget属性のデータ型を定義しています。ここでは、サポートされる文書型（現状では2つのみ）それぞれに対して、異なる範囲を持った列挙値があります。他の文書型へのサポートを追加する場合には、ターゲット・フィールドを特定する追加の列挙値を含めるために、スキーマの更新が必要です。そのためには、自動問題判別ツールそのものを更新する必要がありますが、この更新の目的は単純にスキーマを拡張することだけではありません。更新を行う主な目的は、実際にログ・レコードからのターゲット・フィールド抽出を行うDOMコールを発行する、Java™クラスを追加することです。コモン・ベース・イベントの任意フィールド抽出をサポートする場合、あるいは、ここに挙げていない更新イベントをサポートする場合には、同様な拡張が必要です。現在のターゲット・セットは、シンプトンの作成者が実際によく使いそうな条件をサポートするように選択されています。
リスト7. XmlTargetTypeの定義
<!-- The XmlTargetType contains groups of enumeration values for
each XML schema covered by the analysis function. These values
represent easy-to-understand designations for items to be
extracted from the corresponding documents. Each group
requires its own Java class to perform the extractions.
-->
<xsd:simpleType name="XmlTargetType">
<xsd:restriction base="xsd:string">
<!-- Enumeration values for CBE documents. -->
<xsd:enumeration value="entireCBE"/>
<xsd:enumeration value="cbeSituationCategory"/>
<xsd:enumeration value="cbeSeverity"/>
<xsd:enumeration value="cbeTimestamp"/>
<xsd:enumeration value="cbeMsgId"/>
<!-- Enumeration values for event.history documents. -->
<xsd:enumeration value="entireUpdateEvent"/>
<xsd:enumeration value="updateEventId"/>
<xsd:enumeration value="updateAction"/>
<xsd:enumeration value="updateType"/>
<xsd:enumeration value="updateEventStartTimestamp"/>
<xsd:enumeration value="updateEventEndTimestamp"/>
<xsd:enumeration value="updateEventResult"/>
</xsd:restriction>
</xsd:simpleType>
|
完全一致条件を構築する
命題論理（propositional logic）での任意ステートメントは、それに等価な連言標準形（conjunctive normal form）のステートメントに変換できるため、<xmlMatch>要素は、サポートされている一連のxmlTargetの値を含む、（起こり得る）任意の条件を表現することができます。現実的には、大部分の条件は非常に容易に表現できます。リスト8は、幾つかの例を示しています。
リスト8. 完全一致条件の例
<!-- CBE situation category equals "ConnectSituation" -->
<xmlMatch>
<xmlStringAtom
xmlTarget="cbeSituationCategory">ConnectSituation</xmlStringAtom>
</xmlMatch>
<!-- CBE situation category does not equal "ConnectSituation" -->
<xmlMatch>
<xmlStringAtom
xmlTarget="cbeSituationCategory"
negated="true">ConnectSituation</xmlStringAtom>
</xmlMatch>
<!-- CBE situation category equals "ConnectSituation"
or "ConfigureSituation" -->
<xmlMatch>
<xmlOr>
<xmlStringAtom
xmlTarget="cbeSituationCategory">ConnectSituation</xmlStringAtom>
<xmlStringAtom
xmlTarget="cbeSituationCategory">ConfigureSituation</xmlStringAtom>
</xmlOr>
</xmlMatch>
<!-- CBE situation category equals "ConnectSituation"
and CBE severity greater than or equal to 40 -->
<xmlMatch>
<xmlStringAtom
xmlTarget="cbeSituationCategory">ConnectSituation</xmlStringAtom>
<xmlNumericAtom xmlTarget="cbeSeverity"
comparisonOperator="greaterThanOrEqualTo">40</xmlNumericAtom>
</xmlMatch>
<!-- CBE situation category equals "ConnectSituation"
or "ConfigureSituation" and CBE severity greater
than or equal to 40 -->
<xmlMatch>
<xmlOr>
<xmlStringAtom
xmlTarget="cbeSituationCategory">ConnectSituation</xmlStringAtom>
<xmlStringAtom
xmlTarget="cbeSituationCategory">ConfigureSituation</xmlStringAtom>
</xmlOr>
<xmlNumericAtom xmlTarget="cbeSeverity"
comparisonOperator="greaterThanOrEqualTo">40</xmlNumericAtom>
</xmlMatch>
|
|
<xmlGroups>要素
<xmlGroups>要素は、自動問題判別ツールに対して、選択されたログ・レコードのどのフィールドを分析レポートの中に含むべきかを指定します。従ってこれは、SQLのSELECT文と似ています（<xmlMatch>要素がSQLのWHERE文と似ているのと同様です）。対象とする各フィールドは、<xmlGroups>要素内に含まれる子要素、<xmlGroups>によって指定されます。
再度リスト1を見ると、<xmlGroups>要素には2つの属性があることが分かります。xmlTarget属性の動作は、<xmlMatch>要素内での動作と似ていますが、この場合は一致条件の評価に使用するためのログ・レコードを特定するのではなく、分析レポートの中に含めるべきログ・レコードを特定する点が異なっています。displayName属性は、自動問題判別ツールが使用するラベルを含んでいます。このラベルは、分析レポートの中の、ターゲット・データが含まれるカラムの先頭に置かれます。
ここで、xmlTargetの2つの列挙値、「entireCBE」と「entireUpdateEvent」に関して強調しておきたい点が、もう1つあります。これらの値は、<xmlMatch>要素の中のストリング・atomに現れるxmlTarget属性ではなく、<xmlGroups>要素の中に現れるxmlTarget属性に使われるように設計されているのです（この2つの値の1つをニューメリック・atomの中で使うことは、考えるだけ無駄です）。これは、検索対象のストリングがログ・レコード全体（そのXML要素名や、属性名、要素や属性の値を含む）に対するXMLソースである場合には、正規表現一致がどのような評価動作をするか予測しにくいためです。一方、狭いターゲット（「cbeSeverity」など）を使用して興味深いコモン・ベース・イベントを選択し、その後で（<xmlGroup>要素の中でターゲット「entireCBE」を規定することによって）選択されたコモン・ベース・イベントそれぞれを完全に分析レポートの中に含めるようにすることは、極めて妥当です。リスト9は、そうした規定の仕方を示しています。
リスト9. 分析レポートの中にコモン・ベース・イベント全体を含める
<xmlDelimiter id="cd1" documentXsd="CBE 1.0.1">
<xmlLogRecord elementType="CommonBaseEvent" level="top"/>
<xmlMatch>
<xmlNumericAtom xmlTarget="cbeSeverity"
comparisonOperator="greaterThan">30</xmlNumericAtom>
</xmlMatch>
<xmlGroups>
<xmlGroup xmlTarget="cbeTimestamp" displayName="timestamp"/>
<xmlGroup xmlTarget="cbeSituationCategory"
displayName="situation category"/>
<xmlGroup xmlTarget="entireCBE" displayName="CBE"/>
<formatref outputName="html-1" formatName="format-c1"/>
</xmlGroups>
</xmlDelimiter>
|
選択されたデータの、分析レポートの中での最終的なフォーマット形式は、通常の<delimiter>要素の場合と同様です。<xmlDelimiter>要素の中の<xmlGroups>要素には<formatRef>という子要素があり、この子要素は、<delimiter>要素の中にある<pattern>要素の子要素、<formatRef>と同じです。これは、同じシンプトン・データベース文書の中にある<format>要素を参照します（<format>要素は、ログ・レコードから抽出した情報の具体的なレイアウト規定します）。<formatRef>要素と<format>要素の詳細については、前回の記事、「シンプトン分析の概要」を見てください。
まとめ
自動問題判別ツールが最初にリリースされた時には、そのシンプトン分析は、非XMLのログ・ファイルしかサポートしていませんでした。しかしコモン・ベース・イベントの重要性が増すにつれ、またXMLフォーマットのログ・ファイル（event.history文書など）が存在することから、ツールのシンプトン分析を拡張し、XMLフォーマットのログ・ファイルもサポートする必要があることが明らかになりました。この記事では、この、第2のクラスのログ・ファイルに対するシンプトン分析をコントロールするために、シンプトン・データベース文書を使う方法について詳細に説明しました。
ダウンロード
参考文献
著者について | | | Bob Mooreは、ノースキャロライナ州Research Triangle ParkにあるIBMのSoftware Group Advanced Design and TechnologyチームのAdvisory Software Engineerです。1977年にDuke Universityにて哲学の博士号を取得しています。1983年にIBMに入社して以来、SNA/Management ServicesやCMIP、SNMP、DMTF CIMなど、ネットワークやシステム管理に関する様々なアーキテクチャーや標準に携わってきました。連絡先はremoore@us.ibm.comです。 |
| | | Brad Topolは、ノースキャロライナ州Research Triangle ParkにあるIBMのSoftware Group Advanced Design and TechnologyチームのSenior Software Engineerです。1998年に、Georgia Institute of Technologyにてコンピューター・サイエンスの博士を取得しています。現在は、自動問題判別サービスツール（Problem Determination Serviceability Tool）の開発リーダーです。これまで、オートノミック・コンピューティングやWebサービス、グリッド・コンピューティング、Webコンテンツ変換、アスペクト指向プログラミングなどの領域で、先端技術プロジェクトに携わってきました。連絡先はbtopol@us.ibm.comです。 |
| 
| | Jie Xingは、ノースキャロライナ州Research Triangle ParkにあるIBMのAdvisory Software Engineerとして、1年半勤務しています。現在は、Webサービスやグリッド・コンピューティング、オートノミック・コンピューティングなどの領域で先端技術に携わっています。2000年に、North Carolina State Universityにてコンピューター・サイエンスにおけるオペレーションズ・リサーチで博士を取得しています。そこでの研究領域は、マルチエージェント・システムや分散システム、ワークフローなどでした。連絡先はjiexing-at-us.ibm.comです。
|
| 
| | Thomas McElroyは、ノースキャロライナ州Research Triangle ParkにあるIBM Software Group System House組織のAdvisory Software Engineerです。これまで3年間、Webアプリケーション技術のプロジェクトに携わってきました。その中には、オンデマンド・クライアントやedge-side includes、統合ソリューション・コンソール、JDBC（Java Database Connectivity）キャッシング・プロキシーへの新手法などが含まれています。連絡先はtmcelroy@us.ibm.comです |
| 
| | Belinda Changは、ノースキャロライナ州Research Triangle ParkにあるIBM Software Group Advanced Design and TechnologyチームのSoftware Engineerです。カーネギー・メロン大学にてコンピューター・サイエンスの学位を取得しています。連絡先はbelchang@us.ibm.comです。 |
記事の評価
| 
