SIの現場でSE、PMなどを経験。現場を効率的にしたいと豆蔵に移籍。

SOA.NET

»

はじめに

 何かシステムを作成しようとしたり、更新しようとしたりした場合に、「既存システムの制限であれはできない、これはできない」となったことはないでしょうか。

 昔から受け継がれてきて、少しずつ増えてきた既存システム群は、通信や実装が複雑に絡み合い、こんがらがっていないでしょうか。

 既存システム群がこんがらがっているためにシステム更新や新規システム構築に悪影響が及ぶのであれば、まずは既存システム群をほぐしていけばいいのではないでしょうか。

 既存システム群をほぐす、つまり、既存のシステム同士を疎結合にするには、共通の通信手段と共通のトランザクションに統一する必要があります。分散しているシステムを統合する際に、共通の通信手段と共通のトランザクションが必要となることは20年も昔から(最近はSOAという名前に変わって)言われ続けていることです。最近になってやっとまともに使える標準仕様(WS-*)が策定され、様々なツールがその仕様に対応してきています。

 SOAというと、分散システムを統合する他にも、新しいシステムを早く品質良く作るために、共通のサービスを抽出し、サービスを再利用して似たようなものを作らないようにするとか、業務プロセスの変更に対応しやすくする……といったイメージがないでしょうか。もちろんそういった見方もありますが、本コラムではSOAの技術を、こんがらがった既存システム群をほぐすために利用できるのではないか、という視点から見ていきます。

 また、標準仕様に則れば、Javaや.NETといったプラットフォームに依存せずにどんな相手ともやりとりできる(ことになっている)ため、本コラムでSOAの要素を実現する手段はGUIでサクサクと開発できる(はずの).NETで探っていきたいと思います。

対象読者

 本コラムは、現場の設計者・開発者を対象と考えています。SOAなんて自分とは関係ないと考えるかもしれませんが、共通の通信方式、共通のトランザクションと言えば、実際の開発に直結してきます。その際に、なんだかわからないけど押しつけられて決まった方式でやる、というのと、この方式にすることで実際に得られるメリットをわかってやるのとではモチベーションも変わってくると思います。また、標準の方法を身につければ、自身のスキルアップにもつながります。

企業システムの現状とこれから

 様々な方法で構築された既存のシステム群は、現状どのようになっているでしょうか。

  • オンラインで連携していない
  • 独自の方法で連携している
  • 標準の方法で連携している

 オンラインで連携していない場合には以下の疑問がわきます。

  • 連携する必要がないのだろうか?
    • 連携したくてもできないのだろうか?
    • 仕方なくバッチでデータを投入して連携しているのだろうか?

 また、システム同士が連携している場合には以下の疑問がわきます。

  • なにか連携で失敗したときはどうやってロールバックしているのだろうか?
    • トランザクションについて考えられているのだろうか?
    • 修正依頼をして手で直しているのだろうか?
  • 新しく別のシステムをつなぐときはどうするつもりか?
    • 標準の方式でつなぐのか? 独自の方式に合わせてつなぐのか?
  • 既存のシステム同士をつなぎたくなったらどうするつもりか?
    • それぞれ違う方式だったらどちらに合わせるのか? 互換性はあるのか?

 独自の方式での連携は、他の方式とのコミュニケーションがとれないことや、新しいメンバーが方式を理解するための教育コストがかかること、仕様があいまいなことなどの問題を抱えています。こういった問題を解決するためにも、仕様がしっかり定義された標準の方式を用いるべきです。

 標準の方式を採用することには以下のメリットがあります。

  • 人材の確保が比較的容易
  • インターネットや書籍等で情報を得やすい
  • 対応したツールがあり、ツールのサポートが期待できる
  • 技術者としてどこでも通用するスキルを身につけることができる

 まずは既存システム群をほぐさないと、これからのシステム変更に悪影響が及ぶことは目に見えています。ただし、単にすべてのシステムをほぐすために使うお金はありません。システムの一部を更新するタイミングや、新規システムを構築するタイミングで、少しずつスモールスタートでSOA技術を導入していくことが現実解ではないでしょうか。

これからのシステムに必要なのはSOA視点

 SOAの技術は、これからのシステムに必要な要素をそろえています。

  • 共通の通信方法
    • SOAP
  • 共通の認証方法(WS-Security)
    • SOAPのメッセージレベルの認証(.NETもJavaも対応)
  • 共通のトランザクション(WS-Atomic Transaction)
    • Webサービスを跨るトランザクション(.NETもJavaも対応)
  • ロングランニングトランザクション(補償)
    • 状態の保持・障害発生時の補償処理
  • ビジネスプロセス(サービスの連携)
    • Webサービスのコラボレーション

SOA.NET = WCF + WF

 本コラムで取り組む.NET技術では、SOA = WCF + WFという式が成り立ちます。 WCFは分散通信テクノロジであり、WFはワークフローエンジンです。 それぞれSOA技術の以下の部分に対応します。

  • 共通の通信方法=WCF
    • Webサービス・SOAP通信対応
  • 共通の認証方法=WCF
    • WS-Security・SOAPメッセージレベルの認証対応
  • 共通のトランザクション=WCF
    • WS-Atomic Transaction・Webサービスを跨るトランザクション対応
  • ロングランニングトランザクション=WF
    • ロングランニングトランザクションの補償処理に対応
  • ビジネスプロセス=WF
    • Webサービスの連携に対応

次回

結合度の高い業務システム  既存のシステム群が、独自の連携方式でこんがらがっている状況を図にします。

 次回は、Small Start SOAということで、こんがらがった既存システムをほぐしていくことを考えてみます。

Comment(0)

コメント

コメントを投稿する