はじめに

どのような領域であってもセマンティクスは重要なものですが、特に SOA (Service-oriented architecture) の場合は重要です。SOA はさまざまなチームや組織にまたがるため、関連する用語について合意することが重要です。このシリーズは、用語や、そうした用語の背景にある概念を定義しながら SOA を紹介していきます。またこのシリーズでは、SOA の領域でのコミュニケーションに必要なボキャブラリーを学びます。そしてそれぞれの用語に関して、なぜその用語が SOA にとって重要なのか、その用語はそのコンテキストで何を意味するのか、関連する標準は何か、その用語は他の用語とどのように異なるのか、などについて理解していきます。

このシリーズの第 1 回はビジネスに焦点を絞り、『サービス』や『SOA』といった用語を定義することで、シリーズの準備をしました。今回の記事では、SOA の採用を成功させるために必要なソフトウェア・エンジニアリングの方法やプロセス、また SOA ソリューションを実現するために必要な成果物 (モデルや資産など) について解説します。

上に戻る

開発のプロセスと方法

ソフトウェア開発を成功させるためには下記が必要です。

理解し、従うべき原則

• 正式に記述された、実証済みのベスト・プラクティスに基づく方法や手法
• 正式に記述された方法と実証済みのベスト・プラクティスに基づく手法
• 調整が可能なプロセス

方法内容 (method content)

『方法内容』は、何を作成する必要があるのか、どのように作業を行うのか、誰が作業を行うのか、を表します。

方法内容の成果物には下記が含まれます。

• 役割: 定義されたスキルと作業成果責任。『ソフトウェア・アーキテクト』は役割の一例です。
• 作業成果: タスクの結果 (配布可能か否かにかかわらず)。『サービス・モデル』は作業成果の一例です。
• タスク: 特定の役割が実行するステップのシーケンス。タスクは、入力作業成果を使って出力作業成果を作成、あるいは修正します。『サービスを特定すること』はタスクの一例です。
• ガイダンス: ドキュメンテーション。『用語集』、『テンプレート』、『例』、『ツール・メンター』などはガイダンスの一例です。

プロセス

『プロセス』は、方法内容を開発サイクルとして整理し、また行うべき作業のシーケンスを指定するために使われます。行うべき作業のシーケンスは、開発サイクル・モデル (例えばウォーターフォール型や反復型など) とは独立しています。プロセスはワークフロー、あるいは分解された構造と考えることができます。プロセスによって、プロジェクト・マネージャーは、誰が必要なのか、またプロジェクトの各フェーズにおいてどの作業成果が変更されるのかを理解することができます。RUP (Rational Unified Process®) に慣れている方は、RUP での作業分野 (例えば、分析や設計の実装など) を方法内容として、また RUP でのフェーズ (例えば、推敲や作成など) をプロセス要素と考えることができます。

方法とプロセスという、この 2 つの概念を分離し、それぞれを独立に修正できるフレームワークを持つことが重要です。

Rational Method Composer

IBM のRational® Method Composer (RMC) は、Eclipse をベースにした、方法とプロセスのオーサリング・プラットフォームであり、プロセスの統合、調整、体系化、公開のために使用されます。RMC には、そのまま使用、あるいはカスタマイズできるプロセス (たとえば RUP (Rational Unified Process) など) のカタログが初めから準備されています。通常、RMC を使用するのは、プロセスの維持管理に責任を持つプロジェクト・マネージャーや、プロジェクト・マネージャー、プログラム・マネージャーなどです (RMC はこのセクションで説明する概念をサポートしています)。

RMC の中で行われる作業の出力は、HTML として (通常は Web サイトの形で) 公開されるプロセスです。そしてこのプロセスに従おうとする組織は、そのプロセスのサイトを使用します。

Software Process Engineering Metamodel

このセクションでは、開発プロセスについて説明します。SPEM (Software Process Engineering Metamodel) は、ソフトウェア開発プロセスを正式に記述するための標準仕様です。SPEM は OMG (Object Management Group) の標準であり、特定のベンダーや方法、フレームワークなどに依存しません。Version 1.1 は 2005 年の 1 月に正式公開され、主要な更新である Version 2.0 が現在開発中です。

Rational Unified Process

RUP (Rational Unified Process) は、全世界の何千ものプロジェクトで採用されているベスト・プラクティスに基づくソフトウェア開発プロセスであり、特定のプロジェクトに合わせて容易に調整することができます。RUP には、優先度のバランス (priority balancing) や反復開発、ビジュアル・モデリング、ソフトウェア品質、チーム協力などの重要な原則が含まれています。RUP は、手順 (方法内容) とフェーズ (プロセス) を定義します (図 1)。

Rational Unified Process for Service-Oriented Modeling and Architecture

RUP Plug-In for SOMA (Rational Unified Process for Service-Oriented Modeling and Architecture) は RUP 上に構築されており、サービス指向ソリューションを開発するための手引きとなります。Version 2.4 (「参考文献」を参照) は、SOA コンテンツのための (これまでの) RUP と IBM GBS (Global Business Services) の SOMA による方法とを組み合わせ、統一した方法を提供します。RUP Plug-In for SOMA には、サービス指向ソリューションの分析やアーキテクチャー、設計に関する、ソフトウェアのアーキテクトや設計者のための具体的な手引きが含まれています。

また、ドメイン固有のソリューション (SOA など) のモデリングに特化された UML (Unified Modeling Language) プロファイルがあり、それらを特化されたプロセスと組み合わせて使うことができます。例えば、RUP Plug-In for SOMA をサポートする UML 2.0 profile for Software Services (ソフトウェア・サービスのためのUMLプロファイル 2.0) があります。

注意: 管理に関係するプロセスは、このシリーズの今後の記事で取り上げます。

IBM の手法

このシリーズの第 1 回で説明したように、組織は CBM (Component Business Modeling) を利用することによって、戦略や、技術、運用、投資を、まったく新しい視点から理解した上で連携させることができます。CBM によって、それぞれ異なるビジネス・コンポーネントの識別や、鍵となるビジネス・プロセスの分析が可能になります。

『SOMA (Service-Oriented Modeling and Architecture)』は、SOA ソリューションを分析、設計する上での手引きとなります。SOMA によって、(設計レベルで) ビジネスの目的に合わせたサービスを特定し、詳述し、実現することができます。この話題に関しては、後のセクションで詳細に説明します。

上に戻る

モデル、UML、資産、そしてパターン

メタデータ

メタデータは文字通り、『データに関するデータ』を意味します。例えば、録音された曲のメタデータには、その曲のアーチストやアルバム、作曲者、曲の長さ、品質などの情報が含まれているかもしれません。一方、データは録音された音楽そのものです。

コンテキストによって、同じデータであっても、実際のデータであることもあれば、メタデータであることもあります。この前のセクションで説明した、開発の方法やプロセスの例を考えてみてください。開発方法を RMC で体系化する場合には、(メタデータで補足され) タイプ分けされた内容を定義します。例えば、作業成果やタスク、役割の新しいインスタンスを定義する場合があります。このレベルでは、作業成果やタスク、役割はメタデータ要素であり、またこれらのメタデータは、これらのタイプ (役割が実行するタスク) の間の関係も定義します。今度は設計者が方法に関する概念を定義する場合を考えます。設計者が UML を使って作業成果や役割、タスクの概念をモデリングするところを想像してください。このレベルでは、作業成果やタスク、役割は実際のデータであり、UML はメタデータです。このデータはその後、RMC でメタデータとして使われます。つまりこの例では、UML をメタ・メタデータと考えることができます。

モデル

RUP はモデルを、『ある特定の観点からシステムを完全に表現した、システムの抽象表現あるいはシステムのシミュレーション』と表現しています。モデルは多くの場合、システムの動作をよりよく理解するために、あるいは実際の実装のための設計判断を文書化するために使われます。モデルは多くの場合、いくつかの異なる種類のパーツから構成されます。これらのパーツはモデル要素として分類されます。

モデルは、モデルを理解する人達を対象としています。例えば、システム・アナリストやシステム設計者は分析モデルを作成、使用し、データベース設計者はデータ・モデルを設計、表示します。モデルはテキスト・ベースの場合もあればグラフィックス・ベースの場合もあり、両方を使う場合もあります。モデリングは厳密かつ完璧でなければならない一方、複雑さを避ける必要がある (例えば上位レベルの抽象化で表現するなど) ため、UML (Unified Modeling Language) などの (RUP でビジュアル・モデリングと表現されている) 表現力豊かでグラフィカルな設計表記を使うことが良い習慣です。モデルは特定の抽象化レベルのものであり、下位レベルの抽象化に進化させることができます。例えば、分析モデルは通常、設計モデルに進化します。

このシリーズの第 1 回では、SOA ではコラボレーションが一層重要なことを説明しました。例えば、皆さんの会社は詳細な設計や実装を他の会社にアウトソースしたことがあるかもしれません。モデリングを行う場合には、モデルは他の人達が使うものであることを忘れないことが重要です。また、SOA の設計と開発のプラットフォームは、あるモデルを別のモデルに進化させる機能を持っている必要があります。

自動化と変換

SOA の設計と開発のプラットフォームは、モデルを上位レベルの抽象化から下位レベルの抽象化へ、そして最終的にはコードへ、半自動的に変換できる必要があります。例えば、UML のクラス図から Java コードを生成する、UML から Java™ への変換が考えられます。

また基礎となるフレームワークは、『追跡可能性 (トレーサビリティー)』も持っている必要があります。追跡可能性は基本的に、上位の抽象化レベルに戻る機能です。例えば、ある要件の変更が設計に与える影響を理解したい、としましょう。そうした場合には、その要件が設計の中でどのように表現されていたかを、その特定の要件をサポートする設計判断を行った際に追加したリンク (トレース) によって判断できる必要があります。そうすれば、影響の分析を行う際には、その特定の要件に関連する (トレースされた、つまりリンクされた) すべての設計判断を見られるはずであり、その要件の変更が設計に与える影響を理解できるようになるはずです。

『メタモデル』は、モデルに関するモデルです。メタモデルは特定のドメインのモデルであり、概念を定義し、そのドメインでのモデルを作成するための構築要素を提供します。例えば、SPEM はプロセス・エンジニアリングのメタモデルと考えることができます。

Eclipse Modeling Framework

EMF (Eclipse Modeling Framework) は、オープンソースの Eclipse プロジェクトであり、モデル・メタモデル (モデリング・ドメインのメタモデル) を含んでいます。下記は EMF の Web サイトから引用した定義です。

「EMF は、構造化されたデータ・モデルに基づいてツールや他のアプリケーションを構築するためのモデリング・フレームワークであり、コード生成機能です。EMF は、モデルに対する一連の Java クラスや、モデルをビューし、コマンド・ベースの編集を行える一連のアダプター・クラス、そして基本的なエディターを作成するためのツールとランタイム・サポートを、XMI (XML Metadata Interchange) に記述されているモデル仕様に基づいて提供します。

コアとなる EMF フレームワークには、モデルを記述するためのメタモデル (Ecore) と、変更通知を含むモデルに対するランライム・サポート、デフォルトで XMI シリアライズ機能を持つパーシスタンス・サポート、そして EMF オブジェクトを汎用的に操作できる非常に効率的で反映型の API (Application Programming Interface) などが含まれています。」

上に戻る

UML (Unified Modeling Language)

OMG (Object Management Group) の表現を引用すると、「UML (Unified Modeling Language) はソフトウェア・システムの成果物を指定し、視覚化し、構築し、そして文書化するための業界標準の言語です。UML は複雑なソフトウェア設計を単純化し、「構築のための青写真」を作成します。」

UML の良い点は、業界で広くサポートされていることです。UML が最初に OMG に提出されたのは 1997 年ですが、現在は多くのベンダーが、その設計開発環境で UML を完全にサポートしています (例えば IBM の RSM (Rational Software Modeler) あるいは IBM の RSA (Rational Software Architect) など)。

UML は OMG の標準であり、現在の仕様の正式なバージョンは 2.1.1 です。この仕様は 13 のグループから成る概念と図のタイプを定義しており、それらを次の 2 つのカテゴリーに分類しています。

• 構造: クラス、オブジェクト、コンポーネント、複合構造、パッケージ、デプロイメント
• 振る舞い: ユースケース、アクティビティー、ステート・マシン、シーケンス、コミュニケーション、タイミング、相互作用概要図 (Interaction Overview)

UML は汎用のモデリング言語であり、その重要な強みの 1 つは UML プロファイルを使ってドメイン固有のモデリングに拡張できることです。

UML プロファイル

UML プロファイルは、ドメインから独立した UML に対する、単純な拡張機構を提供します。このプロファイルによって、ドメイン固有のエンティティーやルールを定義することができます。また、UML プロファイルは開発プロセスとうまく対応しています。例えば、UML Profile for Business Modeling (ビジネス・モデリング用のUMLプロファイル) は、Business Modeling Plug-In のための RUP (Rational Unified Process) をサポートしています。

プロファイルは、主にステレオタイプから構成されています。ステレオタイプは、そのステレオタイプにどの UML クラス (メタクラス) が関連付けられているか、そのクラスに対するプロパティー、そしてステレオタイプ化された要素と他の要素との関連付けに関する制約を定義します。例えば、UML 2.0 Profile for Software Services（ソフトウェア・サービスのための UML 2.0プロファイル）では、Service Specification というステレオタイプは、Interface UML メタクラスを拡張します。また、『published』という名前のプロパティーを定義し、そのサービス仕様がサービス・レジストリーに公開されているかどうかを示します。そして最後に、ステレオタイプの制約の 1 つとして、すべての Service Specification の操作は public とマーキングされている必要があります。

UML 2.0 Profile for Software Services (ソフトウェア・サービス用の UML 2.0 プロファイル)

UML 2.0 Profile for Software Services は、「サービスやサービス指向アーキテクチャー (SOA)、そしてサービス指向ソリューションのモデリングを行うための UML プロファイルです。このプロファイル (サービス・プロファイルと呼ばれることもあります) は IBM RSA (Rational Software Architect) に実装されており、複雑な顧客シナリオのモデル開発に使用されて成果を上げ、またサービス指向ソリューションの開発に関連する懸念事項の教育に使われています。」

このプロファイルは、Message や、Service Specification、Service といったステレオタイプを定義します。またプロファイルによって、これらの概念の特徴を図表で表すこともできます。図 2 は UML 図の一例として、保険ドメインにおけるメッセージ設計モデルを示しています (IBM Rational Software Architect より引用)。この UML 図は、サービス・プロファイルのステレオタイプである Message を使うクラス図 (構造図) として表現されています。

Model Driven Architecture (モデル駆動型アーキテクチャー)

MDA (Model Driven Architecture) は、ビジネスと技術双方の独立したモデルを持つことによって、常に変化しているビジネスと技術に対する答えを提供します。下記は OMG の MDA ユーザー・ガイドから引用した定義です。

「OMG の MDA は、ソフトウェア開発にモデルを使う上での、ベンダーに中立な方法です。MDA は下記のための方法として、ツールを提供します。

• システムをサポートするプラットフォームとは独立に、システムを指定する
• プラットフォームを指定する
• そのシステム用の特定のプラットフォームを選択する
• システム仕様を特定プラットフォーム用の仕様に変換する

MDA には移植性、相互運用性、そして再利用性という 3 つの主な目標があり、それをアーキテクチャーによるコンサーンの分離によって実現します。」

MDA の中核にある概念としては、システム (現状のシステム、あるいは目標とするシステム)、プラットフォーム (J2EE や Web サービスなどの機能を提供します)、そしてビューポイント (特定の概念に焦点を絞るための抽象化) などがあります。

MDA は次のようなモデルを定義しています。

• CIM (Computation-Independent Model): 機能に対する要件定義に使われるドメイン・モデル
• PIM (Platform-Independent Model): モデル構築の基礎となる (進化する) 技術から独立した、ビジネス機能と振る舞いのモデル
• PSM (Platform-Specific Model): PIM の仕様と特定のプラットフォーム・タイプの使い方との組み合わせ

MDA は変換を、あるシステムのモデルから同じシステムの別のモデルへの変換 (例えば PIM から PSM への変換) として定義します。1 つのモデルから別のモデルへの変換は、マッピングによって表現されます。

MDA の主な目標の 1 つは、MDA をサポートする設計や開発のツールを提供することです。

Model-Driven Development (モデル駆動型開発)

このセクションでここまでに説明した事項、特にモデルと変換は、MDD (Model-Driven Development) の基本です。MDD は MDSD (Model-Driven Software Development: モデル駆動型ソフトウェア開発) とも呼ばれるソフトウェア・エンジニアリングの手法であり、MDA はそれに対する規範的な標準です。MDD はモデルと変換に基づくソフトウェア開発の手法です。MDD では、半自動的にコードを生成することができます。つまり上位レベルのビジネス分析モデルから始まり、モデルからモデルへの一連の変換を使用し、そして最終的にはモデルからコードへの変換を使用することで、コードを生成することができます。そのためには、一連のモデルを定義し、モデル・インスタンスを完成し、変換に使われるさまざまなモデルの要素間のマッピングを行います。また MDD では変更の影響の分析も行うことができます。

IBM Rational の SDP (Software Delivery Platform) は、MDD (あるいはその他) による方法、例えば Business-Driven Development などに従って行われる、チームによるエンド・ツー・エンドのエンタープライズ・ソリューション開発をサポートしています。「BDD (Business-Driven Development: ビジネス駆動型開発) は、統合された役割ベースのソフトウェア開発手法であり、ビジネスと IT を整合させ、ビジネス・パフォーマンスの劇的な改善を実現します。」BDD もモデルを使用し、SOA のライフサイクル全体に渡って、ビジネス・モデルと IT モデルとの調整に焦点を絞ります (このシリーズの第 1 回を参照してください)。IBM の BDD では、ビジネス・アナリストや IT アーキテクト、J2EE 開発者、あるいは統合開発者などの役割を、IBM Software Delivery Platform によってサポートします。

Model-Driven Software Development を詳述した、IBM の思考リーダー達による IBM Systems Journal の記事を「参考文献」にあげましたので、それを参照してください。

上に戻る

資産

資産とパターンによって再利用が実現されるため、資産とパターンは SOA の成功にとっての鍵です。実際、資産ベースのビジネス・モデルを採用した企業は、非常に大きな成長能力を持ちます。そうした企業はもはや、労働に基づく従来のビジネス・モデルを使用した場合とは異なり、彼らのスタッフの生産性や人数に制限されることはありません。資産を適切に使用することによって、ソフトウェアへの投資を劇的に変えることができます。しかし、このモデルを採用した誰もが言うように、これは単純ではなく、適切なガバナンスとインフラ・サポートを必要とします。

創造性は、SOA の場合は生産性の障害となる可能性があります。アーキテクトや設計者、開発者が、新しいプロジェクトごとに白紙の状態から取り組むことは望ましくありません。類似の要件は、一貫性のあるアーキテクチャーや設計にする必要があります。資産とパターンを使うことで、適切なレベルの創造性が許容され、これによって実績のあるソリューションを可能な限り再利用することができるようになり、またすべての時間と努力を、新たに作り出すべきもの (そのプロジェクトに特有のビジネス・ロジックなど) に集中することができます。

資産は、対象となるコンテキストでの問題に対してソリューションを提供する成果物の集合です。この意味合いでは、成果物は任意のものが可能です (例えば要件や設計モデル、実装コード、あるいはテスト・ケースなど)。成果物はファイルシステム上のファイルと考えることができます。適切な資産であるためには、その資産の使い方やカスタマイズ方法、拡張方法についての説明を含めることが重要です。何が資産となるのかに関しては、「Reusable Asset Specification」のセクションを参照してください。

上に戻る

パターン

パターンは、対象とするコンテキストで繰り返し発生する問題へのソリューションです。またパターンは、特別なタイプの再利用可能な資産です。パターンの仕様 (問題の記述やコンテキスト、影響力、ソリューション) と、パターンの実装 (Java bean など) とは区別することができます。1 つのパターン仕様に対して、多くの実装があり得ます。

パターンは、そのパターンが開発プロセスのどのフェーズに当てはまるかによって、さまざまなカテゴリーに分類することができます。例えば、IBM Patterns for e-business は、パターンを、ビジネスと統合、複合、アプリケーション、そしてランタイムというカテゴリーに分類しています。また、GoF (Gang of Four) デザイン・パターンもよく知られています。

パターンを使用する際には、そうしたパターンによって提供される、あるいは体系化されるソリューションが正確で使いやすく、検証済みであることを確認する必要があります。しかし、どのようなタイプの再利用可能な資産にも言えることですが、そのパターンを採用できるのは、そのパターンをいつ、なぜ、どのように使用するのかに関するコンテキストと方法が与えられている場合のみです。多くのパターンが存在しますが、パターンの使用を開始するには、まず、該当するコンテキストが必要です。例えば、patterns for e-business は、ビジネス問題に対応する関連パターンを (スキルや環境に応じて) 特定する際に役立つプロセスと共に提供されています。

最後に、パターンの目標の 1 つは、一貫性を提供し、設計の中でパターンを使用すれば同じ要件に対して同じアーキテクチャーが得られるようすることです。

Reusable Asset Specification

RAS (Reusable Asset Specification) は、2005 年に採用された OMG 標準であり、再利用可能なソフトウェア資産の構造や内容、説明などを表現するために使われます。RAS の目標は、一貫性のある標準的な方法で資産をパッケージするためのベスト・プラクティスを提供することです。RAS の仕様に定義されているように、RAS 資産の中核的な特性には下記が含まれています。

• 分類: 資産が関係するコンテキスト
• ソリューション: 資産に含まれる成果物
• 使用方法: 資産をインストールし、使用し、カスタマイズするためのルール
• 関連資産: この資産が他の資産とどのように関係するか

成果物は、ファイル名接尾辞 (例えば .xml や .txt、.doc、.java など) あるいは資産の目的 (例えばユースケース・モデルや分析モデルなど) で決定されるタイプを持ちます。『ソフトウェア資産』は非常に意味の広い用語であるため、RAS は特定のタイプの資産を記述するために使われるプロファイルも提供しています。このプロファイルは UML プロファイルの概念と同じです。ドメインからは独立した UML の拡張に使われる UML プロファイルがあるのと同様に、ドメインからは独立した RAS の拡張に使われる、ドメイン専用 (例えば Web サービスなど) の RAS プロファイルがあります。

RAS 資産は .ras ファイル拡張子を持ち、.zip ファイルのようにパッケージされています。これはつまり、RAS 資産が目録を持ち、WinZip を使って開けることを意味しています。RAS の仕様から引用した図 2 は、RAS の中核資産の主なセクションを説明しています。

上に戻る

まとめ

この記事では、ソフトウェア・エンジニアリングのプロセスと方法に関する用語を定義しました。そして SOA ソリューションの構築に使われるソフトウェア成果物として、モデルと資産、パターンを定義しました。またキーとなる標準として、SPEM や UML、RAS などを紹介しました。

今後の記事では、分析や設計、実装、ランタイム、管理などに関連する SOA 用語を定義します。今後の developerWorks にご期待ください。

上に戻る

謝辞

この記事で解説した SOA や各種の概念に関して貢献いただいた、IBM の同僚に感謝いたします。特に、資産やサービスに関する Grant Larsen 氏の洞察に感謝いたします。

参考文献

学ぶために

• IBM の Enterprise Integration Solutions や戦略的 Service-Oriented Architecture、オンデマンド実用化について学んでください。
  
  
• IBM SOA Foundation のページを見てください。
  
  
• Model-Driven Software Development について知るために、IBM Systems Journal - Volume 44 (2005年11月4日刊) と IBM Systems Journal, Volume 45, Number 3 を読んでください。
  
  
• 「Rational Method Composer 入門 Key Concept 編 (前編)」から、キーとなる概念を学んでください。
  
  
• RMC について知るために、「Rational Method Composer 入門 Key Concept 編 (後編)」を読んでください。
  
  
• developerWorks の Rational Method Composer and RUP を読んでください。
  
  
• 「ソフトウェア・サービスのための UML 2.0 プロファイル」(developerWorks、2005年4月) を読み、UML 2.0 Profile for Software Services について学んでください。
  
  
• Reducing complexity with model-driven development を読んでください。
  
  
• Patterns for e-business に関する記事を読んでください。
  
  
• Object Management Group (OMG) の Web サイトを調べ、UML (Unified Modeling Language) や戦略的 Service-Oriented Architecture、オンデマンド実用化、MDA などに関する情報を入手してください。
  
  
• OMG の Web サイトで Software Process Engineering Metamodel, version 1.1 を見てください。
  
  
• OMG の RAS (Reusable Asset Specification) 仕様を見てください。
  
  
• EMF (Eclipse Modeling Framework) について読んでください。
  
  
• Wikipedia で RUP (Rational Unified Process) に関する説明を見てください。
  
  
• Wikipedia でメタデータについて学んでください。
  
  
• developerWorks technical events and webcasts で最新情報を入手してください。
  
  
• IBM の SOA Web サイトでは、SOA の概要と、IBM がどのように皆さんの SOA の実現に貢献できるかを知ることができます。
  
  
• developerWorks の SOA and Web services ゾーンを訪れ、SOA に関して学んでください。
  
  

製品や技術を入手するために

• 最新の IBM Rational Method Composer (RMC) 7.1 Plug-ins をダウンロードしてください。
  
  
• RMC の試用版 をダウンロードしてください。
  
  

議論するために

• developerWorks blogs から developerWorks のコミュニティーに加わってください。
  
  
• SOA and Web services discussion forums を利用してアーキテクトや開発者のコミュニティーと協力してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 開発のプロセスと方法
• モデル、UML、資産、そしてパターン
• UML (Unified Modeling Language)
• 資産
• パターン
• まとめ
• 謝辞
• 参考文献
• 著者について
• コメント