![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
プロセスというのは、ビジネス価値を持ち、明確に定義された入出力を持つビジネス・アクティビティーを、ある順序で並べたものです。例えば技術文書の検索プロセスであれば、Webページから顧客の検索リクエストを受け取り、選択可能な文書を集めたリストを生成します。
プロセスのモデル化には、大きな困難を伴います。モデリングでは、モデルが捉えたビジネス要求をアナリストと開発者の両者が理解できるように、一貫性を持っていること、また関連情報を完璧に網羅していることが必要です。モデリングを行う際には、通常のオペレーションだけではなく、標準的な手順に対する代替手段や例外も捉えておく必要があります。関心対象や担当領域の異なる様々な専門家によって、広範なビジネス目的を満足するプロセス・モデルが作られます。例えばアナリストは、戦略的な決定を駆動するプロセスを高いレベルから見る視点を要求し、例えばシミュレーションのようなプロセス分析を行います。一方開発者はプロセス・モデルを、ソリューションを実装するための入力として使います。
アナリストは、ビジネス要求の所有者との議論から収集した要求に基づいて、BP（ビジネス・プロセス）モデルを構築します。こうした要求は、パワーポイントや表計算ソフト、IBM® Rational® Requisite Pro などの適切なツールを使って、また、時にはプロセス・モデリング・ツール自体を使って収集されます。アナリストは、こうした要求と既存プロセスの分析結果を使って、モデルを構築する上での入力として使います。既存のプロセス・モデルは、既存プロセスの分析に使う場合もあれば、（全く新規のプロセス・モデルを作る代わりに）新しいプロセス・モデルを作るための原型として、修正した上で使う場合もあります。
モデリングは、BPをサブプロセスに分割するところから始まります。次に、それぞれのサブプロセスに対して、コンポーネントやサービス、データ入出力、ポリシー、測定などを特定するための分析が行われます。こうした要素は、WebSphere® Business Integration Modelerソフトウェア・ツール（Business Integration Modeler）を使って、BPモデルにとエンコードされます。
モデリングの成果物はプロセス要素(process element) と呼ばれ、再使用できるように作られたBPセグメントを定義するために使われます。プロセス要素は、BPモデル内で再使用できるように作られ、管理されるプロセス・セグメントを定義する成果物資産です。プロセス要素は、確立された一連のタスクや決定、データ・オブジェクトへの参照、ポリシー、役割、測定などを組み込んでいます。例えば、ログイン・プロセス(login process) 要素であれば、一連のアクティビティーやログインの際の信任データ、ユーザーのログイン・プロセスを完了するためのログイン・ルールなどが含まれます。
こうしたプロセス要素は、受け入れられているオペレーション上の習慣として、似た状況で再利用できるものを表します。例えば、買い物かごの内容を検証し、値段付けをする、サブプロセス(sub-process) モデルなどがあります。
サービス要素(service element) は、モデルに統合されるBusiness Integration Modelerにインポートされる、事前定義されたサービスです。こうしたサービス要素は、入力や出力、公開されたWebサービスのオペレーションなどを規定します。例えばサービス要素は、遠隔の部品サプライヤーを公開するWebサービスを規定します。
ビジネス・アナリストにとってBusiness Integration Modelerは、モデル化や分析、シミュレーション、ビジネス・プロセスの改善などを行うためのツールであり、これを使うことによって、ビジネス・プロセスをRational XDE 用のUMLモデル、つまり、WebSphere Business Integration Server Foundation (Business Integration Server Foundation) のBPEL4WS（Business Process Execution Language for Web Services）に変換したりエクスポートしたりする前に、評価を行うことができます。ここではBusiness Integration Modeler V5.1を使ってBPモデルを作り、それをWebShere Studio Application Developer Integration Edition V5.1.1 (Application Developer) にエクスポートします（図1）。
図1. アナリストから開発者へのモデル変換
Business Integration Modeler V5.1には、プロセス・モデリングのための豊富な機能が用意されています。この中には例えば、グラフィカル・エディターやテキスト・エディターの幾つか、BOM（business operations models）、BOMをターゲット・プラットフォーム上で対応する成果物に変換する機構などがあります。
図2. Business Integration Modelerのエディターやモデル、変換機構
図2 から分かるように、アナリストは、適当なエディターの中に様々なプロセス要素を作ります（例えば、アクティビティーと、アクティビティー間の結合から成るBPフローをグラフィカルに表現するものとして、使用プロセス・エディター(use process editor)があります）。こうしたプロセス要素は、BOMとしてディスク・ファイルの中に保存されます。Business Integration ModelerはそのBOMに対して、対応する検証を自動的に適用します。アナリストは、後でモデルをエクスポートする際に正しい変換を適用し、BOMを、対応する成果物に変換します。図2 はまた、次の4つの成果物エクスポートがサポートされていることも示しています。
- Business Integration Modeler成果物（BPEL (Business Process Execution Language) ＋XSD (XML Schema Definition) ＋WSDL (Web Services Description Language) ）
- MQ Workflow用のFDL（FlowMark Definition Language）
- UML
- 区切り付きテキスト
ビジネス・プロセス・モデリングは、次のものから構成されます。
- BP要求を収集する
- ビジネス・アイテムをモデル化する
- 役割やリソースをモデル化する
- サービスをモデル化する
- ポリシーをモデル化する
- KPI（Key Performance Indicators）をモデル化する
これらのステップの詳細を、これから先のセクションで見て行きましょう。
BPアナリストは、BP所有者とその領域の専門家と協力し、BPモデルを構築するために必要な全情報を収集します。例えばアナリストは適当なツールを使って、役割やタスク、シーケンス情報、リソース、データ、注釈（narratives）、要求などを収集し、BPモデルを構築するための入力として使います。Business Integration Modelerの中でプロセスのモデルを作ることによって、ビジネス・アナリストが捉える情報は、ワークフロー開発者がApplication Developerツールの中で使える形で、容易にエクスポートすることができます。
ビジネス・アイテムは、ビジネス文書であったり、作業製品であったり、ビジネスが稼働する中で使われる日常的なものであったりします。ビジネス・アイテムの例としては、注文書や顧客の住所、部品表などがあります。アナリストは、XMLスキーマ・フォーマットで定義されたデータ・モデルをインポートする場合もあれば、Business Integration Modelerを使って、新しいデータ・モデルを作る場合もあります。
データ・モデリングの要素として、次のようなものを作ります。
- データ・カタログ
- ビジネス・アイテム
- ビジネス・アイテム・テンプレート
- ビジネス・アイテム・インスタンス
データ・カタログは、ビジネス・アイテムやビジネス・テンプレート、ビジネス・アイテム・インスタンスなどを整理するためのフォルダーです。データ・カタログを作るのはオプションです。積極的に作らない場合は、Business Integration ModelerデフォルトのBusiness items データ・カタログの中に、データ・モデルが作られます。
ビジネス・アイテムが作られると、既存のデータ・カタログに追加されます。次にビジネス・アイテムの属性やプロパティーが、ビジネス・アイテムに追加されます。例えば、属性がorderItems やvalid であるようなorders ビジネス・アイテムを作ることができます。こうした属性は、単純型（ストリング型、整数型、ブール型、など）の場合もあれば、同一、あるいは別のデータ・カタログからのビジネス・アイテムの場合もあります。例えばorders ビジネス・アイテムは、同一、あるいは別のデータ・カタログからの、OrderItem型のorderItems 属性を含むことができます。
ビジネス・アイテム・テンプレートを使うと、一般的な属性を持つビジネス・アイテムを作ることができます。新しいビジネス・アイテムは、テンプレートの中に無かった、新しい属性を追加することができます。例えば、適当な属性を持ったorderItem テンプレートを作り、後でそのテンプレートを使って、（orderitem属性全体をタイプ化することなく）purchase order （注文書）アイテムを作ったり、manufacturing bill of materials （生産部品表）アイテムを作ったりすることができます。また、新しい属性を追加することで、適当な拡張を追加することもできます。例えば、orderItem テンプレートから派生させることでpurchase order アイテムを作った後、さらにpurchase date やlocation 、store などの属性を追加することができます。ビジネス・アイテム・インスタンスは、あるビジネス・アイテムの、ある特定な事例、例えば製造番号「1xDBCS」に対する注文、などを表します。
ビジネス・アイテムや、その個々の属性に対して、ルールを関連付けることができます。しかし、この機能は現在BPELエクスポートではサポートされていないため、開発者に分かるように、モデルの中に文書化しておく必要があります。プロセスのモデル化における最初のステップとしては、まず必要なデータ・カタログとビジネス・アイテムを作ることをお勧めします。そうすれば、これらをタスクと関連付けられるようになります。
ビジネス・アイテム属性の最小値と最大値を設定することによって、そのアイテムの順序付きシーケンス（配列）を作ります。できるだけ、WBIモデラーにあるXSDインポート・オプションを使って、既存のXMLスキーマ要素からビジネス・アイテムをインポートするようにします。データ・カタログは、JavaパッケージとXSDスキーマのターゲット名前空間にマップされるため、開発で問題が起きないように、データ・カタログの名前を適切に扱うようにお勧めします。
リソースは、人や装置、タスクを遂行するための材料などを表します。役割は、リソースに対して特性を追加します。例えば、従業員リソースは、Managerの役割を持つかも知れません。役割は主に、スタッフ・アクティビティーを持つプロセスの中で使われるタスクに割り当てられます。例えば管理スタッフは、タスクの中にある例外（例えば無効な注文やシステムのフェールなど）を処理することができます。プロセス分析は、リソース割り当てを調整することによって行われます。この分析によって、リソースの利用率レベルの詳細が分かり、コストやサイクル時間を計算することができます。これが、プロセスの最適化や改善につながります。また、ワークフローに関しては、役割を使ってスタッフ・アクティビティーに人を割り当てます。
Business Integration Modelerでは、サービスは、組織のプロセス内部から利用できる外部実体（モデル化の対象となるプロセスの外）として定義されます。
Business Integration Modelerでは、一連の入力を、入力基準としてグループ化することができます。各入力基準は、プロセスやサービス、タスクを開始できるような入力の、特別な組み合わせを定義します。一つ以上の入力がある場合のデフォルト条件は、and です。or 条件に対しては、追加の入力基準を作ります。BPELにエクスポートしようとしているので、一つの要素に対しては、一つの入力だけに制限されます。同様に、一連の出力をグループ化するために、出力基準を使います。WebサービスのWSDLインターフェース・モデル（portType定義）では、こうした入出力基準はそれぞれ、オペレーションの入出力メッセージにマップされます。
それぞれのサービスに対して、幾つもの入出力基準を作ることはできるのですが、これはBPELモデルでは許されていません。BPELベースの実行可能ワークフローでは、一つの入力基準と一つの出力基準に制限しておくことが推奨されます。WSDLのportTypeオペレーションでは、単一の入力メッセージと単一の出力メッセージを受け付けます。リスト1 は、portTypeオペレーションでの入出力基準が、どのように入出力メッセージにマップされるかを示しています。
リスト1. 入力基準と出力基準
<portType name="ValidateGenerateTopologyPT">
<operation name="sendValidateGenerateTopology_InputCriteria">
<input message="tns:InputCriteriaMessage"
name="InputCriteriaMessage"/>
<output message="tns:OutputCriteriaMessage"
name="OutputCriteriaMessage"/> </operation> </portType>
|
今のところ、既存のサービスWSDLを再利用してサービス要素を作ることはできません。既存のWSDLを再利用するためには、生成されたコードを変更する必要があります。その後で、BPEL partnerLinksを利用して、正しい外部サービスを関連付けるのです。
意図したポリシーをアナリストが規定する場合もあるかも知れませんが、ポリシーは、明示的、実行可能なルールによって、強制する必要があります。ポリシーは通常、宣言的です（例えば、「アメリカの顧客のみがマシンXを発注できる」など）。ポリシーはそれぞれ、その実装の中で、一つ、またはそれ以上の強制ポイント（enforcement points）を必要とする場合があります。強制ポイントは、プロセス中の明示的なステップとして、あるいは特定なコード位置として実装します。強制ポイントはまた、イベントを処理する場合にも発生します。ポリシーの強制ポイントを実装する上で、ルールは有効な方法です。ルールは、命令（imperative）であり、また論理的に実行可能です。リスト2 は、単純なルールの例を示します。
リスト2. 単純なルール
"If !(location(customer) == "USA") then reject(order);" |
時には、ポリシーが明示的に示されておらず、実装によって単に暗黙的に定義されている場合もあります。言い換えると、実際に実装されている一連の強制ポイントとルールが、ポリシーを定義しているのです。
アナリストは、各タスクのコメント・フィールドの中でポリシーを文書化します。開発者は、ポリシーをルールに変換する責任を持ちます。アナリストは、強制ポイントを持った既存サービスを表すサービス要素を、モデルに追加します。アナリストはまた、ポリシーを強制するコードに対するプレースホルダーを表すタスクも追加します。開発者は、そのタスクを実装するために必要なコードを追加します。つまり、正しいルールを実行します（詳細については、参考文献に挙げた「On demand business process life cycle」シリーズの第4回を見てください）。
プロセスのモデル化の役割は、ビジネス・プロセス・フローの詳細を定義することと、そのフローが使用するデータやリソース、その他の要素をモデル化することから成っています。ビジネス・プロセスは通常、制御フローで結合されるプロセス・ステップから構成され、またこれらの制御フローは、アクティビティーを判断ノードと結合します。判断ノードは、ビジネス・ルール（遷移条件）を保持します。（プロセスの中の、どのパスに従うべきかは、ビジネス・ルールを評価することによって判断されます。）モデリングには、BPをサブプロセスに分割することや、必要なプロセス要素をモデルに追加することなどが含まれます。アナリストは、既存のモデリング成果物（例えばサービス要素やプロセス要素）を、モデル構築に、あるいはモデル構築のスピードアップに利用します。資料「Business process modeling using WebSphere Business Integration Modeler」（「On demand business process life cycle」シリーズの一部）は、モデリング成果物からプロセス・モデルを構築する方法を解説しています（参考文献）。
Key Performance Indicatorsをモデル化する
KPI（Key Performance Indicators）は、ビジネスにおける主要成功要因（critical success factors）を追跡するために作られた指標です。BPモニタリング機能を使うと、プロセス所有者や管理者は、リアルタイムでKPIをモニターすることができます。こうした機能はまた、アナリストが既存プロセスでの問題やボトルネックを特定するためにも役立ち、これが結果的に、このシリーズ第1回（参考文献）で説明した開発ループを閉じることにつながります。Business Integration Modelerには、こうしたプロセスを追跡する上での致命要因を文書化するために必要な、プロセスにKPIを追加するためのツールが用意されています（詳細については、資料「Business process modeling using WebSphere Business Integration Modeler」を見てください）。
- Business Integration Modelerには、FDLとBPELそしてOperationalという、3つのモードがあります。プロセスがBusiness Integration Server Foundationで実行されるのであれば、BPELモードでモデリングを開始すべきでしょう。そうすれば、モデルをエクスポートする前に、Error Viewの中で検証エラーを見たり修正したりすることができます。
- ランタイム要求（タスク実行やリポジトリー使用を制御するための入力基準など）を追加するためには、Advanced Business Modelingユーザー・プロファイルを使うべきです。
- Business Item Modeling Refinements -- ビジネス・アイテムは、全ての詳細が無くても定義できます。後から、新しい属性などの詳細を使って改善することができるのです。また、XSDファイルからインポートすることもできます。
- Fault Handlingは、モデルの一部にすべきではなく、ワークフロー開発者（例えば、サービス・タイムアウトの処理）に任せるべきです。
モデラーをBPELモードにすると、BPEL検証チェッカーがオンになります。エラーや警告があると、Error Viewに現れます。このリストをフィルターして、エラーまたは警告を表示することができます。また、プロジェクト全体というレベルから、選択した要素のみ、というレベルまで、モデルのレベルを選択することができます。エラーを持つモデルをエクスポートすることもできますが、後でエクスポートし直さなくて済むように、最終的には修正しておく必要があります。
このモデラーは、Application Developerツールで必要なBPELファイルやXSDファイル、WSDLファイルなどを、既存のサービス・プロジェクトに、または、後でサービス・プロジェクトにインポートするためのフォルダーに、エクスポートします。
図3. 生成されたファイルと、プロセス・モデル要素との関係
図3 は、生成されたファイルを示しています。またこの図から、プロセス・モデル要素と、それに対応する（生成されたファイル中の）成果物の関係も分かります。例えば、複合ビジネス・アイテムはXSD Complexタイプとして生成されます。ビジネス・モデリング・プロジェクト全体をエクスポートすることもでき、プロジェクトの中の選択部分のみをエクスポートすることもできます。エクスポートする際の重要オプションとして、プロセス実行モード(process execution mode) の選択があります。オプションとしては、それぞれ異なる3つがあり、デフォルトはLong-running (request-reply)です。
プロセス・モデルをBPELベースの実行可能ワークフロー成果物にエクスポートする際には、3つの実行モードが利用できます。
- Long-running (receive/reply) -- このオプションは、実行可能BPELワークフロー・モードを長期実行プロセスに設定し、プロセスのオペレーションを、入出力両方のメッセージを持った、双方向 オペレーションとして規定します。長期実行プロセスは割り込み可能です。そのため、プロセス実行に対して割り込みを要求する、スタッフ・アクティビティーやその他のアクティビティーの導入が可能になります。
- Long-running (receive with callback) -- このオプションは、実行可能BPELワークフロー・モードを長期実行プロセスに設定し、プロセスのオペレーションを、入力メッセージのみを受け付け出力メッセージが無い、片方向 オペレーションとして規定します。しかし、コールバック・オペレーションが作られるため、プロセスは呼び出し側に結果を返すことができます。BPEL相関セットが作られますが、相関プロパティーは何も追加されません。後から開発者が、必要なプロパティーを追加することが想定されています。
- Microflows -- このオプションは、双方向 メッセージを受け付けるワークフロー・プロセス・オペレーションを作ります。しかし、こうしたプロセスは割り込み不能であり、スタッフ・アクティビティーをプロセスに追加することはできません。プロセス・モデルが、スタッフや人に基づくリソースや役割を持ったタスクを含む場合には、スタッフ・アクティビティーを使用可能にしてモデルをエクスポートします。しかし、エクスポートされる実行可能モデルには検証の問題があるため、開発者がこれを修正する必要があります。
ビジネス・アナリストによるトップダウン・モデリングは、オンデマンド・ビジネス・プロセスのライフサイクル方法論において、鍵となる要素です。このビジネス・プロセス・モデルは、技術的なフレームワークを定義することによって、ビジネス仕様とIT開発を整合させます。共有モデルは、ビジネス・プロセスの存続時間に渡って保持されるため、ビジネスの視点とITの視点の同期が保たれます。この記事では、WebSphere Business Integration Modeler V5.1を利用して、アナリストがビジネス・プロセスを定義する上で使用する、プロセス・モデリングの概念の一部を紹介しました。また、モデリングのための指針も紹介し、Business Integration Modelerの持つ様々なエクスポート・オプションと、生成された成果物を開発ツールへの入力として使用する方法についても解説しました。
Business Integration Modeler V5.1: 中核的な機能
WebSphere Business Integration Modeler V5.1は使いやすいツールとして、ビジネス・プロセスの中の特定なステップを捉え、文書化するために、特にビジネス・ユーザーのために設計されたものです。中核的な機能としては、下記のようなものです。
ユーザー・プロファイル: Business Integration Modelerには、それぞれ異なる3つのユーザー・プロファイルが用意されています。これを利用することによって、詳細が異なる、同じプロセス・モデルを、別々のビューで見られるようになります。3つのプロファイルは、basicとintermediateそしてadvancedです。これらのプロファイルは、様々なユーザーの役割に関連付けられます。ビジネス領域のエクスパートやアナリストは、basicプロファイルを使います（basicプロファイルでは、ビジネス・タスクはアクティビティーのシーケンスとして説明され、他のモデル情報はドキュメンテーションとして捉えられます）。intermediateプロファイルは、より技術志向であり、データ・モデルや表現、カーディナリティー（cardinality）情報についての詳細を持ち、よりビジネス・アーキテクトに適したものです。advancedプロファイルは、プロセスやデータ・モデルの詳細を包括的に提供します。このプロファイルは、ソリューション・アーキテクトやITアーキテクトに好適です。プロファイルを変更しても、下にあるデータ・モデルは変更されないことには注意する必要があります。
技術モード: 技術モードには、オペレーショナル、BPEL、MQ Workflow FDL という3種類があります。技術的な熟練度や、どの程度詳細なビューが要求されるかにより、モードを切り換えることができます。あるモードでは、オプションや注記要素は使用不可にできます。また、適切なモデルを選択すれば、ターゲットとなるワークフロー実行環境に対する適切な成果物が定義できます。モードを変更しても、下にあるデータ・モデルは変更されないことには注意する必要があります。
カタログ: これらは、類似のモデリング実体を論理的にグループ分けしたものです。これらのカタログには、次のようなものが含まれます。
- データ（注文や製品などの、ビジネス・アイテム）
- プロセス（メイン・プロセス、サブプロセス、サービス、タスク）
- リソース（カスタマー・サービス担当者、セールス・マネージャー、あるいはWebサーバーやアプリケーション・サーバーなどのリソース）
- 組織（組織上の階層構造、位置）
- レポート（要約、比較、ドキュメンテーション）
こうしたグループ分けによって、モデリング実体が再利用しやすくなります。
プロセス: プロセスは、アクティビティーのシーケンスや、こうしたアクティビティーが実行される場合を規定する条件、アクティビティーの実行に必要なリソース、データフロー（アクティビティーと、サービス相互動作との間）などです。これらのプロセスは、ツールが提供するダイヤグラム式記述を使ってモデル化します。
シミュレーション: 組織はプロセス・モデル・シミュレーションを使うことによって、入力を変化させた場合にプロセスがどのように動作するかを調べることができます。シミュレーションには、入力を変化させるための機能やコスト要因を関連付ける機能、リソースと現在の割り当てを調整して実際のビジネス・シナリオをシミュレートする機能などが含まれています。こうしたシミュレーションを利用することによって、クリティカル・パスや最短パス、サイクル・タイム、プロセス・モデルに関するコストや時間単位などに対する分析を強化することができます。
レポート: レポート機能は、プロセスの分析や再設計に対して貴重な指針となります。様々なレポート機能がありますが、一例としては、プロセス・サマリー、2つのプロセス・モデルの比較レポート、ROI測定における「現状のまま」対「変更後」の比較、ドキュメンテーション、プロシージャー（ルールやポリシー、プロシージャー）のレポートなどがあります。
分析: プロセス・モデルに関する分析として、静的分析と動的分析という2種類があります。静的分析の場合は、大部分の情報はモデルから抽出され、コストや時間管理、パフォーマンス、プロセス・フロー検証、リソース平準化などに使われます。動的分析は、シミュレーション・プロセスからの出力に対して、出力ログやイベントに基づいて行われます。動的分析には、集約分析（プロセス・モデル要素を複数回実行した結果に基づく）と、ケース分析（プロセス要素の特定なシーケンスを実行するインスタンスを一つだけ使う）という2種類があります。
-
On demand business process life cycle シリーズの過去の全記事を読んで、これから追加する新しい記事に追いついてください。
- developerWorksから、Business Process Execution Language for Web Services, Version 1.1 仕様を入手してください。
- ホワイトペーパー、BPELJ: BPEL for Java technology を読んでください。この2つの言語を組み合わせて、ビジネス・プロセス・アプリケーションを構築する方法を解説しています（developerWorks, 2004年3月）。
-
WebSphere Business Integration Modeler V5.1 について、このFAQから学んでください。
-
WebSphere Business Integration Library をよく見てください。
- DB2® から Lotus® 、Rational® 、Tivoli®、そして WebSphere® に至る、アプリケーション開発ツールやミドルウェア製品を試してみてください。これらの製品の評価版が無料でダウンロードできます 。もしくは、developerWorksが無料で提供するSoftware Evaluation Kit の Linux® または、Windows® 版を選択してください。
-
Developer Bookstore には、Webサービス関連の書籍 をはじめ、広範な話題を網羅した技術書が豊富に取り揃えられていますので、ぜひご利用ください。
- IBM developerWorksチームは、世界中で何百回ものtechnical briefings を開催しています。どれも無料で参加することができます。
- developerWorksのSOA and web services ゾーンでは、豊富な記事と、初心者から中級者、そして上級者まで幅広い方々に役立つ、Webサービス・アプリケーションの構築方法に関するチュートリアルを提供しています。
Ken Beckは、IBMのGlobal Services Application Management Services Business Transformation Center of Excellenceに勤務するManaging Consultantです。現在はIBMのBT/CIO Enterprise Component Business Architectureグループに所属し、プロセス・モデルの再利用方法を開発するプロセス設計者の中心となっています。IBMには1993年以来、Business Process Consultantとして勤務しています。
Joshy Josephは、IBMのOn Demand Architecture and Development組織の中のIBM Software Groupに勤務するSoftware Engineerです。アーキテクト、プログラマーであり、主なスキル、専門領域としては、分散コンピューティングやグリッド・コンピューティング、Webサービス、ビジネス・プロセス、ワークフロー開発などです。2003年にPrentice HallからGrid Computing を出版しています。また、グリッド・コンピューティングやビジネス・プロセス開発、Webサービスなどに関して、数多くの技術記事を執筆しています。
目次
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ