GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Dilip Krishnan , 翻訳者 金森 諭 投稿日 2009年6月30日
産業アナリストのNeil Ward-Dutton氏が書いた記事によると、ビジネスプロセス管理(BPM)とサービス指向アーキテクチャ(SOA)を組み合わせることは、理論的にいって相互補完的なものだという。この2つのコンセプトをどう組み合わせるかは意見が分かれるとこではあるが、いずれにしてもビジネスバリューを増大させるだけのシナジー(相乗効果)が両者の間にはあると氏は主張している。
BPMとSOAを一緒にすることがなぜ業界で相互補完的なものになるのかと考えられるようになったのか、氏はその理由を考察している。
1. 主要なソフトウェア製品でのBPELの採用。2004年から2005年にかけて、SOAの導入を望む顧客をターゲットにした新しいミドルウェア製品を売る企業は・・・(略)・・・複数の外部サービスも絡む何段階ものステップがあるロジックフローを処理し、Business Process Execution Language(BPEL)と呼ばれる標準を実装したフローエンジンを売り出しはじめました。そして「ビジネスプロセス」という言葉が濫用されたことで、多くの解説者がSOAの話とBPMの話を混ぜたり混同したりました。
2. 技術屋に製品をアピールし、業務リーダに売り込む方法を探し求めているソフトウェア会社。新しい技術に「BPM」という言葉をかぶせるのは、従来の技術屋に加えビジネス系のユーザにも製品を売るのにもってこいの策に思えたのです。
3. ウェブサービスを利用するBPM関連製品。スタートアップのソフトウェア企業のグループも新しいタイプのソフトウェアプラットフォームを売り出しました。それらのプラットフォームはBPMの導入に特化したもので、Business Process Management System(BPMS:ビジネス管理システム)と知られるようになりました。・・・(略)・・・SOAに対する関心は急激に広がりました。そして、既にあるバックエンドのアプリケーションやシステムやデータソースと新しい自動プロセスを統合する製品を顧客へ「オープン」にする方法として、新しい各種ウェブサービスプロトコルに便乗するのはこれらベンダーにとって自然なことだったのです。
氏は2つのコンセプトが見方の違いにすぎないと断じている。SOAはボトムアップ型の主にITによって推進される方法で、BPMはトップダウン型のビジネスによって推進される方法だという。そしてこの2つの方法のシナジーを活かすのに失敗する原因を、それぞれの推進役間で利害のすり合わせが行われないためだとする。
- BPMの実施において「統合サービス」を効果的に活用できないこと
- プロセスの再利用の可能性について十分考慮しないこと
- 情報アーキテクチャのもつ価値を活用できないこと。異なる環境にあるサービスを組み合わせる時には情報フローの変換がおこなわれます。SOA実装においては「共通情報モデル」を定義することはこの変換の量を最小限にする上できわめて重要なことです。
氏が推奨するのは、ビジネスプロセスやサービスをデザインするだけでなく、ビジネスアーキテクチャと技術アーキテクチャの両方について「サービスコンテキスト」を作成する方法だ。ビジネス側によってのみデザインされるサービスは、リソースや情報の再利用や効果的な利用において最適とはならないだろう。IT側によってのみデザインされるサービスも同様で、特にビジネスプロセスが組み合わさった状況に対してはあまり良くデザインされたものにはなってないだろう。
ビジネスアーキテクチャが推進役となるSOAにおいては、既存のアプリケーションやリソースをどうすれば効果的に再利用できるかを考えるだけではサービスのポートフォリオはできません。また、外部に対して配慮された高度なビジネスサービスも同じくらい重要です。さまざまな大きさ・抽象化レベルをカバーするサービスモデルは、このようなトップレベルのビジネスサービスの要件を噛み砕いて、組織やそのシステムのさまざまなレベルにおいて必要となるサービスの要件を気付かせてくれます。
氏は以前「結果がありきで、サービスやプロセスはふさわしい結果を成し遂げる上で表裏一体のものです」と書いている。同じように、BPMとSOAの推進役も見方を広げ、ITとビジネスの両方の要求を満たすように全体的なシステムデザインをすべきだと主張する。
BPMとSOAをどう組み合わせるかを考える時には、統合実現可能性の面だけを考えるようではいけません。BPMとSOAを見る視点をビジネスアーキテクチャという見方にまで広げるなら、より深い関係性とより大きな可能性が明らかになるでしょう。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
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
スレッド表示 返信