InfoQ: Web開発者が知っておくべき八つの分離レベル
原文(投稿日：2009/3/15)へのリンク ACID特性はデータベース論の基礎の一つです。ACIDではデータベースの信頼性を保つために必要とされる4つの属性を定義しています。原子性(Atomicity)、一貫性(Consistency)、分離性(Isolation)、そして永続性(Durability)です。4つの属性はいずれも重要ですが、とりわけ分離性については最も柔軟に解釈されています。ほとんどのデータベースがいくつかの分離レベルを選択できるようにしていますし、最近は多くのライブラリがより極め細やかな分離レベルを作成するレイヤを追加しています。このように広範囲の分離レベルが存在している主な原因は、緩い分離レベルによって拡張性や性能が数桁のオーダーで異なることにつながるからである。 シリアライズ可能というのは最も古典的で高い分離レベルであり、一般的に使うことが出来るもので、多くの人がそ
討論: SOAは死滅したのか？
Anne Thomas Manes氏はSOAは死滅したという内容の記事 (リンク)を書いているが、その中で次のように言っている。 SOAは2009年1月1日に終焉を迎え、景気後退の悲劇的な影響を受けて絶滅しました。SOAを打ち負かし、生存競争に生き残ったのはSOAの子孫です。具体的に言うと、マッシュアップ、BPM、SaaS、クラウドコンピューティングをはじめとする、「サービス」に依存するすべての構造的アプローチです。 この記事で、同氏は次のように続けている。 SOAはかつてITの救世主と考えられていましたが、少なくともほとんどの組織にとっては、「大失敗に終わった実験」でした。SOAによって大幅なコスト削減と敏捷性の向上が実現すると考えられていました。ごくまれなケースを除いて、SOAはこの公約のメリットを実現することができませんでした。数百万ドルを投じても、ITシステムはまったく向上していま
RESTアンチパターン
多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基本的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では
ルール VS 手続き型コード
BPM ベースのソリューションにおいて、どういう時にルールを利用し、どういう時に手続き型のコードを利用するのが適切か、あなたはどうやって決めているだろうか？最近、haley.com(サイト・英語)の創設者であり会長でもある Paul Haley(source)氏がこの問題に関してヘルプを求められた(source)ようである。 最近、エンタープライズアーキテクチャグループ内の一部の戦略的な人たちから、ルールをもっと自分たちの組織に関連付けたいと依頼があった。ルールをどう いう時に中間レイヤに組み込み、どういう時にサービス内にカプセル化するのかということから、理想的な利用事例と参照実装まで、彼らの関心は多岐にわたっ ていた。そして、ルールを BPM および BI と結びつけることに特に興味を抱いていた。 従来の IT の考え方は BPM の乱用をまねく手続き型のコーディングに偏っていると Pa
REST入門
第2版（2008年1月19日）：翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。本稿では、本筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に
RDBMSでは不十分
リレーショナルデータベースはクライアント/サーバモデルに適合するものの、サービスの世界では新しいソリューションが必要である(source)。RDBMSはスケーラビリティの問題に陥りやすい。冗長性や並列性をどのようにして実現すればいいのか(source)？ （リレーショナルデータベースは）単一故障点となります。特に複製はささいな事ではありません。疑問に思うのであれば、全く同じデータを必要とする2つのデータベースサーバがあることによって起こる問題を考えて見てください。データを読んだり書いたりするために両方のサーバがあると、同時に変更するのが困難になります。マスターサーバとスレーブサーバがあっても、良くありません。なぜなら、マスターはユーザが情報を書き込む際、沢山の熱を帯びるからです。 また、Assaf Arkin氏も整合性を書くこと(source)はRDBMSが自身の重さで内破してしまう理由で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Adobe社、Flashプラットフォームで使用しているリアル・タイム・メッセージング・プロトコル(RTMP)の仕様を近く公表予定
企業とSaaSの仮想化がもたらすのは、迅速性（アップ）だけではない
BlazeDSとAMFでWebとデスクトップのアプリケーションを構築する
勢いをつける OAuth
Microsoftが主張：Atom Publishing ProtocolがWeb APIの今後の方向性を決定付ける