ウェブの原則とアーキテクチャ

@nsiena

開発・運用が多組織に散らばるような分散アプリは。単一プログラミングモデルとか参照透過性とかより、軽量インタフェースとか疎結合性とかの方が重要に違いない。依存性が強いほど、拡張・運用が困難になる。

@nsiena

加えて、重量級プロトコルスタックも向いてないように思える。それらは依存が密になるために。それが問題にならない領域では、多機能・高機能でいいかもしれないけれど。コンシューマサービス向きではなかろう。

中野賀通@オプスデータとハンズオン @nakano_guts

@nsiena:同感っ。RT @nsiena: 開発・運用が多組織に散らばるような分散アプリは。単一プログラミングモデルとか参照透過性とかより、軽量インタフェースとか疎結合性とかの方が重要に違いない。依存性が強いほど、拡張・運用が困難になる。

@nsiena

CORBA はモデルとしてはとても好きなのだけど。そういう点で、適用ドメインが限られてしまう。大WS は、ウェブ的でない上、スタックも複雑化して、機能的な点では CORBA の再現をしようとしているようにも見える。

@nsiena

一方で、RESTful WS は、ウェブ的 (REST, ROA) で、軽量インタフェースで、疎結合。だけど、機能的に簡素すぎるのは否めない。不足するところを、個別に対処していたりする。時には人が、時にはフレームワークが。

@nsiena

理解が浅いまま適当に作られる傾向があり。それに起因して、結合可能性の保証が低く、相互運用性に不安が残ってしまっているように感じる。

@nsiena

前承。ウェブ的には RESTful WS だろうと思う。個別技術以上に概念の理解が大切。

@nsiena

しかし。開発者を信頼し。開発者に任される点が多いがゆえに。更に、一見簡単に動くものが作れるがゆえに。概念の理解が軽視されやすく。取っ付きやすい個別技術的な実装方法や、時には、期待されないような技術の使い方などに話題になりやすい。

@nsiena

開発者の理解が不十分という場合もあるけれど。アーキテクチャ・標準技術方針が十分でなく、正当な作り方ができない/分かりにくいということも少なからず問題。

@nsiena

結果的に、似非 RWS が氾濫し、複雑なものは奇妙な作りにされてしまったりする。軽量インタフェース・疎結合の側に振りすぎている気がしている。何らかの形で、制約がもう少し強くても良いのかもしれない。

@nsiena

HTML5 で改善されるけれど。本質的改善というよりも、現状に対するパッチ的改善。ウェブアーキテクチャの概念的理解が伴わないと、ウェブ的でない作りを促進しかねない拡張でもある。開発者への依存度が高まる。

@nsiena

ウェブをアプリプラットホームとすることの限界をどうするか。ウェブとは違う、プログラムに適したプラットホームを作るのか。

紅月さん@がんばらない @koduki

@nsiena プラットフォームにするのはストレージの一般化が重要です

@nsiena

ウェブの経験から得た知見: 情報空間が分断されることは大きな損失。URI による指示可能性とインターネットワイドな接続性は重要。統一I/F (とステートレス性) は疎結合性のために重要。

@nsiena

疎結合すぎて問題になるようなアプリでは。これらを若干緩和したような、HTTP とは異なる性質のプロトコル上で実現される余地があってよい。URI での指示可能性はそれを許容している。なんらかの標準プロトコルが定着すればいい。HTML5 ファミリならば、Web Socket。

@nsiena

しかし、ウェブからエントリポイントへ到達可能であるというだけで。その実行過程で生成される内部状態は隠蔽され、到達後の操作を更に追加しなければ参照できなくなる。ウェブのリソースとしては参照できなくないのは、前述の通り損失。

@nsiena

Web Socket などで通信するアプリは、純粋なウェブとは違う世界に存在することを意識して。ウェブとのゲートウェイを用意するのが望ましい。つまるところ、有用な内部状態が HTTP でアクセス可能なリソースとして公開するべきなのだろう。

@nsiena

ここでいうウェブアーキテクチャは、古典的なそれなので。HTML5 ファミリで再定義される世界とはやや異なっているかもしれない。

きしだൠ(K1S) @kis

@nsiena この場合のウェブってHTTP？HTML？

@nsiena

@kis URI + HTTP ですね。リソースの主要な表現は、HTML 的な構造化文書というかハイパーテキストを想定してるです。

きしだൠ(K1S) @kis

@nsiena アプリケーション作る上で、HTTPもHTMLもラップ可能なので、そこまで問題にならないような気がするのだけど。

@nsiena

@kis ラップするのにうまくできなかったり、遠回りするような実現方法になってしまったりしていないですかね。Comet API みたいな使い方とか、Web Socket みたいなのが必要とされ歓迎されていたりする現状を見ると。

きしだൠ(K1S) @kis

@nsiena とりあえずGWTはうまくRPCできてると思います。IDEの助けがないとちょっと手間だけど、Javaを書くならそもそもIDEないと手間だし。

きしだൠ(K1S) @kis

@nsiena Cometとかの永続的な接続は、そこまで必要とされてない気がするし。

@nsiena

@kis URI で指示可能なリソースが相互接続されたハイパーテキスト空間。という元来のセマンティクスとはずいぶんとずれた作られ方のウェブアプリもしばしば見掛けるのも。プログラミング重視の作られ方とミスマッチが大きいのかな、という気もしてるかしらん。