RESTful WebサービスとSOAPベースのWebサービスの差がいまいちわからない

SOAに対する解を求めている人は非常に多い。これは結構意外でした。
いまだにSOAというキーワード(Buzzワード?)に対してこれほどまでに反応するひとが
多いので若干びっくりです。
それはなぜかというと、おそらく今までのSOAPベースのWebサービスをベースとした
SOAを捨て去れる可能性が出てきたからだと分析します。
そう、RESTful Webサービスです。RESTを使ったWebサービスでのSOA潜在的なニーズとしても高そうです。
RESTful Webサービスの具体的な実例も聞けてその点は非常に満足しています。
というわけで引き続きRESTベースのサービスをどうやって簡単に作るのか、注目です

JavaOne2008雑感
http://d.hatena.ne.jp/shot6/20080510

う〜ん。SOAが流行れるかどうかって、SOAPとかRESTとかの技術的な話なんだろうか?


昔、仕事でチャネル統合のフレームワークという物を作っていたのだが、実際に導入された現場ではそのように使われている事例を私は知らない(チャネル統合とは、銀行のテレバンとインバンのBLの部分で共通化できる部分は共通化しましょうみたいな話)。


あと、半年ぐらい前までやっていた仕事もチャネルに依存しないドメインモデルを作って、Viewに依存しないBLを作ってコンシュマー向けシステムと社内のコールセンター向けシステム統合しましょうみたいのはなしだったのだが、結構現場のSEは悶絶して大変そうだった。


SOAが流行れるかどうかって、

  • 業務の本質を理解してUI(≒特定の業務のシーン)に依存しないサービス(≒メソッド?、インターフェース)が作れますか?
  • その為の業務知識はありますか?
  • 分析手法はわかっていますか?


って辺りがわかれみちなんかじゃないと思う。


最近.NET3.5の講習にいってきたのだが、あるメソッドをSOAPで公開するか、RESTで公開するかってアノテーションレベルの設定でしかなったんですよね(かなりいい加減な言い方ですが・・・)。あと、RESTで行くか、SOAPで行くかっていうのは、クライアントの言語が何かっていうのによって大きく左右されると思ってます。型付けの強い言語であるJAVAC#なんかならば、SOAPでもそれほど困らないと思うし、ライトなスクリプト系、特にJavaScriptならRESTの方が断然お得だと思う。今のREST人気は、Webサービスを使うようなサービス構築ではライトなスクリプト系が花盛りっていうの支えられていると思ってます。


言いたいこととしては、SOAの阻害要因になっているのは、SOAPやREST等のレベルの話ではなくて、サービスを作るノウハウがあるかって所の方が圧倒的におおきいんじゃないかな〜ってことですね。


補足:それほどRESTを知っているわけではないのでもう一度REST系の記事でも読み直してみますか・・・