GlassFish Evangelist in Japan
Sunのプロフェッショナルサービスで、SunのSOA関連製品を
担当している草地さんもブログを
始められたようです。
最初のエントリはGlassFish ESBのインストール方法の
ご紹介をしてくださっています。
非常に優秀なエンジニアですので今後の彼の技術的な情報に
関するブログアップを期待しています。
Permalink
No Comments
Track Back :
今まで、SOAの概念的な所をずっと説明してきました。
今まで説明したSOAは「企業システムの全体最適を
柔軟にできる」という点でとても良さそうですよね。
そう、SOAの概念はとてもいいんです。
ただし、これは、私もSOAの担当になる前から思っていたことなのですが、
「SOAって概念はよさそうだけど、実際はどうなの？」と思ってました。
失敗しているプロジェクトも多数あるらしいし、
実際、"SOA" "失敗"というキーワードでググると
389,000件ヒットしています。
そしてそれ以外にも多くのネガティブなイメージをSOAに
抱いていました。
私が持っていたSOAに対するネガティブイメージ
● 失敗しそう
● 実装が難しそう
● どこから手を付ければいいか分からない
● 覚えることが山ほどありそう
これは、実際にSOAを導入する時に気をつけなければならない点
だと思うのですが、失敗しては元も子もありません、また実装が
難しければ勉強する時間が多くかかりすぎて、工数が高くつきます。
そして、企業システムの全体最適を行うといっても、どこから手を
付けていけばいいか、手をつけてもいいのかなんて分かりません。
さらに、現在SOAを実現しようと思うとWebサービス系のXML技術
を大量に学ばなければなりません。
これらの技術の取得はITエンジニアに対して今後も強いる事になると思います。
では、SOAはどこから始めればいいのでしょう？
現実的に考えると、「将来像を見据えて、できる所からやりましょう」
というのが１つの解ではないかと思います。
「企業のIT基盤システムの全体最適」を一度に全てやり始めると
時間もお金もたくさん掛かってしまいます。また失敗のリスクも
たくさんでてきます。
一方、どの会社でもかけられる予算は決まっていますし、
プロジェクトの失敗は許されないものです。
これを踏まえてどのようにして将来あるべき「企業システムの全体最適」に
向かっていくかについてですが、
マイルストーンをいくつかに区切って（システムの規模により異なりますが）
小さい所、できる所（データ連携やWebサービス化）から少しずつ始めて行けば
リスクを抑え最終的に柔軟性のあるシステムを構築する事ができるようになります。
そしてエンジニアも、全てのWebサービス関連技術(WS-**)を把握しなければ
できないなんて思わなくても、SOAP,WSDL等の基本的な技術を抑えた後に
序々に学んでいけばよいのです。
企業のシステムを将来柔軟性あるものにしたいと考えていても、
どこから始めればいいか分からない方は、是非我々にご相談ください。
経験豊富なエンジニアがそのノウハウやデザインパターンを持っています。
SunのSOA製品はオープンソースをベースに非常に低価格で、さらに
標準準拠されていますので、ベンダーロックインなんてことも発生しません。
SunのSOA: Sun Java CAPSの紹介ページへ
実際に検討してみたいという方は是非、弊社の営業経由でお問い合せください。
Permalink
No Comments
Track Back :
エンジニア以外の人にも「分かりやすく、かんたんに」を実現
しようとしているのがSOA
ガートナーのロイ・シェルテが1996年に名付けたSOAが
こうなのかはわかりませんが、私の中では(Sunではなく)
このように考えるととてもすっきりしています。
今までの歴史は、開発者にとって「分かりやすく、かんたんに」を
目指してきました。
アセンブラから始まり、手続き型、モジュール化、オブジェクト指向へと
進化してきたのですが、言語の進化、開発ツールの進化の過程により開発者に
とっての「分かりやすく、かんたんに」は随分進化しわかりやすくなってきました。
一方でITエンジニア以外がシステムを理解するためにはどうでしょう？
たとえば、会社の社長が社内のシステムの全体像を理解して
有効活用させたいと考えます。
その場合、恐らく既存のシステムを理解する所からつまずくでしょう。
なぜなら、今あるシステムのドキュメントは開発者には
分かりやすいものですが、詳細すぎて社長をはじめ、ITに精通していない人には
全体像を理解するには難しすぎるからです。
開発者が作成したUML図を開発者以外が見てもよくわからないからでしょう。
ですので、開発者以外の人がシステム全体を理解しやすいように、
ITシステム基盤を構築するアーキテクチャをSOAと読んでいます。
ポイント：
詳細な設計資料から全体像を把握するのは困難
これを積み木に例えて、積み木で家を作る時を考えましょう。
最もかんたんな家は下記の絵のように、四角の木が２本と三角の木が
１本あれば家をつくる事ができます。
この時、家の全体像を把握したい人（社長）は四角の木が２本と三角の木が１本あれば
できることを理解すればよいのです。
木の材質（どの言語でつくられているか）や木がどのように作られたか
（内部的にどのように実装されているか）は（社長は）知らなくてもよいのです。
これをサービスに置き換えて考えると、それぞれの木をサービスとして
おきかえてみてください。
Javaで実装されたサービス：
● サービスA（四角の木）
● サービスB（四角の木）
.Netで実装されたサービス：
● サービスC（三角の木）
どの言語か、どのような実装かは理解しなくても、単にサービスA、サービスB、
サービスCという抽象度の高いコンポーネントからシステムが作られていることが
理解できれば、今までよりも明らかに分かりやすくなります。
ここではサービスとしてJavaや、.Netを例にあげていますが
言語はなんでもよくまた、サービスの連携もプログラム言語だけでなく、
汎用機や、DB、ERPなどのデー連携などでもよいです。
ポイント：
SOAが目指す「分かりやすく、かんたんに」は開発者、システムエンジニア向けではなく、
エンジニア以外の人が見てもITシステムの全体像を分かりやすくすることです。
次回は、SOAで「柔軟さ」が必要なわけを説明します。
Permalink
2 Comments
Track Back :
ブログのコメントにSOAって何？とご質問を頂いたので、
私なりのSOAの解釈についてまとめたいと思います。
まぁ、私も数年ぶりにSOAに触れているので、
間違った解釈もあるかもしれないですが、そこはお許しください。
SOA=サービス指向アーキテクチャです。
なんていう怒られちゃいそうですが、(^_^;)
サービス指向っていうのは今までもずっと開発の
歴史の中にあった、人間にとって「わかりやすく、かんたんに」
を考えた先のアーキテクチャなのです。
プラスするならばシステムに柔軟さを持たせるためのアーキテクチャです。
SOAのポイント：
● 分かりやすく
● かんたんに
● 柔軟に
SOA導入により目指すべきゴール：
● 企業ITシステムの全体最適を行う
● 柔軟に企業のIT基盤を変更できるようにする
詳しく説明すると長くなりそうなので何回かに分けて書きます。
次回は、誰にとって「わかりやすく、かんたんに」？
Permalink
No Comments
Track Back :
|
|
Today's Page Hits: 1010