SOA 実践的なSOAアプローチ

2月25日
土日と関東は大荒れの天気。春一番から、北風に変り強風の2日間。
砂が舞い上がり、歩く人も少なくなりました。
被害が出たところもあります。

今日は実践的なSOAアプローチについて。

• 「壊してリプレース（rip and replace）」ではなく「隠蔽して再利用（wrap and reuse）」
• サービスの組み合わせによるコンポジット・アプリケーションの実現
• 段階的な適用
• 標準準拠，相互運用性の確保

このようなアプローチのも、システムの全面的な再構築ではなく、既存システムを隠蔽、再利用しながら、部分的、段階的にSOAを適用し、小さな成功を早期に達成できるようにします。
こうすることにより，企業全体へのSOAの展開をスムーズに進められるようになります。

レガシな部分との接続、ERPとの接続については課題が多いようです。

SOAのバリュー

2月22日猫の日です。
猫を大切にしましょう。

今日はSOAのバリューです。

• ROIの向上，TCOの削減
  共用，再利用可能なサービスをベースとしてアプリケーションを構築することにより，開発期間，Time To Marketを短縮し，開発コストを削減できます。これにより，ビジネス機会の損失を最小限に抑え，早期にROIを獲得することができます。また，システム間のポイント・ツー・ポイントの接続がなくなり，アーキテクチャが簡素化されますので，運用管理，メンテナンスが容易になります。
• ビジネス・プロセスの自動化
  BPM（Business Process Management）機能を使用することにより，WS-BPELで定義したビジネス・プロセスを自動化できます。これにより，業務の効率化，ビジネス・プロセス実行のスピードアップが図れます。
• ビジネス・プロセス，ビジネス・アクティビティの可視化
  BPM（Business Process Management）機能を使用することにより，WS-BPELで定義したビジネス・プロセスがそのまま実行され，ビジネス・プロセス・モデルとITシステムが連動するようになり，モデルと実システムとの乖離がなくなります。また，BAM（Business Acitivity Monitoring）機能を使用することで，KPI（Key Performance Indicator）などのビジネス・アクティビティをモニタリングできるようになります。
• ビジネス・プロセス
  改善の容易化，スピードアップビジネス・プロセス・モデルの変更に即応して，ITシステムで実行されるビジネス・プロセスを更新できますので，ビジネス・プロセス改善の容易化，スピードアップが図れます。
• インテグレーションの容易化，スピードアップ
  サービスの公開，取り込みが容易になりますので，社内，社外のシステムとの連携が容易化，スピードアップします。
• リアルタイム性の向上
  マニュアル入力による連携やファイル転送を用いたバッチ連携が必要であった箇所を，リアルタイムで連携できるようになりますので，一連のビジネス・プロセスを完了するまでにかかる時間，リードタイムを短縮できます。また，リアルタイムで更新される最新のデータを参照しながら，迅速にビジネスの状況を判断し，対応できるようなります。このときBAM機能を有効に活用できます。
• 柔軟性の向上
  レイヤ構成を徹底し，レイヤ間の疎結合化を行うことにより，ライフサイクルの異なる各種の要素（ビジネス・プロセス，サービス，システム，リソースなど）を入れ替えながら，ITシステム全体の新陳代謝を促すことができます。
• ベンダ・ロックインの回避
  プラットフォーム，開発言語に中立なアーキテクチャを採用することにより，ベンダー・ロックインを回避できます。

SOAのレイヤ構成

2月21日

よい天気が続き、春らしくなってきました。

と言っても花粉症の人にはつらい時期。実は私も花粉症です。

さて今日はSOAのレイヤ構成です。


三階層の人には少しなじみがあると思います。

1. アクセス・レイヤ（Access Layer）
   ビジネス・プロセスやサービスとその利用者のインタラクションを実現します。例えば，ビジネス・プロセスとユーザのインタラクションを実現するWeb画面などがこのレイヤに位置づけられます。


2. プロセス・レイヤ（Process Layer）
   サービスをベースとしてビジネス・プロセスを組み立てます。複数のサービスを利用してビジネス・プロセスを組み立てることをオーケストレーションと呼びます。


3. サービス・レイヤ（Service Layer）
   ビジネス機能をサービスとして実現します。


4. リソース・レイヤ（Resource Layer）
   バックエンドのデータ・リポジトリを隠蔽，抽象化します。

• 従来のエンタープライズ・システムでも階層（ティア）の考え方は存在していました。例えば、Java EE（Enterprise Edition）をベースにしたシステムでは、プレゼンテーション階層，ビジネス階層、リソース階層の3階層を設けるのが一般的でした。


• これと比較した場合に，SOAで特徴的なのは，ビジネス階層と呼ばれていた部分を、プロセス・レイヤとサービス・レイヤに明確に分離している点です。これを可能にしているのが、XML形式でビジネス・プロセスを定義するための標準仕様であるWS-BPEL（Web Services Business Process Execution Language）です。典型的には、プロセス・レイヤにおいてWS-BPELを用いて定義されたビジネス・プロセスをビジネス・プロセス実行エンジンで実行します。ビジネス・プロセスはサービス・レイヤに配置されているサービスのオーケストレーションで構成されます。ビジネス・プロセス実行エンジンはSOAPを用いてサービスの呼び出しを行います。


• SOAでは、プロセス・レイヤとサービス・レイヤを分離することにより，ビジネス・プロセスの変更に対してより柔軟に対応できるようになっています。

SOAの適用

2月19日

日が長くなり、陽射しも春らしくなってきました。まだ気温が低いですが、気分的には寒さを感じません。

さて今日は、エンタープライズ・システムへのSOAの適用について述べます。

エンタープライズ・システムへのSOAの適用というのは、アプリケーションをスクラッチで再構築することではありません。

• 既存のアプリケーションをリファクタリングして、ビジネス機能を、企業内の他のアプリケーションおよび外部のパートナーにとって統合しやすいサービスとして公開することがSOA適用の第一歩になります。
  
• 従来のシステムでは、アプリケーションとビジネス機能が密結合しており（モノリシック・アプリケーション）、ビジネス機能を他のアプリケーションに公開するようなことは想定されていませんでした。
  その結果、様々なアプリケーションで同じビジネス機能を重複して開発するといった無駄が生じていました。このように、横の連携がないモノリシック・アプリケーションが林立した状態を「サイロ」と呼ぶこともあります。
  
• 一方、SOAでは、ビジネス機能を外部から利用しやすいサービスとして公開します。
  これにより複数のアプリケーションや外部のパートナーとの間でもサービスを共用、再利用できるようになります。そしてサービスをベースとしてビジネス・プロセスを組み立てることによりアプリケーションを構築します。このような組み立て型のアプリケーションをコンポジット・アプリケーションと呼びます。

SOAの基本サービス

2月18日
昨日の東京マラソン、多くの人が走り、すごいですね。
完走された人、完走されなかった人、お疲れ様でした。
私は、走れませんが。。。

さて今日は、SOAの基本サービスについてのべます。

1. サービス・プロバイダ（Service Provider）
   サービス（Service）を提供するエンティティです。サービスは，標準的な方法に基づいて記述されます。これをサービス記述（Service Description）と呼びます。サービス記述の標準仕様としてWSDL（Web Services Description Language）があります。
   
2. サービス・レジストリ（Service Registry）
   サービスの公開（Publish），発見（Find）を仲介するブローカとしての役割を果たすエンティティです。サービス・レジストリの標準仕様としてUDDI（Universal Description, Discovery and Integration）やebXML Registry があります。サービス・プロバイダは，サービスおよびサービス記述をサービス・レジストリに公開します。
   
3. サービス・コンシューマ（Service Consumer）
   サービスを利用するエンティティです。サービス・コンシューマは，サービス・レジストリからサービスを発見し，サービスにバインド（Bind），呼び出し（Invoke）を行います。サービス・コンシューマからサービスへの呼び出しプロトコルの標準仕様としてSOAP（Simple Object Access Protocol）があります。

SOA オブジェクト指向との違い

2月15日晴れ。

技術は日進月歩、でも技術者は育たない、これには理由があります。

これは後日に。



でもはSOAについて、今日はオブジェクトの違いについてのべます。



再利用される範囲

SOAのサービスは、企業の内外を問わず、複数のアプリケーションをまたがって再利用できるようになっている。一方、オブジェクトやコンポーネントは、どちらかと言えば同一アプリケーション内、あるいは複数のアプリケーション間であっても企業内で再利用されるソフトウエア部品である。


ソフトウエア部品の粒度

SOAのサービスはビジネス環境の変化に効率よく対応できるように、ビジネス・プロセスの一部（サブ・プロセス）を表現していることが多い。例えば、「在庫確認サービス」「発注サービス」などだ。一方、オブジェクトやコンポーネントは、プログラム作成をいかに効率化させるかという点に着目しており、業務処理の変化をシステムの変更に素早く反映させたいという観点で見ると粒度が小さ過ぎる。オブジェクトやコンポーネントがシステム側の都合で構成されるのとは対照的に、サービスはビジネス視点で構成される。


結合度

オブジェクトやコンポーネントはアプリケーション同士が密接に結合（密結合）しており自由度が低かった。しかし、SOAではインタフェースの方式を決めておくだけの“疎結合”でつながっている。そのため、制約が少なく、多様な組み合わせを実現するための自由度が高い。


相互運用性、相互接続性

オブジェクトやコンポーネントは同質の技術との通信を前提に設計されているが、SOAは異機種混合環境を前提にしているので、多様なプラットフォームや技術間での連携が可能である。

SOAで言うサービスとは

2月14日晴れ

なかなかインができず、ようやく書き込みが可能に。
今日は、SOAでいうサービスについて述べる。

SOAの実装技術の中心であるWebサービスでは、
インタフェース記述言語としてWSDL（Web Services Description Language）、
サービスの呼び出しにSOAP（Simple Object Access Protocol）、HTTPというプロトコルを
利用するのが一般的である。

しかし、WebサービスのみがSOAの実装技術というわけではない。
JMS(Java Message Service)やJCA(J2EE Connector Architecture)といったほかのプロトコルを利用することも可能である。

上記のような特徴を持つサービスを組み合わせることでアプリケーションを構成するシステム構築の考え方がSOAである。
SOAを用いた実際のシステムは
ビジネス・プロセス→サービス→ コンポーネント→ システムという階層構造となる。

といって、理論的には簡単そうに見えるが実装技術などは簡単ではない。
いろいろと複雑なことが多い。

SOAとは

寒い日が続きますね。
お風邪を引かないように気をつけてください。

本日はSOAについて

SOA（Service Oriented Architecture：サービス指向アーキテクチャ）とは、アプリケーションあるいはその機能の一部を共通の“サービス”としてコンポーネント化（部品化）し、それらサービスを必要に応じて組み合わせることで、新たなシステムを構築しようという設計手法である。

SOAという言葉が広く認識されるようになったのは2004年。
しかし、SOAの概念自体は，決して新しいものではなく，それ以前から存在していた。
SOAの考え方は、分散オブジェクト技術の流れをくむもので、2004年以前から
マイクロソフトのDCOM（Distributed Component Object Model）や
標準化団体であるOMG（Object Management Group）が策定したCORBA（Common Object Request Broker Architecture）など、
現在のSOAのコンセプトと同等のことを実現しようという試みがなされてきた。

しかし、これらの技術は残念ながら普及したとは言いがたい。

例えば、
DCOMはWindows同士でしか通信ができず、汎用性に欠けた。
一方、CORBAはプラットフォームに制約はないものの、仕様が複雑だったので、実装が難しく、結果的にCORBAに準拠したミドルウエアは一部のベンダーでしか開発されなかった。
また、異なるCORBA実装間の相互運用性も不十分であった。

これらに対して、現在、SOAを実現する技術として最も有望視されているWebサービスはXMLやHTTPというシンプルで一般的な仕様をベースとしている。そのため、実装が容易で、ベンダー各社が支持を示したことによって、相互接続性の問題もほぼ解決している点で違いがある。