Project Zero,背景と概要

Project Zero,背景と概要
小出理史(日本IBMシステムズ・エンジニアリング)
須江信洋(日本IBM)
1
ご注意
この資料に含まれる情報は可能な限り正確を期しておりますが、日本アイ・ビー・エム株式会社及び日本アイ・ビー・エムシステム
ズ・エンジニアリング株式会社の正式なレビューを受けておらず、当資料に記載された内容に関して日本アイ・ビー・エム株式会社及び
日本アイ・ビー・エムシステムズ・エンジニアリング株式会社は何ら保証するものではありません。
従って、この情報の利用またはこれらの技法の実施はひとえに使用者の責任において為されるものであり、資料の内容によって受けたい
かなる被害に関しても一切の保証をするものではありません。
当資料をコピー等で複製することは、日本アイ・ビー・エム株式会社及び日本アイ・ビー・エムシステムズ・エンジニアリング株式会
社および執筆者の承諾なしではできません。また、当資料に記載された製品名または会社名はそれぞれの各社の商標または登録商標です。
2
アジェンダ




1.
2.
3.
4.
Project Zeroの背景
RESTとWebサービス
スクリプト言語とWebアプリケーション
Project Zero First Look
3
1. Project Zeroの背景
2007年のWebシステム開発
4
現代のWebシステムの特徴
 ビジネスの要請：大規模化、開発期間／更新間隔の短期化
 大規模かつ短期開発かつ頻繁な更新
 「大規模なので、開発期間が欲しい・・」

 「大規模なので、長く使いたい・・」

 開発者には悪夢？だが・・
 もう、「あのサイトは、例外です」では、済まない・・
 可能にしている、「何か」がある
 数：「大規模」を可能にする、何か
 質：「短期開発／頻繁な更新」を可能にする、何か
 相互に矛盾しない、何か
5
×
×
技術背景（１）：
大規模、短期開発/更新の必須条件
 ハードウェア
 価格性能比向上、一定の信頼性維持
 OS/ミドルウェア
 提供する機能の信頼性向上
 分散システム設計手法
 運用開始後の構成変更に対する対応性向上
 開発方法論
 短期開発における信頼性向上
6
技術背景(2)：
必須条件の実現方針、付加価値
 OS/ミドルウェア：信頼性
 機能を絞り込んで信頼性を確保、極端な低価格も実現 OSS的
商用的
 対価を得て、多機能と信頼性を両立
 分散システム設計手法：運用開始後の柔軟性
 連携するコンポーネントを、容易に追加／変更可能とする OSS的
 コンポーネントの多機能化を容易にする
商用的
 開発方法論：時間をかけずに信頼性向上
 ソース  実行/テストの時間短縮 OSS的
商用的
 モデル  ソースの時間短縮
数  質？
質  数？
7
注：OSS的／商用的は象徴的な表現。明確な線引きではない
「OSS的」の良さを学ぶ：Project Zero
 開発方法論：ソース実行/テストの短縮, ..
 スクリプト言語、設定ファイル削減, …
 分散システム設計手法：コンポーネント連携の容易な変更／追加
 REST, …
 OS/ミドルウェア:絞り込んだ機能、使い勝手向上
 REST+スクリプト言語を想定した、信頼性の高い実行環境
 Javaで記述された、Web(CGIモデル)+αのフレームワーク
 OS/ミドルウェア:極端な価格低下
 学べる/学べない場合、存在価値の問題・・
 模索中
8
“Reliable”, ”Simple”, ”Rapid”
 人間は間違う。ソフトウェア/ハードウェアも、誤動作の可能性を含む。

誰かが/いつか/どこかで、信頼性確保に注力する
 世の中は複雑。論理演算は単純。

誰かが/いつか/どこかで、複雑さの吸収に注力する
 実装には時間が必要。既存実装の利用方法習得にも時間が必要。

誰かが/いつか/どこかで、時間をつぎ込む
 だれが/いつ/どこで、
どの程度の割合で、行う事が適しているのか？



複雑さの吸収
信頼性確保
開発時間/学習時間の提供
Zero complexity. Zero overhead. Zero obstacles.
9
“Reliable”, ”Simple”, “Rapid”:
REST + Script

信頼性：絞り込まれた指針に基づく、世界中の経験が事前担保



複雑性：絞り込まれた指針に基づき、システム設計者が個別吸収



URI設計、HTTP GET/POST,…
Project Zero : REST API, 規約,
第一回
第三回
迅速性：言語の動的特性に基づき、アプリケーション実装者が個別確保



Apache, PostgreSQL, ..
Project Zero : Java
Ruby, Python, Perl, PHP, Javascript, …
Project Zero : Groovy, PHP
第二回
複雑性の吸収/迅速性の確保:急速に経験蓄積中



ATOM Pub, Ruby on Rails..
Project Zero
個別  事前+個別
第四回
10
“Reliable”, ”Simple”, “Rapid”:
他のアプローチ
 JavaEE



信頼性：ベンダーの技術力が事前担保
複雑性：JCP参加者が、包括的な規格の策定で事前吸収
迅速性：ライブラリ実装者/アプリケーション実装者が事前確保（学習）


信頼性:OSSが進展中（事前担保主体の変化）
複雑性/迅速性：Ease of Developmentが進行中（対処時期の変化）
 JavaSE + DI +ORM, WS-*, .NET, COBOL + CICS,…

それぞれに、それぞれのバランス
 適材適所？・・量産効果？





しっかりとした足場を持っているものは？
適用エリアが広いものは？
現在、勢いがあるものは？
技術者／企業にとって、選択の余地は？
・・・何十年も、変わらないテーマ？
11
2. RESTとWebサービス
2-1. コンピュータ、ネットワークから離れた
“REpresentational State Transfer”
12
RESTとは？
 詳しく/正確には、Roy T Fieldingの博士論文を参照(参考文献1)
 Fielding, Roy Thomas. Architectural Styles and the Design of
Network-based Software Architectures. Doctoral dissertation,
University of California, Irvine, 2000.
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

7年前は、博士論文の主要テーマだった話
 以下は、解釈


「こう解釈して、今のところ困らない」
（著名な技術者間でも、まだ議論中）
13
RESTとは？
 ネットワーク・システム設計方針の一つ。べからず集
 「システムのスケーラビリティ(と柔軟性)を減じる手法によって、
他のメリットを得る」ことを、強く制限する
 「これでは、キャッシュが生きません。ダメです」
 「これでは、参加者が限られます。ダメです」
 べからず集を一定以上に守ると、何ができる？
 ”World Wide Web” (≒HTTP+URI+HTML)が、できた
 べからず集：参考文献１、第５章
 5.1 Deriving REST
14
”Deriving REST”
(http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)







5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
Starting with the Null Style
Client-Server
Stateless（スケーラビリティの主役）
Cache
Uniform Interface(柔軟性の主役)
Layered System
Code-On-Demand
15
RESTとは？
 Webを例としてRESTを理解する事は、難しい
 例としては、しがらみが多すぎます..
 ..後ほど
 Web以外に、適切な例はないか？
 ネットワークに限定しなければ、
「よく工夫されている、ありふれたシステム」
にも見える
 一例として、架空の「免許センター」を分析
16
REST的な側面を持つ例:
架空免許センター
 多数の申請者に、免許更新サービスを提供する
 「書類交換に基づくワークフローの大量処理」の典型
免許渡し1
免許渡し2
印紙提出
印紙販売
申請書記入
カウンター
c
運動
視力
写真
17
架空免許センターの特徴(1/3)：
多数の申請者に免許更新サービスを提供する、ノウハウ
 架空免許センター：
URI,Hyperlink,Form,..
 特定処理のみを担当する窓口が多数用意され、
内部を申請者が頻繁に移動する、サイト
 比較例：一つの窓口で複数の処理を行う、なら？
 窓口：
URI,Uniform Interface,..
 基本的な会話と書類授受のみを行う場所
 比較例：申請者が自分で視力測定する窓口、なら？写真は？
 申請者の移動：
URI,Hyperlink,Form,..
 窓口が移動先を指示(「次は、視力検査です」)
 比較例：申請者が事前に手順書を熟読して把握する、なら？
18
＊黄色は、関連するREST又はWebの用語
架空免許センターの特徴(2/3)：
多数の申請者に免許更新サービスを提供する、ノウハウ
Hypermedia, self-descriptive message,..
 書類
 文字/写真/印紙等を含むもの、一つだけを使用（+旧免許)
 比較例：窓口ごとに別の書類を用い、申請者に戻さない
(Stateless Server)
 書類の管理
 申請者が保持する
 比較例：書類を窓口で預かる
 次の窓口に事前に回す
 預かった書類に基づき、次の窓口を申請者専用として新規に開く
 進捗把握
Stateless Server,URI,hyperlink,Form,..
 申請者が把握する
 書類を受け取った時点で、窓口も(必要なら)判断可能
 比較例：窓口間で連携をとり、窓口で進捗を常時把握する
19
＊黄色は、関連するREST又はWebの用語
架空免許センターの特徴(3/3)：
多数の申請者に免許更新サービスを提供する、ノウハウ
 最終的に伝達する情報
 申請者の状態を(一部)表現した、申請書
 視力、体力、写真、現在の免許、・・
 架空免許センターの状態を(一部)表現した免許証
 免許条件、有効期間、点数・・
 REpresentational State Transfer
申請者の運転能力に関する状態が、
架空免許センターに転送され、架空免
許センターの状態の一部となる
滑空免許センターで設定/保管されて
いる状態が申請者に転送され、申請
者の状態の一部となる
20
＊黄色は、関連するREST又はWebの用語
架空免許センターの特徴+ネットワーク(1/2)
 免許センター的なシステムでは、コンピュータ・ネットワークによって
 集客範囲が、劇的に広がる
Web “1.0”
 世界中の申請者にサービスを提供
 処理能力が、劇的に向上する
Web “1.0”
 窓口の動的追加が容易
 申請者専用の免許配布窓口を開き、案内
 センターの壁が、低くなる
Web “2.0”:Mash up
 写真は他のサービスから取得
 視力測定サービスを、免許から独立して世界に提供
 「・・・センター」の動的構成が、容易になる Web “2.0”:
 免許、旅行、会計、・・・
Situational Application
21
架空免許センターの特徴+ネットワーク(2/2)
 免許センター的なシステムは、コンピュータ・ネットワークによっ
て、壁の存在を前提にできなくなる
 窓口間の共通認識が、なくなる
 認可, ユーザー登録の方法
 取り消し処理
 ・・・
 壁の存在を、無意識に前提としていないか？
 トラブル発生時など
 議論、実験中
 WS-*, Grid, REST, ATOM/WADL,..
 窓口が知っておくべき事前合意事項を、大幅に増やす？
 これ以上の事前合意は、あてにしないで作りこむ？
 少しだけ、追加する？
22
架空免許センターは、“Reliable, Simple, Rapid”か？
REST+Scriptとの比較

信頼性：絞り込まれた指針に基づく、世界中の経験が事前担保



URI設計、HTTP GET/POST,…
Project Zero : REST API, 規約,
××センターの設計(窓口の配置,..)
迅速性：言語の動的特性に基づき、アプリケーション実装者が個別確保



窓口の基礎（会話、読み書き,..)
複雑性：絞り込まれた指針に基づき、システム設計者が個別吸収



Apache, PostgreSQL, ..
Project Zero : Java
Ruby, Python, Perl, PHP, Javascript, …
Project Zero : Groovy, PHP
窓口の詳細（会話の処理、次の指示,..)
複雑性の吸収/迅速性の確保:急速に経験蓄積中



ATOM Pub, Ruby on Rails..
Project Zero
「××センター」の雛形
個別  事前+個別
23
架空免許センターと、”Deriving REST”
(http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)
 5.1.1 Starting with the Null Style
 5.1.2 Client-Server
 申請者-窓口
 5.1.3 Stateless（スケーラビリティの主役）
 申請者による進捗把握
 5.1.4 Cache
 ・・写真撮影コーナーに、Expireしていない写真があれば・・
 5.1.5 Uniform Interface(柔軟性の主役)
 「窓口」+(見ればわかる書類の授受+基本会話)+次の指示
 5.1.6 Layered System
 5.1.7 Code-On-Demand
24
架空免許センターとREST, まとめ

××処理を行うRESTfulなWebシステムの構築 ≒××センターの構築

窓口の特性を理解する


××センターを複数の窓口に分解する



Hypermedia, content-type, status-code, Uniform Interface,..
窓口の詳細を実装する
××センターは、ネットワークのメリットを多数享受できる


Hyperlink, Form, status-code, URI, ..
窓口と利用者で授受される書類を設計する


URI,..
窓口の配置(動的開設)、及び利用者の動線を設計する


Uniform Interface, stateless-server, URI,..…
注意事項も、ある
・・コンピュータ、ネットワークの話へ
25
2. RESTとWebサービス
2-2. コンピュータ、ネットワークにおけるREST
26
分散システム, REST, HTTP, 2007年のWeb(サービス)
論点の整理
エリア2
分散システム
RESTに基づくシステム
免許センター
RESTに基づかないシステム
ホテルのフロント,行きつけの店..
基本会話
窓口(名) 申請書類
HTTP + URI + Hypermedia
PUT
link GET
現実のWeb(サービス）
POST（の使いすぎ)  SOAP/WSDL/WS-*
Status codes Content negotiation
Header fields
エリア3
激論
(X)HTML Form
RPC
Session State (Server side)
Cookie(の典型的な使用法)
DELETE
エリア１
27
補足：HTTP Method, Status code, Header:
Uniform Interfaceの詳細

HTTP/1.1: Methods (*2)










9.1 Safe and Idempotent
Methods
9.2 OPTIONS
9.3 GET
9.4 HEAD
9.5 POST
9.6 PUT
9.7 DELETE
9.8 TRACE
9.9 CONNECT
HTTP/1.1: Header Fieldsの一部(*4)













HTTP/1.1: Status Codes (*3)





10.1
10.2
10.3
10.4
10.5
Informational 1xx
Successful 2xx
Redirection 3xx
Client Error 4xx
Server Error 5xx
14.1 Accept
14.2 Accept-Charset
14.8 Authorization
14.9 Cache-Control
14.17 Content-Type
14.19 ETag
14.21 Expires
14.25 If-Modified-Since
14.30 Location
14.36 Referer
14.43 User-Agent
14.47 WWW-Authenticate
Method + Header + Representation
クライアント
サーバー
(URI)
Status code + Header + Representation
28
part of Hypertext Transfer Protocol -- HTTP/1.1 RFC 2616 Fielding, et al.
RESTとWebサービス「論」、個人的見解

エリア１：広く活用されている”REST”. 「Webで、便利になった」



エリア２：活用がそれほど進んでいない”REST”. 「Webは、もっと使える」



象徴：IE/FireFox + Apache / IIS + …
さらなる活用も、活発に議論されている
象徴：ATOM Pub。
見直され/注目され始めている
分散システム
RESTに基づくシステム
エリア３・・・激論

3
現実のWeb(サービス）
激論
３－２．今後の見通し
1
便利になる？／混乱する？

RESTに基づかない
システム
HTTP + URI + Hypermedia
３－１．これまでの功罪
便利になった？／役に立っていない？
効果を限定的にした？

2
以上を踏まえて・・世界中で議論中  実証実験へ
エリア１で現在（一般には）カバーされていない領域まで、Webで解決するには？



エリア１の発展 + エリア２？
エリア３？
・・両方？そもそも、Webで解決するメリットは？…
29
エリア3：現実のWeb(サービス)、非REST的
側面に関する「激論」,個人的分析
 肯定側 : 有用である + 仕方ない ( + 無意識)
 Message Exchange Patternは、様々だ
 アプリケーションの状態管理を全部クライアントで行うのは大変だ
 「読めばわかるメッセージ」「メタデータはURIに」では、不足
 世の中、HTTPしか通してくれない
 HTTPの資産を利用しないのは、現実的ではない
 気づいたら、REST的でないシステムになっていた
 …Webの発展/補完
 否定側 : “Web”にとって、マイナスである
 ブックマークできないページの氾濫
 SOAP/WSDL/WS-＊の複雑さ
 …Webの乱用
30
補足：激論エリアに関するRoy T Fieldingの発言等

「そんなつもりで、作ってない」？


Chapter 6, Experience and Evaluation (*1)

6.3.4.2 Cookies


6.5.2 HTTP is not RPC
6.5.3 HTTP is not a Transport Protocol
W3C Technical Architecture Group のMLより(*5)


..Cookie interaction fails to match REST's model of application state,..
The only reason SOAP remains in the W3C for standardization is
… If this thing is going to be called Web Services, then I insist
that it actually have something to do with the Web. ..
SOAP/WSDL/WS-＊は、一旦”Web”と切り離して、後ほど議論

RPCとして始まり、HTTPをTransport Protocolとして使い、サーバー側での
application state管理も含む技術体系

これらは全て、SOAP/WSDL/WS-*の世界でも、是非が議論されている
31
分散システムのスケーラビリティと、
エリア１～３
Wiki
一般的なWeb
Mobile
Multimedia
Web 2.0
サーバー主導
クライアント主導
少量単位・複雑データ
大量単位・単純データ
分散システム
データ集積目的
データ配布目的
複雑な信頼関係
単純な信頼関係
RESTの適性
一般的な
企業システム
スケーラビリティ=大
エリア(1),3
1990年代後半～:
Webの企業システム適用努力、含む非REST化
スケーラビリティから：
関連技術,理解の進展
2000年代前半～:周辺技術/経験の
増強に基づくRESTful Webの発展
2000年代中盤～:ハード/ネットワーク環境
変化に適合したシステム設計手法？
エリア(1),2
32
REST周辺技術の進展と
企業システムへの要請変化
双方に注目
スケーラビリティへ：
システムへの要請変化
分散システムの柔軟性と、エリア１～３
システムの使用方法詳細決定時期を
先送りし、多くの用途に対応させる
クライアント
アプリケーション・プロトコル
アプリケーション
分散
システム
(動的)リソース
ミドルウェア
ソフトウェア
RESTの関心領域
標準規格
エリア 1,2
OS
システム
ハードウェア
“アーキテクチャ（スタイル)”の時代?
“標準”の時代
“汎用” の時代
詳細決定先送り
～2000～
～1970
2006～
システム・プロトコル？
専用的要素
汎用的要素
用途に直結
先に製造
ソフトウェア・プロトコル？
接続要素
33
エリア3
Webのプロトコル・スタックと、エリア1～3
更新、通知、カーネル構造体（相当）・・・
WS-*
エリア3(の一部)
エリア 1,2
構造体、文書
WSDL
これ
“Content-type”
（表現、略称）
画面 {変数名=値} 文書
(xhtml) x-www-form.. xml
お願い
あなた
メッセージ構造体更新、通知その
json
atom (rss) 他
soap
返事
HTTP /URI
文字列(実体/参照,*注) Content-type, charset, …に関与
バイト列
ビット列
TCP/IP
Network byte orderに関与
Ethernet
その
他
その
他
その
他
Ethernet orderに関与
34
(*注)文字列:クライアントにとって、意味のある表現
（これ／返事の表現形式は、一例）
Web service, SOA, REST
Web Services Architecture, W3C Working Group Note 11 February 2004(*6)より：
 Web serviceとは
 WSDL + SOAP + “Web-related standards”
 RESTとの関係で、Web serviceは２種類
 REST-compliant Web services
 arbitrary Web services
 Messageが重要(semantics and visibility)
 Uniform Interfaceより、メッセージの構造
35
Web serviceとは
Web Services Architecture, W3C Working Group Note 11 February 2004(*6)より：
 WSDL + SOAP + “Web-related standards”

1.4 What is a Web service?
For the purpose of this Working Group and this architecture,
and without prejudice toward other definitions, we will use
the following definition:
[Definition: A Web service is a software system designed to
support interoperable machine-to-machine interaction over
a network.
It has an interface described in a machineprocessable format (specifically WSDL).
Other systems interact with the Web service in a manner
prescribed by its description
using SOAP messages,
typically conveyed using HTTP with an XML serialization
in conjunction with other Web-related standards.]
36
SOAとWeb, REST
Web Services Architecture, W3C Working Group Note 11 February 2004(*6)より：


REST-compliant Web services と、arbitrary Web services
3 Stakeholder's Perspectives
3.1 Service Oriented Architecture
3.1.3 Relationship to the World Wide Web and REST Architectures
The World Wide Web operates as a networked information system that imposes
several constraints:..
An even more constrained architectural style for reliable Web applications
known as Representation State Transfer (REST) has been proposed by Roy
Fielding and …
The REST Web is the subset of the WWW
分散システム
2
(based on HTTP) in which …
RESTに基づく
RESTに基づかない
HTTP + URI + Hypermedia
3
現実のWeb(サービス）
激論
1

……
We can identify two major classes of Web services:

REST-compliant Web services, in which the primary purpose of the
service is to manipulate XML representations of Web resources using a
uniform set of "stateless" operations; and

arbitrary Web services, in which the service may expose an arbitrary set
of operations.
37
Message semantics and visibility
Web Services Architecture, W3C Working Group Note 11 February 2004(*6)より：
 Uniform Interfaceより、メッセージの構造

3.5 Web Service Semantics
3.5.1 Message semantics and visibility
…The emphasis on messages, rather than on the actions that are caused by
messages, means that SOAs have good visibility: …This, in turn, means that
intermediaries, such as firewalls, are in a better situation for performing their
functions….
In REST-compliant SOAs, additional visibility comes from the uniform interface
semantics, essentially those of the HTTP protocol: an intermediary can
inspect…. .. and firewalls, proxies, caches, etc. are almost universal today.
Visibility, however, goes beyond firewalls. In this architecture, instead of
emphasising a REST-style uniform interface, we emphasize messages'
structure in terms of envelopes, headers and bodies. We enhance
visibility architecturally by fostering agreements on particular forms of headers.
For example, by having well-known standards that describe the form and
interpretation of authentication tokens in headers, we can simultaneously
reduce the cost of performing authentication and increase the overall visiblity of
the message's semantics: if the authentication aspect of a message can be
specified in a standard way then it is easier for a larger number of interested
parties to process the message. Furthermore, increased visibility can reduce
the cost of entry into a marketplace.
38
2007年の、SOAP/WSDL/WS-＊(1/2):
“REST-compliant Web services”的方向
 基礎部分に、RESTと矛盾しない方向への変化が見られる
 SOAP 1.2 + WSDL 2.0 (+ WS-Addressing)
 脱RPC, GETの活用、HTTP Binding, …
 “Web”のメリットも享受できる体系へ
 上位規格で、REST的な発想を感じるものも多い
 (WS-Addressing)
 WS-Transfer, WS-Resource, WS-ResourceTransfer, ..
 SOAP/WSDLの著名技術者による、SOAP/WSDLを使わないエ
リアでの活動が、目立つようになった
39
2007年の、SOAP/WSDL/WS-＊(2/2):
“arbitrary Web services”的方向

「超広域分散コンピューティングは、REST以外で成立し得ない」か？






「非広域分散で一般的な手法を、広域分散環境でも、インフラに任せて実現
できないか？」



UniformではないInterface
Client-Server以外
Application Stateをサーバーで管理
・・・
“Web”との比較に耐えるレベルで「成立させた」と言える例は、把握していない
Transaction, Reliable Messaging, ..
「SOAP/WSDLを使用しない広域分散コンピューティング」に、先行
非広域分散でも先鋭的な手法を、広域分散で手軽に実現できないか（始め
から、広域分散を考慮に入れて構築できないか）？

Open Grid Services Architecture


WS-*の集合
策定作業実施中
40
3. スクリプト言語とWebアプリケーション
今、なぜ、#! ?
41
「スクリプト言語」とは？
 “#!” , 明示的なコンパイルが不要な言語, …
 Shell, Ruby, Python, Perl, PHP, Groovy, JavaScript,..
 職業としては（なぜか）日陰の言語から、主流の一翼へ
 なぜ、「職業としては日陰の言語」だった？
 もともとメリットは多く、幅広く使われていた
 重要な部分に適用するには、欠点が許容範囲を超える
と見なされることが多かったと想像
 現在では、重要な部分まで”Web”化が進みつつある
 “2007年”,”Webシステム”における、スクリプト言語の欠点とは？
42
スクリプト言語、想定される（た）欠点の例：



基本的な言語仕様として、不足
 変数スコープ、データ構造、制御構造、参照、・・
実行速度が遅い

実行時に顕在化するエラーが多い
 事前の型チェックが弱い（ない)
読みやすい/にくいソースの差が、大きい

コードと設定の区別が不明瞭

コードを隠しにくい

実行結果に責任を持つ機関がない
 開発の継続性に責任を持つ機関もない
・・・
大規模開発/実システムには「耐えられない」
 小規模/プロトタイピングでは、以前から欠点が顕在化しにくかった。



 “2007年”、”Web”なら？
43
スクリプト言語、想定される（た）欠点の例：
”2007年””Web”では・・

解決/軽減/メリットへの転化・・


基本的な言語仕様として、不足
 （話題にもならない）
実行速度が遅い
 ボトルネックになる率が低下
 “2007年”のCPU, I/Oで、“Web”
実行時に顕在化するエラーが多い
 開発方法論が進化、一般化
 “2007年”の開発/テスト環境
読みやすい/にくいソースの差
 （質問）
コードと設定の区別が不明瞭
 むしろ流行
コードを隠しにくい
 むしろ流行
 + 納品物の変化？
2007年、”Web”… Software As A Service?
責任を持つ機関がない
 （質問）
大規模開発/実システムには「耐えられない」  事例での言及が増加






44
「読みやすい/にくいソースの差が、大きい」でしょうか？
 「スクリプト言語」とまとめることは、おそらく不適当
 同じ言語でも、時代によって、おそらく異なる
 職業としての慣れ、学生時代の慣れ、開発環境の差異・・
 どう感じるでしょうか？
 “1990年代後半”, “Web”, “Perl(4)”なら、その通りでしたが・・
 “2007年”, “Web”, “Ruby (on Rails)/Python/Perl”なら？
 “2007年”, “Web”, “PHP/Groovy”では？
 + Javaとの連携、では？
45
責任を持つ機関がない、でしょうか？
もしないのであれば、その影響は？

1. 企業が開発／提供する方が安心？


2. 開発に深く関与する企業の存在が重要？


Groovy (JSR241)
(Python Enhancement Proposals, RubySpec Wiki, ..)
(参考：gcc)
4. 1,2,3が無くても、広く活用されていることが重要？ ( いずれ 3,2 へ？)



PHP, (J, Iron)Ruby, (Iron)Python , ..
3. 規格の明示が重要？




商用UNIXに含まれるShell, JScript, …
Perl、(少し前までの)Python/Ruby
「サポートする機関」は、存在する場合が多い
5. 言語開発者の顔が見えることが重要？

多くの著名スクリプト言語

6. オープンソースであれば、自分で確認/修正/維持可能？

どうお考えでしょうか？
46
スクリプト言語の長所
 テキスト処理の簡便さ/強力さ
 動的型付け
 コンパイル不要
 Web情報の豊富さ
 （言語仕様の充実）
…
 事前準備が少ない状態での、開発速度向上
 “2007年”,”Web”においては、大きなメリット
47
スクリプト言語 + 他の言語 + Web

方向として、新しいものではない





“Web”を実装している言語と、スクリプトの連携





Unix (Pipe + Shell + C)
Perl + C +(Apache + mod_perl)
Visual Basic + Visual C++,
…
1990’s : Perl + C (httpd)
(2000 : JSP + Java (Servlet))
2010
: JRuby/Jython/Groovy + Java(Servlet) ?
…
今作っているものは、アプリケーション？インフラの拡張？

アプリケーションなら、人間との親和性が、より重要


インフラの拡張なら、コンピュータとの親和性が、より重要


「スクリプト」
メモリー、バス、ストレージ・・
…差が不明瞭/両方であることも、多いのではないでしょうか？
48
[再掲]“Reliable”, ”Simple”, “Rapid”:
REST + Script

信頼性：絞り込まれた指針に基づく、世界中の経験が事前担保



複雑性：絞り込まれた指針に基づき、システム設計者が個別吸収



URI設計、HTTP GET/POST,…
Project Zero : REST API, 規約,
第一回
第三回
迅速性：言語の動的特性に基づき、アプリケーション実装者が個別確保



Apache, PostgreSQL, ..
Project Zero : Java
Ruby, Python, Perl, PHP, Javascript, …
Project Zero : Groovy, PHP
第二回
複雑性の吸収/迅速性の確保:急速に経験蓄積中



ATOM Pub, Ruby on Rails..
Project Zero
個別  事前+個別
第四回
49
4. Project Zero First Look
4.1 Project Zero 概要
50
Project Zeroとは？
 「シンプル」かつ「パワフル」な、
Webアプリケーションプラットフォーム
 過去のしがらみからの脱却
 ≠JavaEE、≠コンテナモデル
 スクリプト言語(Groovy/PHP)で開発
 Web2.0的用途に特化
 アーキテクチャをゼロから再構築
 オープンな環境化での商用製品開発
 Community Driven Commercial Development
51
Zeroの対象領域:
Situational Applications
 アプリケーションの特性
Enterprise Application Long-tail
52
Mission Critical
Built to Last
 迅速な投入が重要
 Tomcat,LAMP,RoRが使
われることが多い
 Web-oriented
Architecture
 スクリプティング中心
 ファイル単位のデプロイ
 セキュリティとスケーラビリ
ティにWebの特性を活用
Tomcat
LAMP
Situational Applications
Applications
Zeroのtarget
Project Zeroの経緯
 2006/7 IBM社内のインキュベーションプロ
ジェクトとしてスタート
 2007/6 プロジェクト公開
http://www.projectzero.org/
 2007/8 ソースコード公開
 2007/9/14 Milestone1リリース
53
CDCD(Community Driven
Commercial Development)
 プロダクト開発におけるIBMの新しい試みの一つ
 従来のスタイルとOSS的スタイルのレバレッジ
 オープンな開発プロセス（ソースコード、情報、・・・）
 プロダクトに対する保証（Fix提供、サポート、・・・）
CDCDは ”California Pizza Kitchen”(*注)だ。お客様は、IBMが自分の欲しいものをCookしてく
れるかいつでも見る事ができるし、自分の好みと違えば注文をつけることができる。クローズドな環境
で作る製品よりも、よりお客様のニーズに見合った商品を提供できる、新しい試みだ。
- Message from Jerry Cuomo (*注)USでチェーン展開している人気のピザ屋で、ガラス張りのキッチンの中で、注文してからピザをcookしてくれる
We want to build stronger ties to our customers and users, so we're providing a
panoramic view of the development process for Project Zero. With regular
milestones throughout the development of a release, users get the opportunity to
see what’s coming, provide feedback, and help set priorities.
- From “Project Zero FAQ” 54
Project Zero Community Site
•誰でも利用可能（一部コンテンツはユーザー登録が必要）
•プロジェクトの全情報はここでやり取りされている
 ディスカッション
 ニュース
 ドキュメント
 ダウンロード
 デモ/チュートリアル
 JIRA
 開発者Blog
55
Project Zeroの特徴
 開発: シンプルなプログラミングモデル




規約によるシンプル化 (Convention over Configuration)
スクリプティング(PHP,Groovy) ⇒ Javaはシステム言語
RESTfulスタイル
高機能な拡張モジュール例）RSS/ATOMサポート
 アセンブリ: サービス組み立てをシンプルに


FlowとFilterによる構造化
REST/RSS/ATOMマッシュアップ用のビジュアルエディタとAPI
 実行: コンパクトな”New Reality” Runtime



アプリケーション毎にコンパクトなJavaVMを起動
数百のアプリケーションを実行可能 ⇒スケーラビリティ、リスク分散
スレッドモデルからプロセスモデルへの回帰
56
開発
 Eclipse plug-inとCLIを提供
 モジュール化
 コアは小さく、拡張機能はextension moduleで
 依存関係を自動的に解決
 シンプルな規約：コードと設定を削減
 RESTful： URIによるリソースCRUD
 スクリプトとテンプレート
 PHP, Groovy
 全てのステートはメモリ(Global Context)に記録
 ステートレス、イベントドリブンアーキテクチャ
57
アーキテクチャ概要
employees.groovy
GET
/resources/employees
Event Engine
Client
(Event)
List
onList()
Resource
Resolver
(Data)
Global
Context
(Event)
Render
(Data)
View
Engine
JSON / XML / HTML
onList(){}
onRetrieve{}
onCreate{}
・・・
template.gt
render()
58
規約: ディレクトリ構造
/app
/resources
リソースハンドラー
<resource名.groovy>
/views
Viewレンダラー
<.gt or .groovy>
/errors
Errorハンドラー
/config ivy.xml
依存関係の管理
zero.config
各種設定
/java
Javaソース
/public
ドキュメントルート
http://www.projectzero.org/wiki/bin/view/Documentation/CoreDevelopersGuideApplicationLayout
59
規約: RESTful Resources
File: /app/resources/people.groovy
HTTP
URI
Method
Event data
GET
/resources/people
onList()
GET
/resources/people/1
onRetrieve()
POST
/resources/people
onCreate()
PUT
/resources/people/1
onUpdate()
request.params.pe
opleId[0] == 1
DELETE
/resources/people/1
onDelete()
request.params.pe
opleId[0] == 1
request.params.pe
opleId[0] == 1
http://www.projectzero.org/wiki/bin/view/Documentation/CoreDevelopersGuideREST
60
依存関係管理


依存関係管理用のGUIを提供(Eclipse plug-in)
Ivyによる依存関係の自動的解決



必要なコンポーネントを自動的にダウンロード
ローカルにキャッシュを保持
mavenリポジトリも利用可能
61
アセンブリ
 RESTサービスを接続して新しいサービスを作成
 コードレス・マッシュアップ
 迅速な開発
 FeedやRESTfulサービスを組合せ可能
 パイプライン中でソートやフィルタ処理などが可能
 ルーティング、ロギング、データ変換
 テンプレートを提供
 拡張可能
 Flow Editor(GUI)を提供
 Webアプリケーション
62
Flow Editor
デフォルト
アクティビティ
カスタム
アクティビティ
メディエーション
63
Mediation
 簡易ESB的な機能を提供
 ルーティング、ロギング、プロトコル変換
 拡張可能、組合せ可能
Mediation
Step
Request
Request
Req
Req
Yes
Yes
Res
Failover
Response
Response
No
No
64
Retry
Res
External
Resourse
Zero
Application
Step
実行

New Reality Runtime (NRR)



スクリプト言語的な動作のJavaVM（IBM J9の派生版)
PHPとJavaをサポート
省資源


 lazy activationをサポート
クリーン




アプリケーション=サーバー
アプリケーションは互いに独立でセキュア
定期的な再起動でリソースリークなどの問題を削減
軽快


数百のアプリケーションを実行可能
高速に起動 ⇒ 開発サイクルを短縮
QoSと運用管理の外部化


Zeroのランタイムはシングルサーバー
クラスタリング(ワークロード管理、データ共有）は別製品で
65
4. Project Zero First Look
4.2 インストール
66
前提条件
Windows or Linux
Java SE Development Kit 5.0
Eclipse SDK 3.2.2 or later
コマンドライン版もあり
詳細情報
http://www.projectzero.org/wiki/bin/view/Documentation
/CoreGettingStarted
67
インストール手順（１）
 Eclipse Zeroプラグインのアップデートサイトを追加
 Help -> Software Updates -> Fiand and Install …
 「Search for new features to install」を選択し、Next
 「New Remote Site …」をクリック
 以下の通り入力する
Name : Project Zero Update Site（任意）
URL :
http://www.projectzero.org/update/zero.eclipse.latest
 Finishをクリック
68
インストール手順（２）
 Zeroプラグインのインス
トール
 Help -> Software
Updates -> Find and
Install …
 「Search for new
features to install」を
選択し、Next
 「Project Zero Update
Siteにチェックを入れ、
Finish
69
インストール手順（３）
 Zeroプラグインのインス
トール
 プラグインにチェックを入
れ、Nextをクリック
70
インストール手順（４）
 Zeroプラグインのインス
トール
 ライセンスアグリーメント
に同意し、Next
 Finishをクリック
 Install Allをクリック
 Eclipseの再起動を要求
されたらYesをクリック
71
アプリケーション作成と実行
File -> New -> Project ....
Zero -> Project Zero Applicationを選択し、Nextをクリック
アプリケーション名を入力し、Finishをクリック
プロジェクト(Zeroアイコン付き)が作成される
プロジェクトを右クリック
Run As -> Project Zero Application
コンソールに”running on port 8080“というメッセージが表示さ
れれば起動完了
 ブラウザのURLに http://localhost:8080/ を入力すると、アプ
リケーションのデフォルトページが表示される（次ページ）
 アプリケーション停止はコンソールビューの停止ボタンで







72
動作確認
 アプリケーションの
デフォルトページ⇒
73
設定情報の確認
 リクエストの詳細情報を
参照可能
http://localhost:8080/
zero/webtools/snoop.g
t
 このように表示される⇒
74
サンプルの実行
 「Project Zero Examples」プラグインをインストールしておく
 File -> New -> Example ....
 Zero Examples -> Project Zero Example Projects を選択
し、Nextをクリック
 アプリケーションを選択し、Finishをクリック
 プロジェクト(Zeroアイコン付き)が作成される
 実行方法はプロジェクト内のREADME.txtなどを参照
75
参考文献
1. Fielding, Roy Thomas. Architectural Styles and the Design of
Network-based Software Architectures. Doctoral
dissertation, University of California, Irvine, 2000.
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
2. HTTP/1.1:Method Definitions, part of Hypertext Transfer
Protocol -- HTTP/1.1 RFC2616 Fielding, et al.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
3. HTTP/1.1:Status Code Definitions, part of Hypertext Transfer
Protocol -- HTTP/1.1 RFC2616 Fielding, et al.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
4. HTTP/1.1:Header Field Definitions, part of Hypertext
Transfer Protocol -- HTTP/1.1 RFC2616 Fielding, et al.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
5. Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)
http://lists.w3.org/Archives/Public/wwwtag/2002Apr/0235.html
76
参考文献
6. Web Services Architecture, W3C Working Group Note 11 February 2004,
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability,
trademark, document use and software licensing rules apply.
Status of this Document
This section describes the status of this document at the time of its publication. Other
documents may supersede this document. A list of current W3C publications and the
latest revision of this technical report can be found in the W3C technical reports index
at http://www.w3.org/TR/.
This is a public Working Group Note produced by the W3C Web Services Architecture
Working Group, which is part of the W3C Web Services Activity. This publication as a
Working Group Note coincides with the end of the Working Group's charter period, and
represents the culmination of the group's work.
Discussion of this document is invited on the public mailing list [email protected]
(public archives). A list of remaining open issues is included in 4 Conclusions.
Patent disclosures relevant to this specification may be found on the Working Group's
patent disclosure page.
Publication as a Working Group Note does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or obsoleted by
other documents at any time. It is inappropriate to cite this document as other than
work in progress. Other documents may supersede this document.
77

Download Report