SilverLightを使ったWorkflow-as-a-Service（サービスとしてのワークフロー）プラットフォーム

作者 Jean-Jacques Dubray , 翻訳者 編集部 投稿日 2009年3月15日

セクション

プロセス/プラクティス,

デベロップメント,

エンタープライズ・アーキテクチャ

トピック

RIA ,

Business Process Modeling ,

Architecture ,

Silverlight ,

SaaS ,

Business Process Management

タグ

Flash ,

Flex

SnapFlow(リンク)という新しいWorkflow-as-a-Service（サービスとしてのワークフロー）プラットフォームを、ベータプログラムとして先日リリースした。このプラットフォームはMicrosoftのスタック上に構築されているが、エンジニアリング担当副社長のGopinath Dhanakodi氏は次のように説明している(リンク)。

2008年にSnapFlowの構築を始めたとき、ビジネスレイヤにはC#を選び、バックエンドにはSQL Server 2005を選択しましたが、その前にflexも少し検討しました。 

SnapflowにFlashではなくSilverLightの使用を決めた際に考慮した要因は次のとおり。

• ビジネスロジックレイヤへの統合
• 構築に要する時間
• 学習曲線
• 専門知識
• デプロイメント
• 機能一式
• 顧客の導入度合い
• 費用

当初SnapFlowはFlashを選んだが、プロトタイプの開発に入って数週間が経つと、

はかどり具合にとても失望しました。ユーザーインターフェースは時代遅れの感じで、単純な変更にも時間がかかりました。

その時点でSilverLightを非常に細かく調査し、

開発者の大部分はUIの専門家ではないにもかかわらず、ひと月の内にチームは大前進を遂げました。何のサポートも受けずに、チームは学習し、かなり高度なプロトタイプを構築できました。  

長所は以下のとおり。

• チームは短時間でスピードをあげることができた
• フロントエンドの進行速度はFlashの２倍
• 時間ベースのアニメーション
• 全体的に統合された設計と開発環境

短所は以下のとおり。

• 問題が起こるたびに助けを求める
• Silverlightは高度な制御をあまり備えていなかった
• 自動化ツールのテストに対するサポートの欠如
• Silverlight 2ベータからSilverlight 2へ移行する際に予期せぬ問題が発生した

Dhanakodi氏は次のように結んでいる。

私たちは早い時期に導入したので、この分野にはつきものの標準的な課題の多数に直面しているわけです。全体的にみて、下した決断には非常に満足しており、Silverlightをお薦めしますし、.NETの専門知識を持っているなら、なおさらお薦めしたいです。

InfoQはこの新しいPaaSの大まかな哲学について、CEOのSamad Wahedi氏と短時間ながら話をした。

私たちは、現在サービスを提供しているPlatform-as-a-Service（サービスとしてのプラットフォーム）プロバイダとは違います。私たちの目標はワークフローをPowerpointと同じぐらい単純にすることです。ターゲットユーザーとしてセールス担当のアンディーを仮定しています。アンディーは30歳です。セールスチームのメンバーは地理的にあちこち分散していて、人数は30人と小規模のチームですが、会社自体は大きく、500人の従業員を抱えています。アンディーはFacebookにアカウントがあり、Officeスイート製品の扱いにとても慣れています。

ゼロから始めて、あらゆることを疑問視すると決めました。アンディーはどのように考え、アンディーにとって何なら「つじつまが合い」、アンディーはどのように仕事し、解決しようとしている問題は何で、どうやって解決しようとするだろうか…。こうしてSnapFlowが生まれました。

このことを念頭におき、SnapFlowでは伝統的なBPM標準（BPMNやBPEL）のいずれも使用していない。Wahedi氏は次のように説明する。

私たちが作り上げたセールス担当者アンディーは、プロのプロセスエンジニアではありませんから、BPMNを中心に据えた設計にしなかったのです。

ワークフローモデルの中心は活動と行動である。次に来る活動を決定するのは行動である。このモデルではユーザーと役割を各活動に関連づけるので、スイムレーンの必要性を取り除いている。

アンディーのための構築は続けますが、より複雑な機能を公開する必要があることも認識しています。目標は、複雑な機能をアンディーには見えないようにしながらも、パワーユーザーには公開することです。バランスのとり方が難しいですが、私たちにはできると考えています。 

SnapFlowはMicrosoft技術の上に構築された初のPaaSであり、Webベースのフォームとワークフローデザイナーを完全装備している。もちろんAzureはまだ利用していないが、.NETのPaaSがどのようなものになるかという点で、すぐれた見通しを提供している。SilverLightのプログラムマネージャーを務めるTim Heuer氏が先ごろ、SnapFlowについて書いている(リンク)。氏の投稿の目玉はSnapFlowの３分間のデモである。氏は次のように指摘している。

すばらしい特徴のひとつに、ワークフローの作成者が作業を完了したら、そのワークフローをWebサイトや他のポータル（たとえばデモではSharepointを使って見せている）へデプロイできることです。ですから、Webサイトからデータを収集するワークフローを開発し、コーディングをまったく行わずに、生成したSilverlightアプリケーションをサイトに埋め込むことができるのです。

前進中のBPMNを設計する方法にいまだ確信がもてない(リンク)業界であるから、ましてBPMNとBPEL間の正確な表現(リンク)の定義など言うまでもない。そうした中、設計過程にBPMアナリストだけでなく、もっと多数のユーザーを取り込める、代替的なBPMモデルを模索する時期がきたのではないかという疑問を、SnapFlowが再度投げかけているように思われる。さらに、こういう論点もある -- ソリューションをEC2やAzure Windows Servicesにデプロイできるプロの開発者向けにPaaSを設計すべきか、あるいは、単純なソリューションを迅速に、たいていは1度限りのプロジェクトのためだけに構築しなければならない一時的ユーザーを重視すべきか。みなさんはどのようにお考えだろうか。

 

原文はこちらです：http://www.infoq.com/news/2009/03/snapflow

• 次へ >