Welcome to MSDN Blogs Sign in | Join | Help

[Info] 12 月号は、Windows 7 の省電力プログラミング

こんにちは。

日経ソフトウェアでの Windows 7 の連載記事ですが、今月号から、エバンジェリスト 岩田 と共に順次掲載していきます。12 月号は、Window 7 の省電力プログラミング (岩田の執筆) です。

http://itpro.nikkeibp.co.jp/article/MAG/20091022/339253/

省電力とプログラミングって、何か関係があるのでしょうか ? 勿論、オオアリです。
プログラミングテクニックを学ぶと共に、省電力に配慮しないプログラムがどんな弊害をもたらすか、など、内部の仕組みや概念などをご理解頂けると幸いです。

 

Posted by tsmatsuz | 0 Comments
Filed under:

[Info] Visual Studio 2010, SharePoint 2010, そして . . .

こんにちは。

ブログの更新が滞ってしまい申し訳ありません。

訳あって出張しておりましたが、ここ 1 週間で開発者の方にとって大変いろいろと動きがあったと思います。以下に、この動きを整理して記載します。(セミナー、LT などを通して、皆さんに "オブラートに包んで表現していたこと" のいくつかも、以下の通りクリアになりました。スッキリ しない表現が多く、申し訳ありませんでした。。。)

Visual Studio 2010 Beta 2 がダウンロード開始 !

Visual Studio 2010 と .NET Framework 4.0 の Beta 2 の ダウンロード が開始されました。 
Beta 2 では、これまで Windows 7 の API Code Pack や COM 相互運用などでしかできなかった、.NET Framework での Windows 7 開発 (タスクバー、ジャンプリスト、ライブラリ等の開発) が標準でサポートされています。(エバンジェリスト 岩田がコードを紹介 していますので、是非参考にしてみてください。)

Visual Studio 2010 については、今後、イベント、セミナーなどを通し最新情報が紹介されてきますので、米国でまもなく開催予定の Professional Developer Conference 2009 (PDC 09)、日本で来年開催予定の Tech・Days 2010 など、今後のイベントに是非ご期待ください。

SharePoint 2010 Public Beta (Beta 2)、まもなく公開

SharePoint 2010 Beta 2 (Public Beta) も、まもなく公開予定です。(ラスベガスで開催されていた SharePoint Conference 2009 (10/19 - 10/22) で発表されました。)

新しい SharePoint では、フィーチャーマニフェストやソリューションマニフェストなどもビジュアル編集が可能で (従来は、XML の直接編集のみ)、Client API の提供や、LINQ での接続の提供 (LINQ to SharePoint)、Web パーツのビジュアル開発などなど、これまで開発者が "不自由" を感じていた多くの改善事項に加え、スケーラビリティ/アベイラビリティの向上 (「リスト」も含め)、REST 方式でのデータアクセスや連携、FAST 連携、Sandbox ソリューションの提供など、インターネット Facing やクラウド上のサーバー活用も意識した数多くの機能が追加されています。(先日、.NET ラボで現状報告をさせて頂いた「Web パーツのクライアント接続」なども、SharePoint 2010 からは、気にせず、柔軟に対応できます。)
発表された機能については、SharePoint チームブログ をはじめ、SharePoint MVP の山崎さんのブログクリエイルミネート・ブログ などでも記載されていますので、さわってみる前にいち早く知っておきたい方は、是非 Watch してみてください。

SharePoint 2010 についても、今後、イベント、セミナーなどを通し最新情報が紹介されてきますので、日本で開催予定の SharePoint Conference 2009 (日本) など、今後のイベント、セミナーに是非ご期待ください。

 

Posted by tsmatsuz | 0 Comments
Filed under: ,

スケーラブルで "強い" WCF サービスの開発

こんにちは。

本投稿のテーマは、WCF サービスの開発で、"スケーラブルなサービス"、"ミッションクリティカルなサービス"、"結構大きなサービス" を作りはじめると、「いろいろと問題に遭遇する」という話題です。ここ数日で、実はこの話題が何度か取り上げられることがありましたので記載しておきます。

この内容は、実は 一昨年の Tech Ed (2 回前の Tech Ed) でお話したものですが、月日が経ち、皆さんも "本格的なサービス開発" に取り組まれてきて、同様の問題で "はまる" ケースも多くなってきているでしょう。Microsoft の開発ツールは常にそうですが、ウィザードなどで簡単に構成してくれますが、一方で、こうしたツールが構成するものは "初期開発を簡素化するための雛型" であって、トランザクション数の多い本格的なサービスを構築する場合にはチューニングが必要になってきます。よくある問題としては、先日ユーザーの方 (WCF サービスのノウハウをお持ちの開発者の方) も言われていましたが、「サービス (IIS) が応答しなくなる」とか、「異常に遅くなる」などのトラブルに遭遇することがあります。

ここで、一昨年前の Tech Ed でご紹介した 「WCF / WF を活用した実践的アプリケーションの開発」 の内容をあえて 今 おさらいしておきたいと思います。

必要最小限度の構成を

ここは、もっとも大切なポイントです。 (いろいろあるので、少し長くなりますが。。。)

Visual Studio が自動で作成する WCF サービスは、既定では WsHttpBinding を使用した構成になっています。この WsHttpBinding ですが、メッセージレベルのセキュリティ、分散アトミックトランザクションへの対応、などなど、数々の非機能要件に対処できる優れたバインディングですが、その一方で、「本来必要ない余計な処理」をおこなって重くなっている場合もあるので注意してください。

まず「バインディング」について正しく理解しておきましょう。WCF の通信メカニズムは、OSI のプロトコルスタックのように、「認証をおこなう」→「暗号化する」→「MTOM でエンコードする」→「HTTP で通信する」 といった各手順の組み合わせになっています。メッセージを受信した際には、この逆の処理がおこなわれます。(実際には、OSI とはまったくレイヤが異なります。あくまでも例として記載していますのでご注意を。) この各ステップを組み合わせたものが「バインディング」です。つまり、既定で存在している BasicHttpBinding、WsHttpBinding、NetTcpBinding などは、この各ステップが既に組み込まれた状態になっています。
もし皆さんが、「そろそろ WCF の仕組みもわかってきて、いろいろチューニングを」と思われるならば、CustomBinding もお勧めです。CustomBinding は、この各ステップを自分で組み合わせて通信する方法で、ある意味、上述のような「既定の余計な設定」を含んでおらず、必要なもののみを組み合わせることができます (勿論、自分で組み合わせる必要があるので、相応の知識が必要です)。例えば、以下は、バイナリでデータを渡し、HTTP で通信をするだけの、軽量な「myLightWeightBinding」という名前の独自のバインディングを構成しています。

<bindings>
  <customBinding>
    <binding name="myLightWeightBinding">
      <binaryMessageEncoding />
      <httpTransport />
    </binding>
  </customBinding>
</bindings>

このカスタムバインディングを使わずに上述した既存のバインディング (WsHttpBinding など) を使って構成した場合には、チューニングの際に、既定で「オン」になっている数多くのプロパティなどを順番に「オフ」にしていく必要がありますが、カスタムバインディングを使えば、カスタムバインディングでは逆に、「必要なもののみをくみ上げていく」ことになるためチューニングもしやすく、かつ「何が使われているか」といった理解性もよくなります。

カスタムバインディングを使用せずに既定の構成を使用する場合は、不要な既定値はオフにしておいてください。例えば、各バインディングでは、接続 (Connection) の最適化のために、以下の既定値が設定されていますので、このあたりもチューニングに際してよく問題にされるポイントです。

  • 例えば BasicHttpBinding では、既定で HTTP の KeepAlive の設定がおこなわれており、一定のルールで接続されたままの状態になっています (つまり、これが原因で余計なサーバーリソースを消費している場合があります)。処理のスタイルを考慮し、断続的で頻繁な接続などが不要な場合には、この設定はかえって重くなりますので、keepAliveEnabled = false としてこの既定値をオフにしておいてください。
  • また WsHttpBinding では、上記の KeepAlive と同様に、セキュリティコンテキストと呼ばれるセッションのコンテキストが既定で保持されていて、セッション (状態を維持した処理) などで活用されています。これも不要な場合には、EstablishSecurityContext = false として「オフ」にしておきましょう (ただし false にすると、当然、「セッション」を保持した処理ができなくなります)
  • NetTcpBinding では、最適化のため、内部でコネクションが Pool  されていおり、既定では 5 分間保持されています。このプールが不要な場合も、カスタムバインディングを作成し、leaseTimeout でこのリリース時間をカスタムに設定する必要があります。

また、例えば、netTcpBinding では、認証として、既定で「Windows 認証」が使用されているなど、 「接続」(Connection)という観点以外にも認証、セキュリティ設定などの配慮が必要になります。

パフォーマンスだけに注目するならば、トランスポートレベルのバインド要素としては tcpTransport が最も高速で (注 : 同一ノード内なら namedPipeTransport がもっとも早そうに思われるかもしれませんが、必ずしもそうではありません)、エンコーディングについては、無論、BinaryMessageEncoding が早くなります。 

また、こうした WCF の構成以外にも、.config 内のその他の余計な構成 (例えば、よくあるケースは、使ってもいないのに Windows 認証がそのまま入っている、とか) は、パフォーマンス劣化という観点以外に、可読性という観点でもちゃんと削除しておきましょう。

クライアントサイドも必要最小限度に

クライアントサイドも似た留意点があてはまります。WCF をこれからはじめる多くの方が、下図のように [サービス参照の追加] によってクライアントプロキシを構成し、プログラミングをおこなうことでしょう。(私も、初学者の方向けの Web キャストではこの方法を紹介しています。)

この方法は無論、「いけないこと」ではありませんが、もし、クライアントからも呼び出しが頻繁におこなわれ、この点での最適化 (チューニング) も必要になりそうな大規模なアプリケーションの場合には、ChannelFactory を使用して自身で .config を構成して接続する方法をお勧めします。
パフォーマンスの面でも ChannelFactory を使用したほうが高速に処理されますが、よく陥る問題としては、複数のサービスへの接続や、頻繁な [サービス参照の更新] (サービス側のコントラクトが変更され、クライアント側でプロキシを作り直し) によって、.config がぐちゃぐちゃになってしまう (使っていない構成などが大量に残り、最終的に可読性が低下する) ことがあり、最悪なケースでは、そうしたぐちゃぐちゃな構成をそのまま本番用に適用する結果となり、メンテナンスやチューニングに際して大きなオーバーヘッドが発生するためです。

まめなテストと現象の解析

さらに、"大きなサービス" を構成する場合には、負荷テスト (及び、必要に応じ解析) も欠かさないようにしてください。構成が大きくなって原因が特定しづらい状況になってからでは遅い場合があります。以下でもご紹介しているように、Visual Studio のロードテストを使用すると、この一見「大変そうな」負荷テストも、プログラマーがいつでも簡単に実施することができます。

IT Pro 道場自主トレシリーズ : 負荷テストの実施
http://technet.microsoft.com/ja-jp/events/dd696124.aspx

普段からまめにテストを実施することで、「・・・の構成を入れたら動かなくなった」など、問題の特定もピンポイントになりますので、是非大きな開発ではこまめなテストを実施してプロジェクトを進めてください。

また、現象を解析する際に、WCF 内の細かな動き (上述したような、WCF 内のスタックの動き、など) を解析する必要がある場合には、トレースを出力して、Visual Studio (.NET Framework SDK) に付属しているサービストレースビューアツール (svctraceviewer.exe) を使用すると、内部の呼び出しのスタックや処理時刻などが確認できます。(メッセージのトレースも出力すると、どこでどの内容のメッセージが飛んだか確認することもできます。) 問題なく動作しているケースなどと比較して、「認証関連でやたらと時間がかかっている」など、どの処理がオーバーヘッドになっているか細かに確認できます。

さらに慣れてきたら、WCF Load Test Tool なども活用して、より効率的なテスト計画と反復テストをおこなうこともできます。

ワーカープロセスの最適化

WCF サービスでは、.svc を使って IIS にホストするケースも多いでしょう。この場合、ロードテスト (負荷テスト) により、前述したように、ワーカープロセスが肥大化して、応答しなくなってしまうケースがたまに発生することがあります。
こうした場合には、まず、ワーカープロセスの状態を確認してください。IIS 7 を使用されている場合には、インターネットインフォメーションサービスマネージャ (IIS 管理マネージャ) を起動して、下図の通り、ワーカープロセス内で実行されているスレッドや、それぞれのスレッドの状態などを確認できますので、この方法で問題を特定できる場合があります。(例えば、認証処理で止まっている、とか。) 

問題を特定したら、上述のように構成 (.config) を編集するなどして可能な最適化を実施し、それでもスレッドが追いつかない (スレッドが蓄積されて要求を処理しきれない) 場合には、負荷分散などを考慮する必要があります。

負荷の分散 (ロードバランス) 

要求が大量な場合、サービスに処理が蓄積され、要求をさばききれないケースがあります。この場合には、負荷の分散を検討する必要があります。

IIS ホストの場合には、非常に簡単にできる負荷分散の方法として、上述のワーカープロセス数を変更する手法があります。インターネットインフォメーションサービスマネージャ (IIS 管理マネージャ) のアプリケーションプールの詳細設定画面で、簡単にワーカープロセスの最大数を変更することが可能であり、既定ではこの値は「1」 になっています。(最大数を変更すると、要求が増えていくと、ワーカープロセス (w3wp.exe) が増加し、複数のプロセスで要求が処理されるようになります。)

一方、セルフホストの場合などには、下記の通り、スロットルを構成して処理のスループットを向上させる手法も可能です。

<behavior name="Throttled">
<serviceThrottling maxConcurrentCalls="1"
    maxConcurrentSessions="1"
    maxConcurrentInstances="1" />
</behavior>

また、ハードウェアロードバランシングや、NLB を構成するなどして、マシンをスケールアウトさせて処理を分散させることも、勿論、可能です。(StockTrader と呼ばれる WCF を使用した著名なサンプルでは、アプリケーション自身が要求を別のマシンに委譲させるような仕組みを独自に構築していますが、一般の負荷分散の仕組みを使用することも可能です。)

ただし、こうした負荷の分散をおこなうと、ステートを保持しているサービス (前の処理の結果によって次の結果が変わるようなサービス) では、要求ごとにプロセスが変わってしまい、期待しない結果を招く場合があるため、この制御をちゃんとおこなう必要が生じます。

ロードバランスされた状況での、状態 (ステート) の保持

そこで、"ロードバランスされた環境" でかつ、"ステート (状態) を効率的に維持" したいというケースが出てきますが、WCF には、こうした処理をおこなういくつかの手法があります。これについては、講演で解説の時間が充分とれなかったため "怪我の功名" と言いますか、一昨年前の Tech Ed セッションのフォローブログで記載していましたので、以下を参照してください。

http://blogs.msdn.com/tsmatsuz/archive/2008/08/27/t2-302-follow-up-wcf-asp-net-compatibility-model-stateful-n-tier-wcf-load-balancing.aspx

結論だけを述べると、いくつか手法が存在し、用途に応じて (例:永続化が必要、WF と一緒に使う、などなど) 使い分けることができますが、単にステートを維持する目的であれば、ASP.NET 互換モード (ASP.NET Compatibility Mode) の手法がもっとも "軽量" に動作します。

なお、"簡易な WCF サービス" で単に状態 (ステート) を維持したいだけであれば、Session を使用した WCF サービスを構築 (PerSession で WCF を構成) できますので、上記のような面倒な考察は不要です。("ロードバランスされた環境 (かつ、スティッキーでないケース)" という前提で記載しています。なお、「WCF のセッション」では、Web アプリケーションの Session オブジェクトは使用されていないため注意してください。Web アプリケーションの Session オブジェクトなどを使用したい場合に、上記の ASP.NET 互換モードを使用します。)

RESTful サービスの考慮

さて、話がどんどん面倒なほうに行ってしまいましたが、パフォーマンスや最適化を柔軟に構成する上で、REST による WCF サービスも視野に入れておくと良いでしょう。REST は、無論、 パフォーマンスをあげるために存在するアーキテクチャスタイルではありませんが、例えば、以下のような観点で、上述のような考察も "簡素化" してくれるというメリットがあります。特に商用サービスを提供するケースなどでは、他アプリからの接続性という観点など、さまざまなメリットもあわせて享受できる場合があります。

  • REST スタイルでは、処理のスタイルが明快です。例えば、上述したようなステート (状態) の維持といった観点は、実は、アーキテクチャスタイルを再設計すれば本来は不要かもしれません。 
  • このため、チューニングも容易です。例えば、IIS の設定を変更するなどして、"キャッシュ" (Cache) を有効活用できます。

 

上記は「チューニングのすべて」ではありませんが、いくつか代表的な手法をピックアップして紹介しました。一昨年前の Tech Ed でもお話しましたが、WCF は、実は、高速に処理できるように過去のテクノロジーよりもさまざまな観点で最適化されています。データの受け渡しも、XmlDocument を使用しないストリームによるパース、接続情報のキャッシュ、など、さまざまな最適化を内部で実施しています。しかし、上述した構成の話など、条件によっては、過去のテクノロジーより遅くなってしまうケースがあるので注意してください。(例えば、DataSet などの型定義がゆるい情報の受け渡しでは、こうしたメリットが損なわれてしまいます。バインディング構成によっても遅くなります。)

 

 

Posted by tsmatsuz | 1 Comments
Filed under:

SharePoint : クライアントサイドでの Web パーツ接続

環境 :
Office SharePoint Server 2007
Visual Studio 2008
Visual Studio extension for Windows SharePoint Services (VSeWSS) 1.2

[Download Sample : SampleClientWebPartConnection.zip ]

こんにちは。

以下、仕事の関連で話題になりましたので、方法をメモとして記載しておきます。。。

ここでは、Client サイドの Web パーツ接続 (WebParts Connection) について説明します。現在、Web パーツを AJAX, Silverlight などを使用して構築しているケースも多いと思いますが、こうした場合に有効な手段となるでしょう。

事前知識

まず、セミナーなどでもご説明しているように、Windows SharePoint Services 3.0 (Office SharePoint Server 2007) 以降の SharePoint テクノロジーは、従来の SharePoint テクノロジーとの互換性を意識しつつ、.NET の Web 開発テクノロジーである "ASP.NET" とさまざまな面で "美しく" 統合されています。「Web パーツ」もこうした ASP.NET と "美しく" 統合されたテクノロジー・コンポーネントの 1 つであり、この辺りの知識については、下記のテックフィールダーズコラムで簡単に説明していますので参考にしてください。

Web パーツとフィーチャーフレームワーク :
http://www.microsoft.com/japan/powerpro/TF/column/tm_03_2.mspx

このため、MOSS 2007 (WSS 3.0) の Web パーツでは、ASP.NET の WebPart クラスを継承して、SharePoint の Web パーツとして開発・配置をおこなうことが可能です。こう書くと、もはや、あの面倒な "SharePoint の WebPart" はレガシー対応でしか存在していないと言った感じですが、"SharePoint の WebPart クラス" を使用すると、実は、SharePoint でしか使えない幾つかの機能を使用することができるため、こうした目的でこのクラスを使用することができます。(ただし、こうした開発は必要最小限度に留めておきましょう。。。)
そうした機能の 1 つが、今回ご紹介する Web パーツのクライアント側での接続 (Client Connection) です。

なお、"ASP.NET の WebPart クラス" を継承した標準的な Web パーツ作成と、Web パーツどうしの接続のプログラミング方法は、以前、下記の投稿で方法とコードを掲載しています。この投稿で記載している「プロバイダー」と「コンシューマ」の概念などは、"SharePoint の WebPart クラス" でも同様に必要な概念ですので基本をおさえておいてください。

SharePoint における実用的なカスタム Web パーツ (WebPart) の開発 :
http://blogs.msdn.com/tsmatsuz/archive/2007/09/12/sharepoint-web.aspx

では、本題に入っていきましょう。まず、"SharePoint の WebPart クラス" を継承したプログラミング方法ですが、これについては、以下の MSDN の記事が参考になります。

[ウォークスルー] 接続可能な Windows SharePoint Services の Web パーツを作成する
http://msdn.microsoft.com/ja-jp/library/ms469765.aspx

コードの細かな点はとりあえず置いておき、ポイントのみを記載すると、このサンプル (上記のウォークスルーのサンプル) では、ICellProvider, ICellConsumer インタフェースを実装して、相互に接続可能な「プロバイダー Web パーツ」と「コンシューマー Web パーツ」を開発していますが、これら ICellProvider、ICellConsumer 以外の他のインタフェースを使用すると、前述の投稿 (SharePoint における実用的なカスタム Web パーツの開発) でも説明しているように、さまざまなタイプのプロパティ (例 : リストそのものや、リストの行、リストの特定の列の値、フィルターの値、など) と接続可能なさまざまな Web パーツをプログラミングすることができます。
実は、この ICellProvider、ICellConsumer は、"古いインタフェース" であり、標準的な ASP.NET の Web パーツ開発では、 前述の投稿 (SharePoint における実用的なカスタム Web パーツの開発) の中でも記載しているように、IWebPartField などの ASP.NET のインタフェースを使用しますので注意してください。

クライアント接続のプログラミング (Programming)

さて、上記のウォークスルーのサンプルの中でも、実は、既にクライアント接続用のコードが記載 (サーバー接続用のコードと混在) されていますが、今回は話を簡単にするため、このクライアント接続の部分のコードのみにフォーカスを当て、より簡単なサンプルで説明します。

まずは、いきなりですが、プロバイダー (Provider) Web パーツ側のサンプルコードを以下に記載します。

. . . . .
using Microsoft.SharePoint.WebPartPages.Communication;

namespace ClientConnectionWebPart
{
  [Guid("9ddf3991-37ad-49db-9993-e874b65893b6")]
  public class SampleProviderWebPart : Microsoft.SharePoint.WebPartPages.WebPart, ICellProvider
  {
    [Obsolete]
    public override void EnsureInterfaces()
    {
      RegisterInterface("MyCellProvider_WPQ_",
         InterfaceTypes.ICellProvider,
         Microsoft.SharePoint.WebPartPages.WebPart.LimitOneConnection,
         ConnectionRunAt.Client,
         this,
         "CellProvider_WPQ_",
         "Send to MyCellConsumer",
         "this is test");
    }

    [Obsolete]
    public override ConnectionRunAt CanRunAt()
    {
      return ConnectionRunAt.Client;
    }

    [Obsolete]
    public override void PartCommunicationConnect(string interfaceName, Microsoft.SharePoint.WebPartPages.WebPart connectedPart, string connectedInterfaceName, ConnectionRunAt runAt)
    {
      if (runAt == ConnectionRunAt.Client)
      {
        // 接続時に呼ばれるため、接続時の処理はここに書きます。
        // 今回は、何もしない . . .
      }
      EnsureChildControls(); // <-- 今回は、なくても良い
    }

    [Obsolete]
    public override void PartCommunicationInit()
    {
      // クライアント側の接続では、ここは呼ばれません
      // (サーバー側の接続の場合のみ、実装)
    }

    [Obsolete]
    public override void PartCommunicationMain()
    {
      // クライアント側の接続では、ここは呼ばれません
      // (サーバー側の接続の場合のみ、実装)
    }

    protected override void RenderWebPart(HtmlTextWriter output)
    {
      EnsureChildControls(); // <-- 今回は、なくても良い

      output.Write(ReplaceTokens(
        "<select id='MySelect_WPQ_' onchange='MenuChange_WPQ_()'>\n" +
        "<option value='1'>1番選択</option>\n" +
        "<option value='2'>2番選択</option>\n" +
        "</select>"));

      output.Write(ReplaceTokens(
        "<script language='javascript'>\n" +

        "var CellProvider_WPQ_ = new funcCellProvider_WPQ_();\n" +
        "function funcCellProvider_WPQ_() {\n" +

        "  this.PartCommunicationInit = myInit;\n" +
        "  this.PartCommunicationMain = myMain;\n" +
        "  this.CellConsumerInit = myCellConsumerInit;\n" +

        "  function myInit() {\n" +
        "  var cellProviderInitArgs = new Object();\n" +
        "  cellProviderInitArgs.FieldName = 'CellName';\n" +
        "  WPSC.RaiseConnectionEvent('MyCellProvider_WPQ_', 'CellProviderInit', cellProviderInitArgs);\n" +
        "  }\n" +

        "  function myMain() {\n" +
        "  var cellReadyArgs = new Object();\n" +
        "  cellReadyArgs.Cell = '';\n" +
        "  WPSC.RaiseConnectionEvent('MyCellProvider_WPQ_', 'CellReady', cellReadyArgs);\n" +
        "  }\n" +

        "  function myCellConsumerInit(sender, cellConsumerInitArgs) { }\n" +

        "}\n" +

        "function MenuChange_WPQ_() {\n" +
        "  var cellReadyArgs = new Object();" +
        "  cellReadyArgs.Cell = document.all('MySelect_WPQ_').value;\n" +
        "  WPSC.RaiseConnectionEvent('MyCellProvider_WPQ_', 'CellReady', cellReadyArgs);\n" +
        "}\n" +

        "</script>\n"));
    }

    #region ICellProvider メンバ

    // 以下はいずれも、クライアント側の接続では呼ばれません
    // (サーバー側の接続の場合のみ、実装)
    public void CellConsumerInit(object sender, CellConsumerInitEventArgs cellConsumerInitEventArgs)
    {
    }
    public event CellProviderInitEventHandler CellProviderInit;
    public event CellReadyEventHandler CellReady;

    #endregion
  }
}

上記のコードを説明します。

まず、"SharePoint の Web パーツ" ですから、SharePoint の WebPart クラスを継承し、今回は、ICellProvider インタフェース (特定の列の値と接続可能なインタフェース) を実装しています。

EnsureInterfaces オーバーライドメソッドでは、この Web パーツがいったい何者であるかを返しています。EnsureInterfaces の 6 番目の引数の "CellProvider_WPQ_" は、イベントが発生した場合に処理されるクライアント側 (JavaScript 側) のクラスを示しており、今回は、コンシューマ側がイベントを投げると、このプロバイダーの CellProvider_WPQ_ のクラス (JavaScript のオブジェクト) でイベントが処理されることになります。

上記で、_WPQ_ は、非常に重要なキーワードです。このキーワードは、SharePoint により一意な ID に書き換えられます。これにより、同一の Web パーツが複数存在しているケースなど、さまざまなケースで矛盾がなく処理されるようになりますので、関数名、オブジェクト名など、一意性が求められる箇所にはこのキーワードを入れておきましょう。(上記の RenderWebPart オーバーライドメソッドにおける ReplaceTokens では、この書き換えを明示的に指定しています。)

Obsolete 属性は、"古いメソッド" などを使用している場合に警告を表示しないために使用しているオマジナイだと思ってください。前述したように、ICellProvider 自体も古いインタフェースであり、Obsolete でビルドメッセージを指定しないと、ビルド時に、"廃棄予定のメソッドである" などのメッセージが表示されることになるでしょう。

RenderWebPart オーバーライドメソッドに記載されているコードは最も重要です。(というか、今回はクライアント側の処理のため、ここに処理のほとんどが書かれています。) 通常のサーバー側の Web パーツでは、Web パーツの初期化がおこなわれた際に呼ばれる PartCommunicationInit メソッドや、選択項目が変更された際などに呼ばれるメイン処理の PartCommunicationMain メソッドなどのオーバーライドメソッドをプログラミングしますが、クライアントサイドの接続では、こうした処理はすべて JavaScript で記述することになります (このフレームワークの JavaScript ライブラリが SharePoint によって内部で提供されます)。このため、このフレームワークと連携して動作する処理を  "JavaScript として"  RenderWebPart メソッドで出力しています。

この JavaScript の処理についてですが、this.PartCommunicationInit は Web パーツの初期化がおこなわれた際に呼ばれる処理で、this.PartCommunicationMain は初期化後の状態の変更通知などで呼ばれるメイン処理です。いずれのメソッドも、それをコンシューマー Web パーツに通知するため、WPSC.RaiseConnectionEvent (SharePoint の組み込みの JavaScript 関数) を呼び出しています。
また、CellConsumerInit メソッドは、逆に、コンシューマ側から通知されるイベント処理で、今回、ここでは特に処理はおこなっていません。
メニュー (select タグの項目) が変更されると、RadioOnClick_WPQ_ 関数により、PartCommunicationMain の処理と同様、CellReady のイベントをコンシューマ Web パーツに通知し、この際、引数としてメニューで選択された値を送信しています。
(なお、ここではクライアントのコードで説明していますが、サーバー側の実装でも、上記と同様の概念で、PartCommunicationInit、PartCommunicationMain などを使用するので、この動作概念はおぼえておくと良いでしょう。サーバー側の実装の場合、コントロールの再描画時などに自動的に PartCommunicationMain が呼ばれるので、コントロール側では、単にポストバックをおこなうように実装すれば良いでしょう。。。)

つぎに、コンシューマ (Consumer) 側のコードを記載してみましょう。

. . . . .
using Microsoft.SharePoint.WebPartPages.Communication;

namespace ClientConnectionSample
{
  [Guid("0bab1085-f5f8-42ba-a406-9c6f8619121e")]
  public class SampleConsumerWebPart : Microsoft.SharePoint.WebPartPages.WebPart, ICellConsumer
  {
    [Obsolete]
    public override void EnsureInterfaces()
    {
      RegisterInterface("MyCellConsumer_WPQ_",
        InterfaceTypes.ICellConsumer,
        Microsoft.SharePoint.WebPartPages.WebPart.LimitOneConnection,
        ConnectionRunAt.Client,
        this,
        "CellConsumer_WPQ_",
        "Receive from MyCellProvider",
        "this is test");
    }

    [Obsolete]
    public override ConnectionRunAt CanRunAt()
    {
      return ConnectionRunAt.Client;
    }

    [Obsolete]
    public override void PartCommunicationConnect(string interfaceName, Microsoft.SharePoint.WebPartPages.WebPart connectedPart, string connectedInterfaceName, ConnectionRunAt runAt)
    {
      if (runAt == ConnectionRunAt.Client)
      {
        // 接続時に呼ばれるため、接続時の処理はここに書きます。
        // 今回は、何もしない . . .
      }
      EnsureChildControls(); // <-- 今回は、なくても良い
    }

    [Obsolete]
    public override void PartCommunicationInit()
    {
      // クライアント側の接続では、ここは呼ばれません
      // (サーバー側の接続の場合のみ、実装)
    }

    protected override void RenderWebPart(HtmlTextWriter output)
    {
      EnsureChildControls(); // <-- 今回は、なくても良い

      output.Write(ReplaceTokens("<input type='text' id='MyText_WPQ_' />\n"));

      output.Write(ReplaceTokens(
        "<script language='javascript'>\n" +

        "var CellConsumer_WPQ_ = new funcCellConsumer_WPQ_();\n" +
        "function funcCellConsumer_WPQ_() {\n" +

        "  this.PartCommunicationInit = myInit;\n" +
        "  this.CellProviderInit = myCellProviderInit;\n" +
        "  this.CellReady = myCellReady;\n" +

        "  function myInit() {\n" +
        "  var cellConsumerInitArgs = new Object();\n" +
        "  cellConsumerInitArgs.FieldName = 'CellName';\n" +
        "  WPSC.RaiseConnectionEvent('MyCellConsumer_WPQ_', 'CellConsumerInit', cellConsumerInitArgs);\n" +
        "  }\n" +

        "  function myCellProviderInit(sender, cellProviderInitArgs) { }\n" +

        "  function myCellReady(sender, cellReadyArgs) {\n" +
        "  document.all('MyText_WPQ_').value = cellReadyArgs.Cell;\n" +
        "  }\n" +

        "}\n" +

        "</script>\n"));
    }

    #region ICellConsumer メンバ

    // 以下はいずれも、クライアント側の接続では呼ばれません
    // (サーバー側の接続の場合のみ、実装)
    public event CellConsumerInitEventHandler CellConsumerInit;
    public void CellProviderInit(object sender, CellProviderInitEventArgs cellProviderInitArgs)
    {
    }
    public void CellReady(object sender, CellReadyEventArgs cellReadyArgs)
    {
    }

    #endregion
  }
}

コンシューマ側も、考え方はまったく同様です。プロバイダー側のコードを理解できた方は、こちらのコードも簡単に理解できたのではないでしょうか。

コンシューマ側では、上述したプロバイダー側からの初期化のイベント処理 (PartCommunicationInit 関数が渡した CellProviderInit イベント) とメインのイベント処理 (PartCommunicationMain 関数が渡した CellReady イベント) が呼び出されますので、これらのイベント処理を JavaScript で記述しています。今回は、CellReady のイベント処理で、テキストボックスに、渡された値 (引数) をそのまま設定するように記載しています。

このプロバイダー Web パーツとコンシューマ Web パーツを SharePoint に配置し、相互の接続をおこなって動作をさせると、下図の通り、選択欄 (メニュー) が変更された際に、テキストボックスに選択した値が入力されます。(ページのポストバックはおこなわれません。)

なお、既存のリストビュー Web パーツ (ListViewWebPart) では、残念ながら、サーバー側での Web パーツ接続しかサポートしていないようですので (ConnectionRunAt.Server または、ConnectionRunAt.ServerAndClient のみ対応)、
この自作のクライアントサイドの Web パーツと接続することはできませんので注意してください。

 

Posted by tsmatsuz | 0 Comments
Filed under: ,

[記事紹介] Windows 7、アプリケーション互換性の Tips ! Tips ! Tips !

こんにちは。

Windows 7 のアプリケーション開発の視点での「互換性」情報について、「マニフェスト編集」、「セッション 0 の分離」、などなど、既に、"概要レベル" のドキュメントは多くの方が目を通されたかと思います。

今回ご紹介する記事は、現実のアプリケーション開発をおこなう上で実際にどのような点に遭遇し、それぞれをどのように考えていくか、という Tips を列記したものです。

Windows 7 : 製品ソフト開発者から出た "その疑問" にズバリお答えします !
http://www.microsoft.com/japan/powerpro/TF/column/ro2_01_1.mspx

マイクロソフトでは、新しい OS のリリースに際して、リリースのかなり前の段階から早期導入と検証のためのプログラムがおこなわれています。日本の多くのベンダの方、ソフトウェア開発者の方も参加されており、皆さんがお持ちの実際のアプリケーションを使用して、検証や、窓口での Q & A がおこなわれ、この段階での Q & A の多くは、実際に開発に関与している (マイクロソフトの) 開発部門が多く対応しています。上記の記事は、こうした多くのソフトウェア開発者の皆さんからフィードバックのあった "現実の課題" のうちの代表的なものを各回にわけて連載しています。
第1回は、Windows Vista から変更された Tips 系の話について、「セットアップ関連での注意点」、「削除された細かな機能群」、帳票文化の日本のお客さんにとっては重要な 「フォントの話」 にわけて、記載されています。(Windows Vista で追加・変更された機能ではありません。。。)

「もう知ってる、そんなこと」、「知らなかった、そんなこと!」など、いろいろな内容が含まれているかと思いますが、単なる変更点の列挙ではなく、「実際にどのような場合に、どんな問題に遭遇するのか」といった視点で記載されています。これから Window 7 対応のアプリケーション開発をお考えの方は、是非参考にしてみてください。

 

Posted by tsmatsuz | 0 Comments
Filed under:

[ブログ紹介] Scott Gu の VS 2010 and .NET 4.0 シリーズ

こんにちは。

特に新しい技術をキャッチアップされている方にとっては、次期 Visual Studio 2010、.NET Framework 4.0 について、いろいろと待望の機能なども多いことでしょう。日本のイベントでもいくつかご紹介をしてきましたが (Tech Ed 2009 では、新村 の 「Visual Studio 2010 & .NET Framework 4 概要」 のセッションでまとめて紹介させました)、「仕事が忙しくてイベントに出ていられない。。。」という方、「気になるけど、イベントに通うほどマイクロソフトにハマっているわけでは。。。」 という方も居られるでしょう。MSDN の記事を端から端まで読むわけにも。。。

そんな方は、Scott Gu が、自身のブログの中で、新しくなった Visual Studio 2010、.NET Framework 4.0 の新機能を中心に、いち早く、シリーズを掲載してくれています。

ScottGu's Blog : VS 2010 and .NET 4 Series
http://weblogs.asp.net/scottgu/archive/2009/08/25/vs-2010-and-net-4-series.aspx

次期 Visual Studio 2010、.NET Framework 4.0 については今後も日本のイベントなどで順次 情報発信がおこなわれると思いますが、先行でキャッチアップしたい方、机の上で "自分のペースで" "ポイントにしぼって" 読みたい方には、ためになる投稿がどんどん出てくると思います。

 

Posted by tsmatsuz | 2 Comments
Filed under:

技術を理解して、正しく判断 . . .

こんにちは。

本日、Tech Ed 「IT ヒーローラウンジ」でご紹介した本は以下になります。

.NET 開発テクノロジ入門 (日経BPソフトプレス)
http://astore.amazon.co.jp/press096-22/detail/4891006609

こちら、本日は Tech Ed ということで、.NET な開発者向けの紹介でしたが、Java, PHP (Zend) など、他のテクノロジに周知されている方も、ASP.NET MVC, ADO.NET Data Services は勿論、その他のテクノロジも、是非新鮮な感覚で内容に接して頂ければと思います。(これイケてる ! 時代遅れ ? など、セミナーなどを通し、さまざまなフィードバックをお待ちしています。)

昨今、言語を問わず、多くのテクノロジやアイデアがあり翻弄されてしまいそうですが (大変な時代ですね。。。)、まわりの技術やアイデアを理解せず (触れず) に殻に籠ってしまうことと、それぞれの技術 (良い点、悪い点) を理解した上で最適なものを選択する (もしくは、選択しない) ことには大きな差異があります。著者陣の一人として、皆さんにも、是非、そうした "広い視点" を持って技術と接して頂ければと思います。(これは、OS、データベース、など分野を問いません。)

ご参考 : 「中堅企業向け オラクル都市伝説シーズン2: 其の一」への反論
http://blogs.technet.com/sqlpm-j/archive/2009/08/27/3277427.aspx

 

Posted by tsmatsuz | 0 Comments
Filed under:

【T2-311補足】 msi ファイル (Windows Installer) の 64 bit 向けカスタマイズ

こんにちは。

Tech Ed 2009 セッション T2-311 で紹介が途中となった 64 ビット環境向けの msi のカスタマイズ手順、および紹介できなかったその他の要素について補足します。

msi ファイルの超概要

セッションでもご紹介したように、Windows インストーラの msi ファイルは、テーブルなどが多数含まれたデータベースファイルの構造になっています。
Visual Studio では、こうしたインストーラで必要となるテーブルの内容やプロパティなどの設定を簡素化しているため意識しませんが、msi ファイルの内容を細かくカスタマイズする必要が生じた場合にはこうしたテーブルの内容などをカスタマイズできるツールを使用して構成しなければならないケースがあります。

こうしたカスタマイズをおこなえるツールはいくつか存在しますが、ここでは、Windows SDK に付属の「Orca」というツールを使用して例示します。

カスタマイズの概要 (インストールファイルの例)

では、実際に例をみてみましょう。(下記の例は、一見、64 bit とは無関係ですが、64 bit 環境のためのカスタマイズでも必要になる場合があります。)

例えば、ファイルのインストール先ディレクトリを変更する方法を考えてみましょう。この設定には、msi の中の File テーブル、Component テーブル、Directory テーブルなどを使用します。ここでは、インストールされるモジュール (.exe など) を c:\work のディレクトリにインストールするように変更してみましょう。

まず、Orca を起動して、Visual Studio などで作成された .msi ファイルを開いてください。
そして、File テーブルを参照すると、インストールされるモジュールの Component 名が Component_ 列 (下記) に記載されているのがわかります。

このコンポーネント名は Component テーブルで参照できます。さらに、Component テーブルの Directory_ 列にディレクトリ名が記載されていますので、つぎに、このディレクトリの情報を Directory テーブルで参照します。

Directory テーブルには、Directory 列、Directory_Parent 列、DefaultDir 列を持っており、それぞれ以下の内容が記載されています。

  • Directory 列 :
    その Directory の名前が入っています。
  • Directory_Parent 列 :
    親のディレクトリの名前 (上記) が入っています。ここをブランクにすると、親を持たないルートディレクトリであることを示します。
  • DefaultDir 列 :
    ここにディレクトリを指定します。一般に Directory_Parent に対するサブディレクトリを指定しますが、ターゲットディレクトリ (インストール先) とソースディレクトリ (インストール元) があり、それぞれをコロン (:) を使用して  targetpath:sourcepath の形式で指定します。(コロンを入れない場合には、双方のサブディレクトリになります。)

例えば、Visual Studio で作成したばかりの .msi ファイルは以下のような感じになっているでしょう。


上図で、パイプ文字 ( | ) で区切られている箇所は、short name と actual name を指しています。

上図では、約束語がたくさん含まれていますので注意してください。
まず、TARGETDIR ですが、ここには、インストーラ実行時に外部 (コマンドラインのオプションや、インストーラの画面) から指定するインストール先のターゲットディレクトリが設定されることを意味しています。また、SourceDir も、インストーラのソースディレクトリのパスで上書きされます。さらに、ショートカットの作成などで使用するプログラムメニュー (ProgramMenuFolder) やデスクトップ (DesktopFolder) のディレクトリなども上記で指定されていますが、これらもそれぞれの環境にあわせて書き換えられます。(なお、作成されるショートカットは、上記の File テーブルでなく、Shortcut テーブル内で指定されています。)

これらの詳細については、以下に記載されています。

Using the Directory Table :
http://msdn.microsoft.com/en-us/library/aa372452(VS.85).aspx

今回は、c:\work にインストールするため、この Directory テーブルに [Add Row] メニューで行を追加し、以下の 2 行を追加してみましょう。

Direcrory Directory_Parent DefaultDir
root (ブランク) SourceDir
work root work:.

1 行目は、ルートドライブ (この場合、C:\ と仮定) がターゲットとして設定され、2 行目で c:\work がターゲットに指定されます。

あとは、この「work」を Component テーブルの Directory_ 列に設定して終了です。

上記は 64 bit とは何ら関係のないサンプルでしたが、例えば、x86 用と x64 用でインストールするモジュールを変える場合には、Directory テーブルで x86 用と x64 用の両方のソースの指定を用意しておき (さらに、それぞれを同じターゲットにインストールするように設定し)、Component テーブルの Condition 列を使用してコンポーネントのインストール条件を設定することで、環境にあわせてそれぞれ別のソースからコピーをおこなうように指定することになるでしょう。

64 bit 用のカスタム動作の設定 (マネージコードの場合)

では、デモでさらりと流した「64 bit 環境用のカスタム動作の設定手順」を復習し、紹介できなかった他の設定方法などもご紹介します。

カスタム動作 (カスタムアクション) は、ご紹介したように CustomAction テーブルに記載されており、インストール時、アンインストール時などの各アクションと、アクションで使用するソース (Source) が下記の通り指定されています。

そして、上記の Source の情報は Binary テーブルに記述されており (下図)、下記の Data 列に、実行されるバイナリデータが入っています。

セッション(デモ)で見ていただいたように、マネージコードのアクションの場合、既定では、このバイナリデータとして、

%windir%\Microsoft.NET\Framework\v2.0.50727\InstallUtilLib.dll

が設定されています。このため、カスタム動作を動かすと、ファイルはリダイレクトされたり、32 bit 用の ngen.exe が実行されるなど、64 ビット環境にあわない動きをすることになるでしょう。(ご紹介したように、Visual Studio のコマンドプロンプトも 32 bit 用の Framework にパスが通っていますので混乱しないよう注意してください。Visual Studio 2010 がどうなるかは、現時点では未定です。)

従って、Orca を使用して、この Binary Data を 64 bit 用の

%windir%\Microsoft.NET\Framework64\v2.0.50727\InstallUtilLib.dll

に変更することでこれらは解決されます。

セッションのデモでは上記の方法を紹介しましたが、例えば、アクションによって 32 bit, 64 bit をわけて実行したい場合などには Binary テーブルの行を追加して、CustomAction テーブルで使用する Binary を用途にわけて設定すれば双方のアクションを実行することもできます。

 

Posted by tsmatsuz | 2 Comments

【T2-310補足2】BizTalk と Windows Azure の連携

環境 :
BizTalk Server 2009
Visual Studio 2008 SP1
WCF LOB Adapter SDK SP2
.NET Services SDK (July 2009 CTP) 

こんにちは。

つぎは、失敗した S + S のデモの補足です。オオトリのデモで失敗すると悲惨な結果になる (セッション全体が無意味なものに思える。。。) という教訓を本日学びました。。。 (失敗した理由は、Relay バインディングのポートが空いていなかったことが原因でした。すみませんでした。。。)

デモで使用していた WCF のアダプターは、以下から入手できます。(方法を下記に記載します)

CodePlex : BizTalk Azure Adapters SDK (CTP)
http://btsazureadapters.codeplex.com/

なお、上記は現在、64 bit 版しか配布されていませんが、使用しているセットアッププロジェクト (インストーラプロジェクト) が64 bit 版になっているだけですので、セットアッププロジェクトの処理を 32 bit 対応 (カスタム動作のソースコードの変更、など) にすると 32 bit 環境でもちゃんと動作します。 ソースコードもすべて公開されていますので、そのまま鵜呑みにしてしまうのではなく、本日セッションで紹介したテクノロジの理解をベースに中身 (ソースコード) の接続方法を理解しておくと良いでしょう。(実運用でいろいろと応用も効きます。ソースコードでは、本日説明した WCF LOB Adapter SDK を使用したアダプターを使用しています。)

上記で、ソースコード (BizTalk Azure Adapters SDK 1.0 CTP - July 2009) をダウンロードして unzip すると、以下のフォルダが展開されます。

[ディレクトリ構成]

  • BizTalk ISB Adapter (.NET Services のサービスバスと接続するアダプタと、それを使ったサンプルです。)
    • Cloud Services (BizTalk プロジェクト, .NET Services に登録するサービス, ホストプログラムのそれぞれのサンプルが入っています)
    • End (ISBアダプター本体のソースコードと、そのインストーラが含まれます)
    • Install
  • BizTalk LiveMesh Adapter (同様に LiveMesh 用のアダプターなどが含まれます。今回は省略します。。。)
  • Referenced Assemblies (上記のプロジェクトで参照している dll が入っています。ビルドで必要になります。)

Visual Studio で BizTalk ISB Adapter\End\End.sln を開くと、今回使用するすべてのプロジェクトが参照できます。

  1. まず、使用するプロジェクトの構成を記載します。
    • CloudServices\ISBServiceTester
      サービスバス (.NET Services) に登録されるサービスとホストプログラムのサンプルです 
    • CloudServices\BizTalkClient
      BizTalk プロジェクトのサンプルです
    • ISBAdapter
      ISBアダプターそのものです
    • Setup\ISBAdapterSetupCustomAction
      ISBアダプターのインストーラで実行されるカスタムアクションです。この中で、%windir%\Microsoft.NET\Framework64 下の machine.config への書き換えなどをおこなっていますので (本日セッションでご説明した、machine.config へのバインディング構成の追加です)、32 bit 環境では、ここのソースなどを書き換える必要があります。
    • Setup\ISBAdapterSetup
      セットアッププロジェクトです

  2. 上記で、ソースコード (BizTalk Azure Adapters SDK 1.0 CTP - July 2009) を展開した際の Referenced Assemblies フォルダで使用されている dll のバージョンに注意してください。例えば、私の環境では、.NET Services SDK の July 2009 CTP を使用しているため、Referenced Assemblies\Microsoft.ServiceBus.dll を自分の環境にあわせて入れ替えました。  (GAC 内のアセンブリとバージョンをそろえておきましょう。)

  3. セットアッププロジェクト (Setup\ISBAdapterSetup) をリビルドし、ビルドで作成された setup.exe を実行すると、本日ご説明した WCF LOB Adapter の dll の GAC 登録や、サービスバス接続用のバインディングが (machine.config に) 登録されます。

  4. CloudServices\ISBServiceTester の Program.cs に、.NET Services に接続するための SolutionName, Password が記載されていますので、これを皆さんの (.NEt Services の) アカウントに変更してください。

  5. CloudServices\BizTalkClient をリビルドし、配置してください。ただし、配置前にプロジェクトのプロパティで、展開先を (皆さんの) 環境にあわせて変更しておきましょう。

  6. 展開した BizTalkClient のバインドを構成します。バインドは、上記の展開したフォルダのInstall\Bindings\TechReady9.HOL.ISBAdapter.xml に入っていますので、これをインポートすれば OK です。(ただし、アプリケーション名として TechReady9.HOL.ISBAdapter という名前が使用されていますので、アプリケーション名を変えてしまった方は、こうした文字列も変更してからインポートする必要があります。)

  7. オーケストレーションのバインド構成で、今回は、送信ポートを [Send Message to Cloud]、受信ポートを [Receive Message from File System] に設定しましょう。



  8. 送信ポートの [Send Message to Cloud] のプロパティで、以下を変更しておきましょう。
    • [資格情報] として、.NET Services のソリューション名とパスワードを設定します。 
    • [Assembly] として、Cloud Services\TestClient\bin\Debug\Microsoft.Azure.Samples.ISBServiceTester.exe (のフルパス) を設定します。



  9. 受信ポートの [Receive Message from File System] の受信場所のプロパティを存在するフォルダに変更しておきましょう。

上記でプロジェクトの準備は完了です。

ISBServiceTester (.NET Services の WCF サービス) を起動して、上記で配置した BizTalk アプリケーションを開始しておきます。(受信用のディレクトリが Polling されます。)
上記の受信用のディレクトリに、何でも構いませんので作成した XML ファイルを置くと、ポーリング時間を経過した際に BizTalk がサブスクライブし、.NET Services に記述内容が通知されます。

なお、ISBServiceTester のソースコードでは、Cloud Services (.NET Services) への Receive と Send の双方が可能なように構成されていますので、多少複雑なソースコードになっている点に注意してください。。。

デモでは、SharePoint との連携のパターンも用意していましたが、これもまた出来ずに (時間がなく)、まったくお伝えしたかったポイントをお話できませんでした。SharePoint との連携については、以前、下記に掲載しましたのでご参照ください。(度々、すみません。。。)

SharePoint と BizTalk の連携 :
http://blogs.msdn.com/tsmatsuz/archive/2008/04/30/sharepoint-biztalk-1.aspx

このセッション後半で述べたかったポイントは以下です。

SharePoint のワークフロー、BizTalk のオーケストレーション、さらに .NET Services (Azure) にもワークフローサービスなどもありますが、それぞれは似た手法が重複して提供されているのではなく、目的 (用途や、アーキテクチャ上の位置づけ) が異なるという点を理解しておくことが重要です。
上記は非常に些細なサンプルですが、例えば、LiveMesh を経由して外 (取引先、派遣先、など) から登録されたデータを元に社内のオーケストレーションを稼働させるケースや、逆に、企業内で回覧され、Fix された内容を外に出して関係先 (外の企業) に情報を回覧するケース、あるいは、SharePoint で部門内で承認された情報をもとに企業内(エンタープライズ) の部門間で処理を連携させるケースなど、さまざまな組み合わせがあります。部門内やヒューマンワークフローで活躍する SharePoint と、社内の (部門を超えた) エンタープライズレベルでのオーケストレーション、外 (クラウド上) の関係者 (関係組織) 同士を連携する ISB (Internet Service Bus) としてのワークフローサービス (.NET Services) など、それぞれを適材適所に組み合わせて全体を構成しますが、WCF は、こうした全体の「系」の中で、セッションでご説明したWCFならではの特徴を生かした「道具」として利用される ( = WCF 自体が何かを解決するわけではない) という点を理解しておいてください。

WCF の特徴とメリットを理解し、「だから、ここで、こんな役割で使われているのかぁ」 という点を理解しておくことが重要です。(例えば、ADO.NET Data Services の内部でも使用されています。) WCF は、システム全体を構成する上で欠かせない「道具」です。

 

 

Posted by tsmatsuz | 0 Comments
Filed under:

【T2-310補足1】.NET における REST サービスのコンシューマ実装

環境 :
Visual Studio 2008 SP1
WCF REST Starter Kit (Preview 2)

こんにちは。

Tech Ed  2009 セッション T2-310 では、またまた時間がなく、大変失礼致しました。例により、説明割愛した箇所を補足致します。

まずは、デモでお見せした WCF REST Starter Kit によるコンシューマ実装についてです。 (ご説明した、「必要な事前設定」という点も記載します。)

その前に、コンシューマ実装の全体を少し復習しておきましょう。(この説明も、かなり駆け足になってしまいましたので。。。)

REST クライアント (コンシューマ) の実装方法 (全体)

例えば、ASP.NET においても jQuery がサポートされているため、ASP.NET MVC などビュー内で閉じた実装をおこなう場合には、こうしたライブラリを組み合わせてコンシューマ (クライアント) を構築することもできます。

MSDN マガジン : jQuery によるリッチなクライアント スクリプトについて
http://msdn.microsoft.com/ja-jp/magazine/dd453033.aspx

以下では、こうした実装方法を除き、Microsoft が提供しているテクノロジ (特に .NET 周り) を使用して REST のコンシューマを作成する数々の方法について整理しましょう。

  • HttpWebRequest (または WebClient) を使用した実装

    .NET で HTTP 通信のクライアントを実装する際に使用されるお馴染みの手法です。取得したデータは、XmlReader の使用、LINQ to XML を使用したクエリなどで処理することができます。
    もっともオーソドックスで素直な手法ですが、この方法だと、ストリームの処理、XML の構文解析 (または、xsd を使用したクラスへのデシリアライズ処理) などを自前で実装することになります。

  • ASP.NET AJAX, Microsoft AJAX Library (ASP.NET AJAX のクライアントライブラリ) のプロキシを使用した実装

    JavaScript ライブラリである Microsoft AJAX Library 内で定義されている Sys.Net.WebServiceProxy などを使用して Json フォーマットのサービスと通信できます。(サーバサイドの ASP.NET AJAX ライブラリも、最終的にはこの Microsoft AJAX Library を使用しています。かなり以前に記載した記事ですが、ASP.NET AJAX の内部のメカニズムについては http://www.atmarkit.co.jp/fdotnet/aspnetajax/aspnetajax02/aspnetajax02_01.html に記載しています。)
    この手法は、通信相手が Json シリアライズに限定される点だけでなく、通信相手として .NET の Web サービスやWCF サービスを強く意識して実装されているため、一般的な REST サービス (.NET 以外で構築されている RESTful サービスなど) でこの手法を使用することはむずかしくなるので注意してください。

  • ADO.NET Data Services のライブラリ (フレームワーク) を使用した実装

    ADO.NET Data Services のフレームワーク (内部では WCF が使用されています) を使用すると、Visual Studio から [サービス参照の追加] メニューを使用して REST サービスに接続するクライアント側のプロキシを簡単に生成できます。また、書籍「.NET 開発テクノロジ入門」で小高も記載していますが、ASP.NET AJAX 4.0 (現在は、この Preview 版が出ています) では、クライアントサイド (ブラウザ側) の JavaScript で同様の処理をおこなうこともできます。
    この方法は大変便利な手法ですが、上記の WCF の場合と同様、ADO.NET Data Services を強く意識した作りになっているため、ADO.NET Data Services 以外の REST サービスとの接続向けではないので注意してください。

  • DataContractJsonSerializer, Json.NET を使用した実装

    .NET Framework 3.5 (Visual Studio 2008) では、Json フォーマットのデータのシリアライズを扱える DataContractJsonSerializer クラス (System.ServiceModel.Web.dll に定義) が含まれています。
    このクラスは、その名の通り WCF での Json フォーマットの扱いを考慮して提供されているクラスですが (つまり、そもそも今回のようなクライアントから使うためのもの、というよりは、WCF が提供するクラスを間借りして処理するイメージです)、CodePlex で入手できる新しい Json.NET では、.NET オブジェクトと Json フォーマット間でのシリアライズ / デシリアライズをより簡単に扱えるクラスや、Json フォーマットのデータを LINQ のクエリなどで扱える LINQ to JSON など、REST サービス / コンシューマ開発で使用することを想定したいくつかの便利なクラスが含まれています。
    これらは .NET のコードであるためサーバサイドで使用するアプローチですが、Silverlight で使用することで、クライアントサイド (ブラウザ側) の処理でもこれらのクラスを使用することができます。(LINQ to JSON は、既に Silverlight 2 から追加されています。)

  • HttpClient を使用した実装

    セッションでご紹介した CodePlex の WCF REST Starter Kit を使用します。(WCF REST Starter Kit は、今後 Visual Studio 2010 で追加される予定です。ただし、どの機能が含まれるかは現時点では未定です。)
    .NET を使った実装アプローチですが、実装方法の詳細は後述します。

  • WCF の Channel を使用したアプローチ

    セッションでもご説明したように、クライアント側で WCF (ChannelFactory など) を使って REST のサービスに接続することも可能です。(この場合も、同様に、.NET によるコードです。)
    この実装では、

    - WCF の svcutil.exe ではなく ChannelFactory を使用した接続 (ただし、ClientBase<> を使用して自身でプロキシコードを作成することでプロキシを使用した接続も可能です)
    - クライアント側の Contract にも UriTemplate を設定 (これを設定しないと、クライアントが URL を理解できません)
    - WCF の DataContractSerializer の変わりに、XmlSerializerFormat を使用

    といったプログラミングになります。下記のブログに方法 (コード) が記載されていますので参考にしてください。

    http://blogs.msdn.com/pedram/archive/2008/04/21/how-to-consume-rest-services-with-wcf.aspx

    この手法は、通信相手が WCF である場合には非常に「美しい」手法ですが、その他の REST サービスとの相互連携には向かない点や (Contract を定義する必要がある、など)、最近主流の AtomFeed などを扱う場合などには、結局、実装技術に依存する (Atom10FeedFormatter などが返るため) などの点があることを理解しておいてください。

HttpClient (WCF REST Starter Kit) を使用した接続

この方法は見ていただくように大変扱いやすい手法ですが、まだ日本で動かしている人は少ないかもしれないので (実は下記で記載するように一部に日本語の問題があります)、手順詳細を記載します。(セッションで説明しなかった事前設定についても記載します。)

まず、このあと使用する WCF REST Starter Kit (Preview 2) の [Paste Xml As Types] メニューですが、ソースに一部不備があるため、英語版以外の Visual Studio ではこのメニュー出て来ないでしょう。ですので、現状は、以下の通り修正してから使用してください。(まだ Preview 版ですので、今後修正されるのをお待ちください。)

  1. %ProgramFiles%\Microsoft WCF REST\WCF REST Starter Kit Preview 2\WCF REST Starter Kit Preview 2.zip を展開します (ソースコードが展開されます)
  2. PasteXmlAsType プロジェクトが入っているため、このプロジェクトを Visual Studio で開いて、Connect.cs の 80 行目を下記の通り修正してください。(この PasteXmlAsType プロジェクトは、本来、カスタマイズ用に提供されています。)

    [現在]
    CommandBarControl pasteControl = (CommandBarControl)toolsPopup.CommandBar.Controls["Paste"];
    [日本語用の Fix]
    CommandBarControl pasteControl = (CommandBarControl)toolsPopup.CommandBar.Controls["貼り付け"];

ビルドをおこない、Visual Studio をいったんすべて終了し、コンパイルされた .dll と、プロジェクト内にある PasteXmlAsType.AddIn を%MyDocuments%\Visual Studio 2008\Addins に配置します。(Addins フォルダがない場合は、新規作成してください。)
Visual Studio を起動すると、[編集] メニューの中に [Paste Xml As Types] メニューが追加されているはずです。(もし追加されない場合は、念のため、devenv.exe /resetaddin <プロジェクト> で起動してみてください。)

では、本題の、HttpClient を使用したプログラミングに入っていきましょう。

まず、REST のサービスをあらかじめ作成しておきましょう。WCF でも、ADO.NET Data Services でも、PHP や Java で構築したサービスでも、インターネット上のサービスでも何でも構いません。

クライアントとして、今回は、コンソールアプリケーションのプロジェクトを新規作成して、以下を参照追加します。

  • %ProgramFiles%\Microsoft WCF REST\WCF REST Starter Kit Preview 2\Assemblies 下
    • Microsft.Http.dll
    • Microsoft.Http.Extensions.dll

以下の名前空間を追加します。(2 つ目も必ず入れておいてください)

using Microsoft.Http;
using System.Xml.Serialization;

接続先の REST のデータをブラウザなどで表示し (下図)、そのソース (XML) をコピーします。

そして、Visual Studio の上記クライアントプロジェクト上で、メニュー [Paste Xml As Type] を選択して貼り付けます。

この「貼り付け」をおこなうと、素敵なことに、XML のデータがシリアライズ可能なクラスのコードとしてソースコード上に貼り付けられます。
例えば、上図の XML の場合、生成されるソースコードは以下の通りになります。

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.4016")]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true)]
[System.Xml.Serialization.XmlRootAttribute(Namespace = "", IsNullable = false)]
public partial class OrderItems
{
    private OrderItemsOrderItem[] orderItemField;
    [System.Xml.Serialization.XmlElementAttribute("OrderItem")]
    public OrderItemsOrderItem[] OrderItem
    {
        get { return this.orderItemField; }
        set { this.orderItemField = value; }
    }
}
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.4016")]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true)]
public partial class OrderItemsOrderItem
{
    private byte idField;
    private string nameField;
    private ushort valueField;
    public byte id
    {
        get { return this.idField; }
        set { this.idField = value; }
    }
    public string name
    {
        get { return this.nameField; }
        set { this.nameField = value; }
    }
    public ushort value
    {
        get { return this.valueField; }
        set { this.valueField = value; }
    }
}

このコードですが、.xsd なしでコード生成されているため、ある程度予測に基づいて生成される点に注意してください。例えば、本来文字列を返している要素でも、たまたま int 型しか返していない場合には int 型に設定されているかもしれません。ですので、生成された型などをチェックし、必要に応じて修正しておきましょう。(要は、.xsd でクラス生成を実行する手間を省いてくれている、と考えるべきでしょう。)

さいごに、生成されたコードにあわせて、下記の通り Main のコードを作成してみましょう。

static void Main(string[] args)
{
    HttpClient client = new HttpClient();
    HttpResponseMessage res = client.Get(@"http://localhost:25631/Service1.svc/orders");
    OrderItems items = res.Content.ReadAsXmlSerializable<OrderItems>();
    foreach (OrderItemsOrderItem item in items.OrderItem)
    {
        Console.WriteLine(item.name);
    }
    Console.ReadLine();
}

このように、デシリアライズ (逆シリアライズ) の手間も省き、GET、POST などの Verb もメソッドとしてそのまま呼び出せるため、意味的にわかりやすくクライアントを構築することができます。 

ADO.NET Data Services のサービスについても、同様の手法でアクセスできます。
以下はそのサンプルですが、Data Services が返すフィードの構造を多少理解しておく必要があるという点に注意しておいてください。(Data Services が返すフィードでは、データは Content の中に XML として含まれています。)

static void Main(string[] args)
{
    HttpClient client = new HttpClient();
    HttpResponseMessage res = client.Get(@"http://localhost:9583/MatsuDataService.svc/TypeAInvoice");
    feed feeds = res.Content.ReadAsXmlSerializable<feed>();
    foreach (feedEntry entry in feeds.entry)
    {
        Console.WriteLine(entry.content.properties.name);
    }
    Console.ReadLine();
}

上述した Json.NET が .NET 上で Json を扱える汎用的な (実装技術などに依存しない) 仕組みであるのに対して、この HttpClient は、POX など XML 形式のリソースを汎用的に扱える .NET の仕組みであると整理しておくと良いでしょう。

なお、HttpClient は、現在 (Preview 2 では)、残念ながら Silverlight に未対応ですが、今後の対応状況などについては Silverlight Web Services チームブログをウォッチしておくと良いでしょう。

Silverlight Web Service チームブログ :
http://blogs.msdn.com/silverlightws/

WCF REST Starter Kit は、セミナーでも説明したように Visual Studio 2010 で標準で含まれる予定です。(ただし、どの機能が含まれるかは現時点では未定です。)

 

Posted by tsmatsuz | 0 Comments
Filed under:

2009年10月号は "Windows 7 らしさをプログラミングしよう"

こんにちは。

Windows 7 プログラミングの連載シリーズですが、2009年10月号の日経ソフトウェア では「Windows 7 らしさをプログラミングしよう」と題して、ジャンプリスト (Jump List)、タスクバー (Task bar) のプログラミングを紹介しています。

日経ソフトウェア 2009年10月号 :
http://itpro.nikkeibp.co.jp/article/MAG/20090820/335628/

タスクバー、ジャンプリスト関連のプログラミングのディテール(どんなプログラミングが可能か)は、Windows 7 SDK のサンプルコードを参照してください。上記では、ネイティブコード開発者、マネージコード開発者向けに、その「ベース」がわかるよう紐解いて (コード付きで) 解説しました。(Tech Ed 2009 では、こうした手法に加え、Touch、Sensor API など、Windows 7 アプリケーション開発手法の全体を紹介するセッションもありますのでご期待ください。)

私の記事は今回 "短め" ですが、今回の 10 月号では、この他に、Visual Studio 2010 の魅力の新機能の簡単解説 (図入り) や、並列プログラミング、F# などの簡単解説、さらに、Windows 7 / R2 の製品版の実測データに見る実力など、魅力的な記事がいくつか掲載されています。

今後の予定 (連載 : Windows 7 プログラミング) :

  • UAC を考慮したアプリケーションの作り方 (2009年11月号)
  • 「エコ」なプログラミングテクニック (2009年12月号)
    . . . つづく

追記 : Windows 7 のプログラミングコンテスト「Code 7」が開始されています。皆さんの頭の中のアイデアを披露して、ロサンゼルス (PDC 09) 行きのチケットを Get できます ! (期限 2009年10月10日まで)

http://msdn.microsoft.com/ja-jp/library/ee348020.aspx

 

Posted by tsmatsuz | 0 Comments
Filed under:

WCF REST Starter Kit を学ぶ

こんにちは。

WCF REST Stater Kit (現在は Preview 2, CodePlex より入手可能です) のドキュメントが整備されてきました。昨年の PDC 前に発表されて以来、先行して使っていた方も多いかもしれませんが、Tech Ed 2009 (Japan) でも紹介する予定です。(その多くの機能は、Visual Studio 2010 に含まれる "予定" です。)

まず、ご存じない方のために、これはいったい何者でしょうか ?

ご存じの通り、WCF を使用した RESTful サービスの開発は .NET Framework 3.5 (Visual Studio 2008) 以降で充分可能です。しかし、REST の開発を "ちゃんと", あるいは "扱いやすく" 構築するには、"Simple な REST" と言えどもいろいろと配慮すべきことが沢山あります。
例えば、オブジェクトの作成 (Create) 時は、ステータスコード 200 ではなく別のステータスコードを返す必要があります。アイテムが存在しないときには 404 (Not Found) をちゃんと返してますか ? また、REST ではメタデータ交換とか wsdl なんて面倒なものもありませんから、コンシューマー向けのヘルプシステムの作りこみも重要です。AtomPub のサービスもちゃんと作ろうと思うと結構面倒になるでしょう。
ざっくり書いてしまうと、そうした多くの実装をロジックの実装と分離して簡素化してくれるのが、この WCF REST Starter Kit です。(実装の概念は、現在の .NET Framework 3.5 (Visual Studio 2008) と大きく変わりませんので、使用する上で抵抗も少ないでしょう。)

まず、ざっと把握しておきたい方には、Channel 9 がおすすめです。

WCF REST Starter Kit で singleton services を構築する :
http://channel9.msdn.com/shows/Endpoint/endpointtv-Screencast-Building-resource-singleton-services-with-the-WCF-REST-Starter-Kit/

WCF REST Starter Kit で collection services を構築する :
http://channel9.msdn.com/shows/Endpoint/endpointtv-Screencast-Building-resource-collection-services-with-the-WCF-REST-Starter-Kit/

WCF REST Starter Kit で Atom フィードのサービスを構築する :
http://channel9.msdn.com/shows/Endpoint/endpointtv-Screencast-Building-Atom-feeds-with-the-WCF-REST-Starter-Kit/

WCF REST Starter Kit で AtomPub のサービスを構築する :
http://channel9.msdn.com/shows/Endpoint/endpointtv-Screencast-Building-AtomPub-services-with-the-WCF-REST-Starter-Kit/

WCF REST Starter Kit の API を使用した拡張 (Part 1) :
http://channel9.msdn.com/shows/Endpoint/endpointtv-Screencast-A-lap-around-the-new-API-extensions-for-REST-Part-1/

WCF REST Starter Kit の API を使用した拡張 (Part 2) :
http://channel9.msdn.com/shows/Endpoint/endpointtv-Screencast-A-lap-around-the-new-API-extensions-for-REST-Part-2/

Tech Ed 2009 では、WCF REST Stater Kit を使用したクライアント(コンシューマ)開発などについても説明します。 

また、The .NET Endpoint のチームブログ で紹介されていますが、WCF REST Stater Kit を使用した網羅的な機能紹介 (開発者ガイド) もリリースされています。

MSDN : A Developer's Guide to the WCF REST Starter Kit
http://msdn.microsoft.com/en-us/library/ee391967.aspx

 

Posted by tsmatsuz | 0 Comments
Filed under:

MSDN Flash (08/11 号) の答えあわせと . . .

こんにちは。

MSDN Flash 08/11 号で、以下のような記事を投稿しました。

プログラマの皆様に出題です。64 ビット環境で、以下のコードを見つけたら、皆さんなら放っておきますか?

int i1 = -2;
unsigned int i2 = 1;
char *s = "Hello";
printf("%s", s + 1 + (i1 + i2));

このコードは、32 ビット環境では "Hello" と表示されます。しかし、64 ビット環境では必ず修正してください。
では、以下のコードはどうでしょう?

char s[10];
memset(s, 0, 10);
double *val = (double*) (&s[2]);
printf("%lf\n", *val);

Itanium も視野に入れている方は、やはりこのコードは "必ず" 修正をお願いします。

 

この記事ですが、何名かの方から、「答えがわからなくて すっきりしない !」 など、フィードバックをいただきました。ありがとうございました。

そんな皆さんのワダカマリを受け、この1問目の答えを 今日ご紹介するエバンジェリスト 岩田雅樹 が、そのブログの中ですっきりと紹介してくれています ! (きっと、2 問目も 回答してくれるのかもしれません . . . 祈りましょう . . .)

http://blogs.msdn.com/masaki/archive/2009/08/11/msdn-flash-2009-8-11-no-330-1.aspx

岩田は、エバンジェリストとしては初めて聞く名前かもしれませんが、Tech Ed 2009 の「64ビットアプリケーション開発のポイント」のセッションでは、私が経験不足なカーネルモードドライバー開発などの分野をフォローしてもらい、セッションに共同登壇してもらう予定です。
また、今後も、プラットフォーム系、とりわけ、Windows 7 / R2 など新しいプラットフォームも含めた観点で、より「気づき」のある切り口で、OSの根幹の部分などを中心に情報発信をしてもらえると思いますので、こうした分野に興味のある方は、今回の「解答」のみならず、今後も、岩田ブログ にご注目いただくといろいろ得られるものがあるかもしれません。(私のブログの中でも、こうしたプラットフォーム系のコアな部分の記述は縮小傾向にしようと思います。)

 

Posted by tsmatsuz | 0 Comments
Filed under: ,

書籍「.NET 開発テクノロジ入門」の変更点

こんにちは。

「.NET 開発テクノロジ入門」の本ですが、2009/08/03 販売開始予定ですので、そろそろ店頭に並んでいるかもしれません。

本書の Windows Azure の章 (p.342) で 「変更される可能性があるのでご了承ください」 と記載しているように、Windows Azure など CTP 版の内容については、CTP のリリースに際し、いくつかの名称変更 / Design Change などが入っているものがあります。

下記に、その一覧 (現在までに変更されたもの) を列挙しますので、書籍をご購入された方は是非ご参照ください。

  • p.341 - (Windows Azure の章全般) :
    書籍では、March 2009 CTP 版をベースとして作成していますが、現在、July 2009 CTP 版が最新リリースであり、一部、画面のイメージや、選択可能な項目などが変更されていますのでご注意ください。(大きな流れは変わりません。)
    特に、「Hello Azure」のサンプルでは [Web Cloud Service] のプロジェクトテンプレートを選択していますが、July 2009 CTP ではこのプロジェクトテンプレートは存在していません。このため、一旦 [Cloud Service] のプロジェクトテンプレートを選択して、その際に表示されるウィザードで [ASP.NET Web Role] を追加してください。(同一のプロジェクトが新規作成されます。)

  • p.193, p.375, p.400 などで随所に登場する「Azure Services Platform」という用語ですが、「Windows Azure Platform」に名称変更されました。

  • p.399 :
    SQL Services」という用語は「SQL Azure」に名称変更、「SQL Data Services」と呼んでいたデータベースの中核部分は「SQL Azure Database」に名称変更されました。

  • p.383 - (A.7 「.NET Serviecs ワークフローサービス」全般) :
    July 2009 CTP (現在) では、カスタマーフィードバック反映のため、ワークフローサービスの機能 (サービス) が削除されています (使用できません)。特に、書籍 p.392 や、こちらのコラム でも記載したように、WF 4.0 も見据えた機能強化を現在実施していますので、使用に際しては、お手数ですが以降のリリースをお待ちください。(下記に、背景など詳細をアナウンスしています。)
    http://blogs.msdn.com/netservicesannounce/archive/2009/06/12/upcoming-important-changes-to-net-workflow-service.aspx

 

Posted by tsmatsuz | 0 Comments
Filed under: ,

WF 4 への移行ガイダンス (Beta 1)

環境 :
.NET Framework 4.0 Beta 1

こんにちは。

WCF / WF (.NET Endpoint) のチームブログ にも記載されていますが、TechDays でも予告しました通り、米国の WCF / WF チームから、WF 4 移行のための Cookbook / ガイダンスが提供されています。

WF 4 Migration Guidance :
http://www.microsoft.com/downloads/details.aspx?FamilyID=bd94c260-b5e0-4d12-93ec-53567505e685&displaylang=en

TechDays 2009 でも、もっとも多かったご質問がこの「移行方法」に関してでした。やはり気になりますね。
内容詳細は上記のドキュメントを参照して頂きたいと思いますが (すみません、まだ英語です)、重要なポイントとしては、一部、TechDays 2009 などでもご紹介したように、

  • WF 3 のアプリは、.NET Framework 4.0 になってもそのまま動作します
  • Visual Studio 2010 による WF 3 ソリューションの新規作成 / 編集をフルサポートされます
  • Interop Activity (WF 4.0 上で WF 3 のアクティビティをラッピングして使えるアクティビティ) を提供します

という点と、あともう 1 つの新しいポイントとして、WF 3 から WF 4 へのコンバージョンツールのサポートが "予定" されているという点です。(これについては、まだ「予定」なので注意してください。アクティビティ定義のツリー、フィールド / プロパティの値などのマイグレーションが予定されていると書かれています。)

WF 3 がそのまま動くということで、WF 4 へのプロジェクト / モジュールの移行がつぎの関心時になってくると思いますが、上記で提供されているドキュメントは、主に、この観点でのドキュメント (つまり、WF 3 からの Redesign のための「クックブック」と、WF 3 から WF 4 に直接マップできないケースなど、状況に応じた「ガイダンス」) を提供しています。

このガイダンスの読み方ですが、まず、WF 4 を少なくともある程度は理解してから読んでください。WF 4 については、日本では TechDays 2009 でご紹介していますが、以降もいくつかアップデートが入っていますので、今後の日本でのイベントや、速めにキャッチしたい方は米国の情報など (例えば、US での Tech Ed の内容など) をご参照ください。WF 4 のベースが理解できたところで、皆さんが構築されている具体的なプロジェクトの気になるポイント (例:「・・・って、WF 4 になったらどうすれば良いんだろう ?」) を上記の Cookbook / Guidance で学んでいくと効果的に理解できます。

ざっくりですが、「CodeActivity の乱用は避けてください」とお願いしていた通り (書籍「.NET 開発テクノロジ入門」でも同様の注意を Note として記載しておきました)、WF 4 は XAML ベースで組んでいきますので、コードビサイドのロジックは、カスタムアクティビティとしてリパッケージなどをする必要があるので注意してください。特に、CodeActivity、アクティビティのイベントハンドラを使っている場合には、コードの内容などに応じて独自に移行が必要となります。

  • あるアクティビティ内のプロパティから別のアクティビティのプロパティへの直接的なバインドはおこなわないこと。
    (かならず、ワークフロー変数を作成するなどして、アクティビティ間でバインドする。)
  • WF 4 のカスタムアクティビティでは、コンセプトそのものは WF 3 のカスタムアクティビティと類似。ただし、既存の手法に変わるいくつかの新しい API を提供しているので、アクティビティが提供する API やメソッドを使っている場合には注意。

などなど、の抑えておくべきポイントが Cookbook / Guidance で紹介されています。(コンバージョンツールが出てきたら、また多少アップデートされるとは思います。)

 

 

Posted by tsmatsuz | 0 Comments
Filed under: , ,
More Posts Next page »
 
Page view tracker