GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Mark Little , 翻訳者 八角研究所 投稿日 2008年4月11日
業種を問わず、すぐれたアーキテクトはずっと前から機能を再利用可能なサービスとして提供してきた。このことは、サービス指向アーキテクチャが長い時間をかけてどのように進化してきたのかを私に考えさせてくれた。我々のようにSOAツールの機能拡張に取り組んできた者は、この数年でSOAをポピュラーなものとした"Web サービス"よりはるかに長い間、サービスやSOAが身の周りに存在していたことを知っている。そして今、ソフトウェア業界では、サービス指向の実装が成熟期を迎えているようである。Kirstan氏はときとしてSOAはWebサービスとかかわりを持ちすぎている(source)という考え方に同調している(source)。彼は、まだSOAの全てのポテンシャルを引き出せていないと信じており、またそれには時間を要すると考えている。
伝統的な1年から1年半の開発サイクルを持つ開発では、大勢のアナリストや開発者を要するが、それらはあたらしいプロセスのフローグラフを描くビジネスアナリスト置き換えられ、そうすることにより enterprise-readyな環境へボタンをクリックすることでアプリケーションをデプロイできてしまうだろう。サービス指向的なアプローチであれば数日から数週間わずかなエンジニアリングリソースを使用するだけで済むはずだ。しかしながら、どこかで聞いたことがあるように(source) 、時々あなたのマイレージは変わってしまうかもしれないし(source)、SOAのプロジェクトはある種の万能薬のように自動的に成功するわけではない(source)。しかしKirstan氏によれば、これは世代的な問題で時間を経ることによりだんだん良くなる(もしくは何か新しい良いものが生まれる)とのことである。さらにKirstan氏によると、すでに四つの世代(もしくはそれ以上)のサービスベースのアーキテクチャが存在しているそうだ。:
第一世代サービス - WS-* や REST のようなモダンなSOAの標準な手法を使用していない、C、C++、C#やJavaといった第三世代のプログラミング言語によって書かれたシンプルなサービス群である。こういったサービスは、コンシューマと潜在的なリソースの依存関係が非常に強くなってしまう傾向にある。CORBA やDCOMといった比較的古い技術はこの世代に当てはまる。原文はこちらです:http://www.infoq.com/news/2008/04/soa-generations
第二世代サービス - データベースのデータを取得、修正、作成、削除したりするような、標準ベースのそれなりにシンプルなサービス群である。こういったサービスはJava やC#のクラスやEJB、データベースへ送信するクエリから自動生成することができる。これらのサービスはオブジェクトのメソッドをそのまま反映し、リレーショナルテーブルのような内部実装を外部にさらけ出してしまう傾向がある。開発は簡単だが、そのようなサービスはビジネス指向ではなく技術指向であるため、ビジネスプロセスで直接使用するのは非常に難しい。システムを編成するための適切なレベルの粒度で提供するためには、他の別のサービスやロジックと結合させる必要がある。
第三世代サービス - 本当の意味での「サービス指向」のサービス群である。このようなサービスはビジネスプロセスに適している。サービスのリクエストやレスポンスのペイロードといったデータフォーマットを明確に定義することによって疎結合が実現されている。これらのデータフォーマットは、実行パフォーマンスや必要なストレージの最適化をするような技術者ではなく、ビジネスプロセスをよく知るアナリストによって定義される。これらのサービスは、システムの編成に適した粗い粒度と疎結合を実現するために、第一世代と第二世代のサービスを縫い合わせて変形することで作られることが多い。
第四世代サービス - 第三世代のサービスを管理されたセキュアで再利用可能なサービスとして制度化したサービス群である。第四世代のSOAは、より高レベルのサービスやビジネスプロセスの構築や管理をするための、SOAを意識した技術や手続き等のエコシステムを持つ。第四世代のサービスを実現させるために時間をついやせば、企業はSOAの恩恵を最大限受けることになり、変化するビジネス的な要求を短い時間でビジネスプロセスに反映することができるようになるだろう。
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信