SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I（Web Services Interoperability Organization）が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました（参考：WS-I Completes Web Services Interoperability Standards Work（pdf））。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST（Representational State Transfer）と呼ばれるアーキテクチ
RESTful Web Services より良いWebインタフェースの構築と分散型システム連携 第1回：RESTのコンセプトと特徴 ～REST を知ると考え方が変わる～ 印刷 株式会社豆蔵 BS事業部 コンサルタント 五味 和人 2009/10/02 ［アーキテクチャ］ 現在、一般的になりつつある REST (REpresentational State Transfer) ですが、いざ実践しようとするためには、正しい理解と実装指針が必要です。前編となる本記事では、REST の概念をご紹介し、後編となる次記事では、一般的に言われている勘所と、私が実プロジェクトで実践した勘所についてご紹介します。 1. SaaS/PaaSとREST SaaS(Software as a Service)やPaaS(Platform as a Service)、クラウドといった言葉をよく耳にします。 We
_ Webコンピューティングの位置 コンピュータの特徴とは、ストアされたプログラムを実行することで、あらかじめ決めた手続きを高速かつ正確に再現することにある。 第二次世界大戦において、復号暗号の解読と弾道計算の2つの計算がコンピュータ開発のモティベーションとなった。 民生分野へ適用するとき、それは事務計算に対して行われた。 それまで事務計算は人間によって行われた。例外的な処理については現場の判断という柔軟な運用が可能であった。 しかしそれはコンピュータにはできないことである。 最初の価値の逆転が行われる。事務計算には例外的な処理は存在しないという前提を置くことで、この問題に対応した。 それによって、いわゆる大規模開発が許容されることとなった。開発されたシステムは中期以上にわたり変更されることはない。変更されずに使われることが前提に置かれたために、開発期間と開発要員という2つのコストを回収可
yohei-y:weblog: S はシンプルの S
This entry is a Japanese transration of Pete Lacey's "The S stands for Simple". Burton グループのアプリケーションプラットフォームサービスグループでは、 REST派とSOAP派の間でずっと継続中の議論がある。 その大部分は外部での議論によく似ている。 最近のやりとりの一つ、 SOAP と Web サービスフレームワークの複雑さの議論で、 SOAP 側は「WS-* の前は、SOAP は実際にシンプルだった。S はシンプルの略だ」といった。 さあ歴史を学ぼう。 2000年、悩める開発者が問題をかかえている。 開発者: うちの上司が先週末ゴルフをやってきて、 いわゆる SOAP なエンタープライズをやる必用があるんです。 でも私は SOAP が何なのか知りません。 教えてもください、 SOAP の人。 SOAP
« AJAXが大事何ではないはず | メイン | "Crossbow", Windows Forms & WPF Interoperability » 2006年02月18日 SOAP vs REST？ いいから出荷しろ Pragmatics - Don Box's Spoutlet ドン箱先生が、あんまりSOAPとRESTの違いについてあまりにも聞かれてウザイからと、その違いを5項目にまとめている。 SOAPを使用しているのか、POX（Plain Old XML)を使用しているのか。 一つはそれらのフォーマットにXML Schemaを使用しているか。 一つはXML Schemaを静的に言語にバインディングしているか。 一つがHTTPに特有の特徴に依存する程度。それは語られているように、危険覚悟でGETにねじどめする。 一つはメッセージ中心の設計アプローチをと
■ Yahoo! デベロッパーネットワーク よくある質問より: Q: Yahoo! JAPANは、SOAPはサポートしないのですか? 現在はサポートしていません。SOAPインターフェースに対する要望が多ければ、将来提供する可能性もあります。Yahoo!デベロッパーネットワークでは、RESTは敷居が低く、SOAPよりも簡単に使用でき、またWebサービスを利用するのに十分であると考えます。 そうやって誤解を撒き散らすのはヤメロっつーの。RESTの(仕組みの理解への)敷居が低いのは確かだが、現時点では(使うだけなら)SOAPの方が簡単だろ。違うレイヤーの話をごちゃ混ぜにしてるよ。こういう主張をするなら、主要各言語のクライアントライブラリを、すべて実装して公開すべきだ。
はじめに GoogleやAmazonを始め、多くの代表的なWebサービスでは、それ自身の機能を多くの利用者（開発者）に使ってもらうために、APIを提供しています。 その仕組みとしてSOAPやXML-RPCが使われていますが、今回はPHP5の新機能であるSOAP拡張機能を用いて、SOAPによるブックマークサービスを作成してみます。 対象読者 PHP5を用いて開発している方を対象とします。 また、今回用いるSOAPの拡張機能はPHP5から導入されたものなので、PHP4で開発している方はPEAR::SOAPを利用することで同様の事ができると思います。 必要な環境 筆者の環境ではいわゆるLAMP構成で開発を行っています。対象OSは、Unix/Linuxです（Windowsでは、サンプルプログラムが動作しません）。以下に、必要なPHP Extension（PHP拡張）をリストアップしま
KDDIは6月13日、XML対応のBREWアプリケーションを開発したと発表した。これにより、auの携帯電話から業務アプリケーションサーバにSOAPプロトコルを使って通信できるようになる。 同社では第一弾として、米Salesforce.comのCRMサービス「salesforce.com」とau携帯電話を連携させ、携帯電話からsalesforce.comのデータを参照したり、登録したりできるようにする。 今回KDDIが開発したのは、携帯電話内のデータをXMLに構文化したり、サーバから送られてきたXMLデータを解析したりするミドルウェア。実際の開発は北海道大学などが出資するベンチャー企業のテクノフェイスが担当した。 Salesforce.comはこのミドルウェア上で動くBREWアプリ「salesforce.com Mobile Edition for au」を開発した。このアプリを使うことで、
yohei-y:weblog: REST 入門(その10) 終わりに
» REST 入門 目次 前回まで、REST 入門ということで、 REST アーキテクチャスタイルとは何なのか、 について基礎的なところを結構細かく :-) 説明してきました。 REST 入門はこれで終わりですが、最後にロイ・フィールディングの論文から REST アーキテクチャスタイルの各制約を抜き出して説明します。 Null スタイル 最初は、制約がまったくないところからはじまります。それが Null スタイルです。 クライアント・サーバ 最初の制約はクライアント・サーバです。REST がクライアント・サーバから派生していることは、 "2. アーキテクチャスタイルとは" で解説しました。 ステートレス REST スタイルにおいて、サーバはクライアントの状態を管理しません。すべての状態はクライアントで持ちます。 クッキーでの状態管理が REST でないことは "8. REST でないもの"
yohei-y:weblog: REST 入門(その9) REST と SOAP
» REST 入門 目次 前回、WWW のうち REST アーキテクチャスタイルに従っていないものについて解説しました。 今回は「その筋」では有名な REST と SOAP の対決の概略を解説します。 Google で "REST vs SOAP" あるいは "SOAP vs REST" を検索すると、 たくさんの Web ページが見つかります。 いろいろな立場の人が、それぞれの意見を述べ合っていて、 ここで全ての主張や意見を解説するのは不可能です。 これから解説する内容は、あくまでも個人の意見ということをご了承ください(まー weblog なんてそんなもんですが)。 ところで最初からこんな話をするのもアレですが、 REST と SOAP は比べられるものなのでしょうか。 REST はこれまで何度も述べてきたとおり、ネットワークシステムのアーキテクチャスタイルです。 一方で SOAP はプ
May 18, 2005 Having finally found some time, this post continues my little mini-series on SOA styles. Once again a warning to the experts: expect and please accept some oversimplification and a whole lot of things that seem annoyingly obvious to you — but please do point out any mistakes you might find. The most pervasive Web services usage pattern is to use them as an interoperable means of doing
The Third Age of Web Services As I look back over the events of the last few weeks, it feels like we have now definitely entered the Third Age of Web Services. Here's the taxonomy I'm thinking about: First Age of Web Services - Basic Web Services Focus was on creating the base communication and messaging layer - including SOAP, WSDL and UDDI specifications. Second Age of Web Services - Advanced We
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
