2006年 4月 14日 金曜日
2006年 4月 14日 金曜日 SOAのバリューをITの側面から眺めてみましょう。
ここでは「時間」「空間」「リソース」の3つの軸を用いて整理してみたいと思います。
まずは「時間」から。
- リアルタイム性向上
SOAでは，Webサービスのような標準プロトコルを用いてシステム間の連携を行います。これにより，マニュアル入力による連携やファイル転送を用いたバッチ連携が必要であった箇所を，リアルタイムで連携させられるようになります。
リアルタイムで連携できるようになれば，一連の処理を完了するまでにかかる時間を短縮できます。例えば，物品の購入プロセスにSOAを適用した場合，与信チェック，在庫確認，納期回答，会計処理，出荷指示…といった一連の処理をその場で完了する，ということも可能になるわけです。
また，リアルタイムで更新される最新のデータを参照しながら，迅速にビジネスの状況を判断し，対応できるようになります。このときBAM（Business Activity Monitoring）ツールを有効に活用できます。 - ビジネス・サービスの改善
SOAでは，ビジネス・サービスの組み合わせによってビジネス・プロセスを実現できます。ここで「疎結合」というSOAの原則に従ってビジネス・サービスを構成しておけば，もし時間とともに状況が変化して，あるビジネス・サービスに対する要件が変化しても，他のビジネス・サービスに影響を与えることなく，そのビジネス・サービスを変更，改善できるようになります。例えば，上述の購入プロセスで，与信チェックに人間が関与していたものを，自動チェックに変更するような場合でも，その他の一連の処理には全く影響を与えずに済みます。 - ビジネス・プロセスの改善
SOAのBPM（Business Process Management）機能を用いれば，ビジネス・プロセスをBPELのようなビジネス・プロセス実行言語で定義し，そのまま実行できます。
ビジネスの状況変化などに従って，ビジネス・プロセスがビジネス実行上のボトルネックになってしまった場合，BPM機能を用いると，ビジネス・サービスの組み換えによってビジネス・プロセスを改善させることが可能になります。
例えば，上述の購入プロセスで，全ての与信チェックに常に3段階の承認が必要だったものを，一定金額以下であれば1段階の承認で済ませる，というような変更も，BPMツールを用いて容易に行えるようになります。 - ライフサイクルの異なるシステム群の共存
企業のシステム全体を考えた場合，通常，そこには複数のシステムが存在します。そうするとシステム毎に稼動開始時期や稼動期間が異なってきます。例えば，10年前から稼動しており2年後には稼動終了が予定されているレガシーシステムと，今後5年間使用する予定の新たなシステムを連携させなければならない，というような状況が当然発生します。
SunのSOAでは「wrap and reuse（隠蔽して再利用）」を大原則としています。このような場合には，レガシーシステムを隠蔽してビジネス・サービスとして機能，インタフェースを公開するようにして，新規システムと連携させます。そして，2年後にレガシーシステムが引退する際には，ビジネス・サービスのインタフェースはそのままで，実現手段をレガシーシステムから最新システムに（あるいは外部のサービスに）変更する，ということで対応します。
ここで一つ注意ですが，SOAは（SOAに限らずどんなテクノロジーでも）万能ではありませんし，SOAで言われている全ての機能を使用する必要もありません。例えば「SOAではBPELによるビジネス・プロセス実行という処理が余分に増えるから性能が劣化する」というような声も聞かれますが，それは正しくないと考えています。というのも，BPM/BPELを使用しないSOAも可能だからです。この辺りは，機能要件やサービスレベル要件のトレードオフになります。ビジネス・プロセスの変更がそれほど頻繁ではなく，性能がクリティカルな場合にはビジネス・プロセスのロジックをプログラムで作り込めば良いのです。正にアーキテクトの真価の発揮しどころですね。
2006年 4月 05日 水曜日 最近，何でも"2.0"をつけるのが流行っているようなので，SOAやWeb 2.0によって企業システムがどのような影響を受けるのか，"企業システム2.0"の思考実験を行ってみたいと思います。
ひとりブレインストーミングの結果です。
- 自社でインフラを保有せず，仮想的なコンピューティング環境（以下，便宜的に「グリッド」と呼びます。正確な定義と違うというご指摘もあるかもしれませんがご勘弁を。）を利用します。グリッド上で，Webサーバ，アプリケーションサーバ，ESBなどの標準コンテナが提供されます。
- システムの機能は，グリッド上でSaaS(Software as a Service)を利用して，SaaSとして或いはオープン・サービスとして実現されます。オープン・サービスとは，開発者コミュニティにより自由に開発されるサービスで，(グリッドのような)共有，実行可能な場所に配置されます。(オープン・サービスは，Sun Analyst Summit 2006でGreg Papadopoulosによって提唱されています。)
サービス開発にはSOAの考え方が取り入れられます。 - 開発には，社内の開発者コミュニティ，さらには社外の開発者コミュニティも参加します。
社員には20%ルール(自分の時間の20%を自由に使って良い)が適用され，この時間を使って自由にサービスの開発/改良が行われます。 - 外部とのインタフェースとして，サービスのAPI（典型的にはWebサービス，SOAP or REST）が公開されます。更にオープン・サービスではサービス実装も公開され，開発者コミュニティによって継続的な改良が施されます。
- 自社のビジネスの境界は曖昧になります。サービスを公開し，コミュニティを支援することによって，社外の開発者コミュニティ，そして社外のサービスを巻き込む形で，自己組織的にビジネスの輪郭が形作られていきます。
Sunでは，いわゆる"2.0"を支えるべく，Sun Grid，Solaris Enterprise System等の製品，サービス，ソリューションを提供し，同時にコミュニティの支援を行っています。"2.0"に注目される方はSunの動向も要チェックです。
2006年 4月 01日 土曜日 Sun SOAの日本語ページができました。
SunのSOAに対するアプローチ，製品構成，サービスメニュー，Whitepaper, 事例など，各種の情報を入手できますので，有効活用してください。
SunのSOAに対するアプローチ，製品構成，サービスメニュー，Whitepaper, 事例など，各種の情報を入手できますので，有効活用してください。
2006年 3月 30日 木曜日 Sun Business .Next @東京にてセッションを持つことになりました。タイトルは「SOAとJavaテクノロジーその可能性と現在」です。私のセッションは兎も角，Greg PapadopoulosやDavid Yenの基調講演は必見です。是非ご登録ください。
2006年 3月 22日 水曜日 SunではSOAのアーキテクチャとして，4つのレイヤを定義しています。
- アクセス・レイヤ
ビジネス・プロセスへのアクセス・ポイントとなるレイヤ。
（ex. ポータル画面等が配置される） - プロセス・レイヤ
ビジネス・サービスをベースとしてビジネス・プロセスを実現するレイヤ。
（ex. BPELが実行される） - サービス・レイヤ
テクニカル・サービスをベースとしてビジネス機能を実現するレイヤ。
（ex. ビジネス・サービスが配置される） - テクニカル・プラットフォーム・レイヤ（リソースレイヤ）
リソースやレガシーシステム，プロトコルの詳細を隠蔽するレイヤ。
（ex. テクニカル・サービスが配置される）
SOAはその名の通り”アーキテクチャ”ですので，このような形でエンタープライズ・システム全体でのアーキテクチャの整合性をとっておくことが最も重要です。アーキテクチャをきっちり守っておけば，その実装形態（例えば，サービスをSOA基盤ソフトウェアをベースに簡単に開発する，Java EEでカスタム開発する，など）が多少異なっていたとしても，そのメリットを損なうことなくSOAを実現することができます。
2006年 3月 15日 水曜日 以前のエントリ（狭義のSOA，広義のSOA）では技術的な観点からSOAについて整理してみました。
一方，SOAをビジネスの観点から見た場合の重要なフレーバーとして，"ビジネス駆動(Business Driven)"あるいは"ビジネスプロセス駆動(Business Process Driven)"の考え方があります。ビジネス・プロセス駆動の考え方では，まず，業務機能要件をビジネス・プロセス・モデルとして定義します。それをSOAをベースにしたリファレンス・アーキテクチャに従いながら，システム機能要件を表現するようなオーケストレーション・モデルに落とし込みます。（ユースケースとのアナロジーで考えると，ビジネス・ユースケースからシステム・ユースケースへの落とし込みに相当します。）オーケストレーション・モデルはビジネス・サービス（ビジネス機能を実現するサービス）を組み合わせて構成されます。ビジネス・サービスはビジネス・ロジックとテクニカル・サービス（リソースやプロトコルの詳細を隠蔽するサービス）の呼び出しで実現されます。具体的には，オーケストレーション・モデルはBPELによって定義され，BPELエンジンで実行されます。
SOAを成功させるには，業務要件の実現を第一義とする，ビジネス・プロセス駆動の考え方（あるいはトップ・ダウン・アプローチと呼んでも良いかもしれません）が重要です。また，このような形で，ビジネスとシステムをシームレスにつないでおくことにより，SOAをBPM(Business Process Management)の基盤として活用できるようになります。
2006年 3月 08日 水曜日 NASAは1990年代に「Cheaper, Better, Faster」への方針転換を行いました。例えば,Mars Pathfinder以降の火星探査では，パラシュートとエアバッグを使ってシンプルな（大胆な）着陸を行うことにより，Cheaper, Better, Fasterを達成しています（動画）。つまり，現在のRocket Scienceは以前のRocket Scienceとは変わってきているのです。
宇宙開発においてCheaper, Better, Fasterを実現する方法のひとつとして,標準化,再利用があげられています。これって，SOAと共通する考え方ですね。SOAはエンタープライズシステムにおいてCheaper, Better, Fasterを実現する手段と言えます。SOAの話をすると「再利用なんて無理」とか言われる場合が多いですが,宇宙開発だって変わっているのですから,IT開発だって変われないはずがありません。
2006年 3月 04日 土曜日 最近JAXAが1ヶ月の間に2回，H-IIAロケットの打ち上げを成功させたことが話題になっていました。日本の宇宙開発が最近失敗続きだったことから,やっぱりRocket Scienceは（英語のスラングでも使われるように）複雑で難しいことなんだなと思われている方も多いかと思います。
しかし，宇宙開発も最近変わってきているのです。たとえば現在も土星探査をつづけているカッシーニの説明を見てみると「97年10月にフロリダ州ケープカナベラル宇宙基地からタイタン4型ロケットによって打ち上げられた高さ約7メートル、幅約4メートル、重さ約6トンとNASA最後といわれる重厚長大な土星探査機」との記述があります。なぜカッシーニが「NASA最後の重厚長大な土星探査機」と言われるようになったのでしょうか。
2006年 2月 25日 土曜日 OpenESBプロジェクトのWhiteper(PDF)とFAQにService-Oriented Integration (SOI)に関する記述があります。
Q. What is the difference between service-oriented architecture (SOA) and service-oriented integration (SOI)?
SOA is an architectural pattern for constructing systems, based on service descriptions. Such systems are rarely constructed in completely new IT environments; instead, many of the services must come from existing applications within an enterprise. The act of adapting an application (or messaging protocol) to interact with other applications that it was not designed to interoperate with is called integration. Adapting applications and protocols to a SOA is a very common activity, and is called service-oriented integration (SOI).
広義のSOAのうち「インテグレーション分野に狭義のSOAを適用する」ことがSOIに相当しそうですね。
2006年 2月 22日 水曜日 Sun SOAのページにSOAのTCOに関するWhitepaper（PDF）が載っています。
この調査報告（Butler Group）を要約すると，Sun Java Integration Suite（Sun Java CAPSに名称変更されています）のように，サービス指向のComposite Applicationを，うまく統合された開発環境を用いて開発すると，従来型のJ2EE（現在はJava EEと呼ぶのが正です）開発に比べて，初期フェーズ（設計，開発，ディプロイ）で50%，2～3年目のメンテナンスで70%，3年間トータルで58%のコスト削減が見込めるそうです。
うまく統合された開発環境（例えば，Sun Java CAPSの統合開発環境であるEnterprise Designerは，Near-Zeroコーディングを謳い文句にしています）では，コーディング量を大幅に削減できますので，開発，テスト，運用の工数を削減できるとされています。
旧SeeBeyond U.S.のSEの人によると，これまでのデモ開発等は全てコーディングを一切行わずに実現してきたそうです。これはちょっと極端ですが，SOAの開発では，画面開発，プロセス定義，サービス開発，多種多様なシステムと接続など多くの要素が含まれてきますので，それらをうまく連携して簡単に実現できる開発環境が重要というのは疑いようがありませんね。