Windows Azureアクセス制御に対するUpdate

12月 26th, 2011

先週、Windows Azure TeamのBlogにて、Windows Azureアクセス制御 (ACS) に関するいくつかのUpdateがアナウンスされています。

ACS自体、まだまだ広く利用されているサービスではないせいか、影響を心配する声はあまり上がっておりませんが、現在ACS 1.0を利用している方は注意が必要です。

Team Blogにてアナウンスされている内容は以下の通りです。

  • プロモーション期間を2012年12月1日まで延長
  • ACS 1.0からのマイグレーションツールの提供
  • ACS 1.0サービスを2012年12月20日で終了

 

まず、プロモーション期間の延長ですが、これはACSが来年12月1日まで無料で利用できるプロモーションです。このプロモーション期間が2012年の12月1日まで延長されるので、2012年中はほぼ無料でACSを利用することができます。ACSを試してサービスの利用を検討するならば、2012年中に検証を実施しておくことをお勧めします。

次にACS 1.0の舞具レーションツールの提供ですが、これは2012年12月20日にサービスの提供を終了するACS 1.0を利用しているユーザがACS 2.0に移行するためのツールを提供する旨のアナウンスです。

まずは、MSDNサイトに掲載されている移行ガイドライン(英語)を読み、移行条件を確認の上実施するようにしてください。

最後に、現在ACS 1.0のサービスを利用しているユーザは2012年12月20日までにACS 2.0ベースの認証方式に移行する必要があります。

ここで、何も書かれていないので見落としがちですが、実は現在提供されているWindows Azure サービス バスもACS1.0ベースの認証で実行されている点に注意が必要です。

このサービス停止はサービス バスの利用者にも影響する可能性があります。

現在、新規作成されるサービス バスはACS 2.0ベースの認証に変更されていますが、ACS 1.0ベースの認証でサービス バスを利用しているユーザは、サービス バスの再作成などが必要になる場合があります。

移行方法など、このブログでも追ってお知らせさせていただきます。

 

Windows Azure AppFabricサービス バスでのTopic利用

11月 7th, 2011

前回のポストで、Windows Azure AppFabricサービス バスにおけるQueueの利用についてご紹介しました。

前回も少しだけ触れましたが、パブリッシャ・サブスクライバ モデルを実現するためのTopicの利用も、Queue利用とほぼ同じ手順で利用できるという話をしました。

唯一異なる点は、1つのパブリッシャ(発行者)に対し複数のサブスクライバ(購読者)が存在するため、各Topic(発行される記事)に対して複数のSubscriptionを作成する必要がある点です。

各Subscriptionは必ず1つのTopicに属し、所属するTopicにポストされたメッセージを各サブスクライバに配信します。

一方、Topicにメッセージを発信する発信者はどのSubscriptionにメッセージを配信するかを意識する必要はありません。

Topicに対しメッセージを送信するだけで、自動的にTopicに属するSubscriptionに対してメッセージが配信されます。

それでは、実際にTopicにメッセージを層んするためのコードを見ていきましょう。

 

private Uri m_BaseAddress;
private string m_Issuer = “owner”;
private string m_SharedKey = “各Namespaceに対応するSharedKeyを指定する。”;
private TokenProvider m_TokenProvider;
private NamespaceManager m_NamespaceManager;
private MessagingFactory m_MessagingFactory;
private TopicClient m_TopicClient;

private void CreateAndSend(string messagebody)
{
//サービスバスのBaseAddressを生成
 m_BaseAddress = ServiceBusEnvironment.CreateServiceUri(“sb”, ”yournamespace”, string.Empty);
 //資格情報の作成
 m_TokenProvider
= TokenProvider.CreateSharedSecretTokenProvider(m_Issuer, m_SharedKey);
 //トピックの新規作成(同一名トピックが存在する場合、一旦削除する)
 m_ NamespaceManager = new NamespaceManager(m_BaseAddress, m_TokenProvider);
 if(m_ NamespaceManager.TopicExists(“NotifyTopic”))
m_ NamespaceManager.DeleteTopic(“NotifyTopic”);
 m_ NamespaceManager.CreateTopic(“NotifyTopic”);
 //メッセージファクトリの作成
 m_MessageingFactory = MessagingFactory.Create(m_BaseAddress, m_TokenProvider);
 //TopicClient作成
 m_TopicClient = m_MessageingFactory.CreateTopicClient(“NotifyTopic”);
 //Subscriptionを新規作成し、Topicと関連付ける
 m_NsManager.CreateSubscription(m_TopicClient.Path, “Category1″);
 m_NsManager.CreateSubscription(m_TopicClient.Path, “Category2″);
 m_NsManager.CreateSubscription(m_TopicClient.Path, “Category3″);
 //メッセージの送信
 m_TopicClient.Send(new BrokeredMessage(messagebody));
}

この例では、Topicの作成~メッセージの送信を一度に実行していますが、多くの場合には初期化時にTopicおよびSubscriptionの作成を実行しておき、適宜メッセージを送信することとなります。

したがって、初期化処理はサンプルコード中の最下部のm_TopicClient.Send()メソッドを除いた部分を実行しておけば大丈夫です。

それでは、サブスクリプション側のインプリメントを見ていきましょう。

 

private Uri m_BaseAddress;
private string m_Issuer = “owner”;
private string m_SharedKey = “各Namespaceに対応するSharedKeyを指定する。”;
private TokenProvider m_TokenProvider;
private SubscriptionClient m_SubClient;
private MessagingFactory m_MessageingFactory;
private void CreateSubscription ()
{
 //サービスバスのBaseAddressを生成
 m_BaseAddress = ServiceBusEnvironment.CreateServiceUri(“sb” ,  “yournamespace” ,  string.Empty);
 //資格情報の作成
 m_TokenProvider
  = TokenProvider.CreateSharedSecretTokenProvider(m_Issuer, m_SharedKey);
 //メッセージファクトリの作成
 m_MessageingFactory = MessagingFactory.Create(m_BaseAddress, m_TokenProvider);
 //サブスクリプション・クライアントの作成
 m_SubClient = m_MessageingFactory.CreateSubscriptionClient(NotifyTopic”,“Category1″);
}
private void TryReceive ()
{
 //メッセージオブジェクトの定義
 BrokeredMessage message;
 //メッセージの受信(1秒待ってメッセージが存在しない場合はパス)
 message = m_SubClient.Receive(TimeSpan.FromSeconds(1));
 if (message != null)
 {
  //メッセージが受信できた場合にメッセージ本文を表示
  MessageBox.Show(message.GetBody<string>(), m_SubClient.Name);
  //メッセージの処理の完了を通知
  m_SubClient.Complete(message.LockToken);
 }
}

 

この例では、CreateSubscriptionメソッドでSubscriptionを作成し、TryReceiveメソッドでメッセージを受信しています。

メッセージ形式はQueueと同様BrokeredMessageであることがわかります。

つまり、シリアライズ可能なオブジェクトをメッセージ本体に含めて送ることが可能です。

また、メッセージの処理が完了した後にSubscriptionClientのCompleteメソッドを忘れずに実行してください。

これを忘れてしまうと、再購読時に同一のメッセージを受信してしまいます。

言い換えれば、処理が完了するまではメッセージが保存されていますので、途中で失敗した場合には再度メッセージを受信することでリカバリが可能であるともいえます。

 

Windows Azure AppFabric SDK 1.5でのサービス バスQueueの利用

11月 2nd, 2011

以前のポストで、June CTP版のサービス バスQueueの利用法をご紹介しました。

September CTP版としてすべてのユーザがAppFabricサービス バスでQueueが利用可能になったのを受け、SDKの内容も変更されました。

June CTPのコードと比べ、若干ではありますがシンプルな手順で利用可能になっています。

まず、Microsoft.ServiceBus.dllを参照設定します。この手順は今までと同一です。

参照設定するDLLは「C:\Program Files\Windows Azure AppFabric SDK\V1.5\Assemblies\NET4.0\Microsoft.ServiceBus.dll」などのパスに存在します。

ただ、参照設定するDLLがCTPと比べ減っています。1つのDLLのみを参照設定すればよくなっているので、多少ではありますが手間が省けています。

続いて、サービスを公開するためのコードをご紹介します。

まずは、コードを見てみましょう。

 

private Uri m_BaseAddress;
private string m_Issuer = “owner”;
private string m_SharedKey = “各Namespaceに対応するSharedKeyを指定する。”;
private TokenProvider m_TokenProvider;
private NamespaceManager m_NamespaceManager;
private MessagingFactory m_MessagingFactory;
private QueueClient m_QueueClient;
private void CreateAndSend(string messagebody)
{
//サービスバスのBaseAddressを生成
 m_BaseAddress = ServiceBusEnvironment.CreateServiceUri(“sb”, “yournamespace “, string.Empty);
 //資格情報の作成
 m_TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(m_Issuer, m_SharedKey);
 //NamespaceClientの作成
 m_NamespaceManager = new NamespaceManager(m_BaseAddress, m_TokenProvider);
 //Queueの初期化
 if (!m_NamespaceManager.QueueExists(“YourQueue”))
 {
  //Queueの作成
  m_NamespaceManager.CreateQueue(“YourQueue “);
 }
 //MessageingFactoryの作成
 m_MessagingFactory = MessagingFactory.Create(m_BaseAddress, m_TokenProvider);
 //Queueクライアントの作成
 m_QueueClient = m_MessagingFactory.CreateQueueClient(“YourQueue “);
 //メッセージの送信
 m_QueueClient.Send(new BrokeredMessage ( messagebody));
}

 

この例では、Queueが全く存在してないことを想定して、Queueを作成することから始めています。

最初に、発行者(Issuer)と共有キー(SharedKey)を用いて、TokenProviderのインスタンスを作成しています。

このTokenProviderをもとにサービスバスに対して認証を実行しています。

続いて、Queueを初期化しています。

コメント中の「Queueの初期化」の部分がそれに該当します。指定したパスのQueueが存在しない場合のみ、新規にQueueを作成しています。

Queueの作成や削除などといったQueueの管理にはNamespaceManagerオブジェクトを利用します。

一方メッセージの送受信にはMessagingFactoryおよびQueueClientオブジェクトを使用します。

余談ですが、Topicを利用する場合にはQueueClientの代わりにTopicClientを利用するだけです。

メッセージはQueueClient.Sendを用いて送信します。メッセージはBrokeredMessageオブジェクトである必要があります。

ここであることに気づきませんか?

そう、Senderを作成していません。

June CTPではQueueClientからSenderおよびReceiverを作成してメッセージを送受信していました。

しかし、現在のバージョンではQueueClientが直接メッセージを送受信することができるように改良されています。

BrokerdMessageの本文に含めるオブジェクトはシリアライズ可能なすべてのオブジェクトを指定することが可能です。

メッセージ長は最大256KBですので、シリアライズ時のサイズが256KB以下のオブジェクトを指定しなければなりません。

それでは読み出しの部分を見てみましょう。

 

BrokeredMessage bm;
bm = m_QueueClient.Receive(TimeSpan.FromSeconds(1));
if (bm != null)
{
 string msg= bm.GetBody< string >();
 MessageBox.Show(msg);
 m_QueueClient.Complete(bm.LockToken);
}

 

QueueClientの作成までは送信時と同一のため、コードは割愛しました。

QueueClient.Receiveメソッドを利用して読み出しを実行しています。引数は取得までの待ち時間で、指定した時間以上経過した場合には読み出しを中止し、後続の処理を実行します。

メッセージ本文はBrokeredMessage.GetBodyメソッドで取り出すことが可能です。

処理が完了した時点でQueueClient.Completeメソッドを実行します。

これを実行することで、メッセージをQueueから消去することができます。

言い換えれば、これを忘れると何度も同じメッセージに対する処理を実行してしまうことになりますので、注意してください。

 

Service Bus Relay Endpointでロードバランスがサポートされました

11月 1st, 2011

ご無沙汰しております。

ここの所、いろいろと細かいところでバタバタしておりまして、なかなかブログ記事を更新できませんでした。

思えば、9月の//build/カンファレンスでAppFabricのサービス バスV2の提供開始がアナウンスされ、AppFabric SDK 1.5が提供されていたことをアナウンスしなければ・・・と思いつつ1カ月以上が経過してしまいました。

以前このブログでご紹介したQueueやTopicの利用法もCTPとは異なっていますので、近々AppFabric SDK 1.5で動作するコードをご紹介したいと思っております。

さて、そんな中。従来のRelay機能にもUpdateがありました。

かねてよりサポートされるとの予告があった、Service Bus Relay Endpointのロードバランスが利用可能になっています。

これは、複数のリスナ(サービスの提供側)が1つのエンドポイントを共有し、リクエストを分散して実行することが可能な機能です。

Service Busのロードバランサは最大25のリスナを同一のエンドポイントに割り当てることが可能です。

従来、以下のようなコードを書いていると、既にOpenされているエンドポイントと同一のエンドポイントを割り当てようとした時点でAddressAlreadyInUseExceptionがスローされてしまいました。

 

Uri address = ServiceBusEnvironment.CreateServiceUri(“sb”, serviceNamespace, “MyService”);

ServiceHost host = new ServiceHost(typeof(MyService), address);

host.Open();

 

しかし、ロードバランサが提供されると最大25リスナまでは、例外が発生することなくエンドポイントが利用可能になっています。

※ただし、1つのリスナがアクセス制御を有効にしているなどといった、特定の条件下ではAddressAlreadyInUseExceptionがスローする場合があります。詳しくは以下のURL(英語)をご参照ください。

http://msdn.microsoft.com/en-us/library/hh148155.aspx

 

なお、25リスナを超えるリスナがエンドポイントを利用しようとした場合は、QuotaExceededExceptionがスローされます。

また、細かな変更点ですが、AppFabric SDK 1.5より、Relayエンドポイントの構成情報をmachine.configに書き込まないように変更されています。

したがって、App.configまたは、Web.configに構成情報を記述する必要があります。

 

<configuration>

<system.serviceModel>

<extensions>

<!– Adding all known service bus extensions. You can remove the ones you don’t need. –>

<behaviorExtensions>

<add name=”connectionStatusBehavior” type=”Microsoft.ServiceBus.Configuration.ConnectionStatusElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”transportClientEndpointBehavior” type=”Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”serviceRegistrySettings” type=”Microsoft.ServiceBus.Configuration.ServiceRegistrySettingsElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

</behaviorExtensions>

<bindingElementExtensions>

<add name=”netMessagingTransport” type=”Microsoft.ServiceBus.Messaging.Configuration.NetMessagingTransportExtensionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”tcpRelayTransport” type=”Microsoft.ServiceBus.Configuration.TcpRelayTransportElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”httpRelayTransport” type=”Microsoft.ServiceBus.Configuration.HttpRelayTransportElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”httpsRelayTransport” type=”Microsoft.ServiceBus.Configuration.HttpsRelayTransportElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”onewayRelayTransport” type=”Microsoft.ServiceBus.Configuration.RelayedOnewayTransportElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

</bindingElementExtensions>

<bindingExtensions>

<add name=”basicHttpRelayBinding” type=”Microsoft.ServiceBus.Configuration.BasicHttpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”webHttpRelayBinding” type=”Microsoft.ServiceBus.Configuration.WebHttpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”ws2007HttpRelayBinding” type=”Microsoft.ServiceBus.Configuration.WS2007HttpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”netTcpRelayBinding” type=”Microsoft.ServiceBus.Configuration.NetTcpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”netOnewayRelayBinding” type=”Microsoft.ServiceBus.Configuration.NetOnewayRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”netEventRelayBinding” type=”Microsoft.ServiceBus.Configuration.NetEventRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

<add name=”netMessagingBinding” type=”Microsoft.ServiceBus.Messaging.Configuration.NetMessagingBindingCollectionElement, Microsoft.ServiceBus, Version=1.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

</bindingExtensions>

</extensions>

</system.serviceModel>

</configuration>

 

少々面倒な追記ではありますが、この記述を追加することで、サービスバスを利用するサービスのポータビリティも向上します。

もちろん、コード中でRelayバインディングを解決できるようにしておく方法も利用可能です。

「Windows Azureアプリケーション開発入門第2版 」発売のご報告

7月 27th, 2011

かねてより改訂作業を進めておりました書籍「Windows Azureアプリケーション開発入門 第2版」(日経BP社刊)が発売されました。

今日~明日中には主な書店に並ぶ予定です。

 

 

昨年3月に「Windows Azureアプリケーション開発入門」を出版させていただいて以降、皆さんもご存じのとおりWindows Azure Platformは大きく進化しております。

まだまだ進化は続くのですが、現段階でも書籍の内容と現状が大きく違っていることから、改訂して第2版として発売する運びとなりました。

また、Windows Azureだけでなくクラウドを取り巻く環境も大きく変わってきています。

初版発売直後はクラウドがまだ「バズワード」として扱われていた時期でした。しかし、現在はクラウドで提供されるサービスを当たり前のように利用するようになってきました。

また、スマートフォンやタブレット端末の普及に伴い、バックグラウンドのストレージに応用されるなど、クラウドの活躍する場面が大きく広がっているともいえます。

Windows Azure自体もサービスの成熟が進み、主要な機能が完成形を迎えようとしています。

同時に、開発環境や実行環境も初版当時とは大きく変わっております。

そこで、ほぼ「全面見直し」を敢行いたしました。

今回の目次構成にはかなり悩みました。どの機能を紹介するか。また、どのようなサンプル構成にするか。前版を踏襲しつつも、全面的に見直すところは見直す。

そして、「全部入り」にしたいところをグッと堪え、エンタープライズでの利用にフォーカスして内容を推敲するなどといった見直しを実施しました。

おそらく、皆さんが期待しているであろうVM Roleに関しては概要の紹介にとどめました。また、AppFabricのアクセス制御 (本書では「アクセスコントロール」と表記してあります。) や分散キャッシュも、執筆時点ではUpdateが予定されていたため、掲載を見送った機能です。

こうしたUpdateに関してはこのブログで引き続き補足していく予定です。

 

「Windows Azureアプリケーション開発入門 第2版」(日経BP社刊)

価格:2,940円(税込)

ISBN: 978-4-82229-459-5

AppFabricサービスバスにおけるQueueの取り扱い

6月 23rd, 2011

Windows Azure AppFabricサービスバスの新たなCTPではQueueとTopicによるメッセージングがサポートされています。

これにより、Windows Azure AppFabricサービスバスは従来からのWCFのRelayバインディング以外にメッセージングによる非同期型連携が追加され、より多様な利用シナリオに対応できるようになりました。

QueueおよびTopicでは256KB以下のシリアライズ可能なオブジェクトをメッセージとして送信することができます。そのため、ListやArrayでコレクションされたオブジェクトもそのまま送信することが可能です。

以下にQueueにメッセージを送信するコードの例をご紹介します。

 


Uri m_BaseAddress;
string m_Issuer = “owner”;
string m_SharedKey = “*************** Your Secret Key ****************”;
SharedSecretCredential m_ManagementCredential;
ServiceBusNamespaceClient m_NamespaceClient;
MessagingFactory m_MessagingFactory;
QueueClient m_QueueClient;
void Page_Load(object sender, EventArgs e)

//サービスバスのBaseAddressを生成
m_BaseAddress
= ServiceBusEnvironment.CreateServiceUri(“sb”, “yournamespace”, string.Empty);
//
資格情報の作成
m_ManagementCredential
= TransportClientCredentialBase.CreateSharedSecretCredential(
m_Issuer, m_SharedKey);
//NamespaceClient
の作成
m_NamespaceClient =
new ServiceBusNamespaceClient(m_BaseAddress, m_ManagementCredential);
//MessageingFactory
の作成
m_MessagingFactory
= MessagingFactory.Create(m_BaseAddress, m_ManagementCredential);
//Queue
の初期化
Queue qPOQueue;
try
{
//Queue
の作成
qPOQueue = m_NamespaceClient.CreateQueue(“POQueue”);
}
catch (MessagingEntityAlreadyExistsException) { } //
すでに当該Queueが存在する場合
//Queueクライアントの作成
m_QueueClient = m_MessagingFactory.CreateQueueClient(“POQueue”);
//QueueクライアントからMesseageSenderを作成
MessageSender ms = m_QueueClient.CreateSender();
//
メッセージの送信
BrokeredMessage bm
= BrokeredMessage.CreateMessage(
new PurchaseOrder(“20110623001″, “SLCYCLE”));
bm.Properties["Remarks"] =
プロパティも追加できます。“;
ms.Send(bm);

 

メッセージングにおいても、従来のRelay Bindingの利用と同様に、Shared Secretによる認証が必要です。

また、あらかじめサービスバスのエンドポイントのURIを作成しておきます。

ここでポイントとなるAPIが2種類あります。1つがServiceBusNamespaceClientです。このライブラリはQueueの作成や削除を実行することが可能です。

もう1つがMessagingFactoryです。このライブラリは、メッセージを送受信するためのQueueClientを作成するために必要となります。

これらのライブラリは直接連携することはありませんが、ServiceBusNamespaceClientを用いて作成されたQueueに関連付けるQueueClientはMessagingFactoryから生成されます。

QueueClientはMessageSenderを作成します。MessageSenderはメッセージを送信するためのライブラリです。

名前から想像するとMessageReceiverが存在するであろうことは容易に想像できるでしょう。事実、Queueからメッセージを受信するためのライブラリとしてMessageReceiverが存在します。以下のコードはメッセージを受信する例です。

 


MessageReceiver mr = m_QueueClient.CreateReceiver();
BrokeredMessage bm = BrokeredMessage.CreateMessage();
if (mr.TryReceive(TimeSpan.FromSeconds(2), out bm) == true)
{
MessageBox.Show(bm.GetBody<PurchaseOrder>().ToString());
mr.Complete(bm);
}

 

QueueのメッセージはBrokeredMessage型のメッセージとして送信します。メッセージはBrokeredMessageのCreateMessageスタティックメソッドで作成します。

この時、引数にシリアライズしたいオブジェクトを指定することでメッセージにオブジェクトを含めることが可能です。

それ以外にもBrokeredMessageにはPropertyやLabelといった追加情報を付加することが可能です。

以下のブロックダイアグラムは、各ライブラリの関係を示したものです。

 

 

Windows Azure AppFabricサービスバスのQueueはWindows AzureストレージのQueueと比較しても、送信できるメッセージ長およびメッセージの型に柔軟性があるため、多くの場面で利用されることが期待されるサービスです。

この流れがある程度理解できれば、Topicの理解も容易になります。

折を見て、Topicについても触れたいと思います。

 

Windows Azure AppFabric SDK V2.0 CTP6月版リリース

6月 21st, 2011

先月開催されたMicrosoft Tech・Ed North AmericaにてアナウンスされたWindows Azure AppFabric SDK 2.0の新たなCTPがリリースされました。

Tech・Edでアナウンスがあった通り、新たなWindows Azure AppFabric (現在はLaboで公開)は開発ツール、アプリケーション管理、そしてAppFabric Containerへのアプリケーション配置がサポートされています。

新たなSDKではVisual Studio用のツールとして「Windows Azure AppFabric Developer Tools」が提供され、このツールをインストールすることで、AppFabric SDKを含めた開発環境がインストールされます。

Visual StudioではAppFabricプロジェクトが作成可能であり、コンポジットアプリケーションが開発できるようになっています。

作成したモデルは、AppFabric LabosのApplications領域にデプロイすることが可能です。

ただし、デプロイには以下の手続きが必要です。

手順はAppFabric Team Blogのポストでも紹介されています。

 

・AppFabric管理ポータル(http://portal.appfabriclabs.com/)にログインします。

・管理ポータル左側のメニューから「Applications」を選択します。

・ツールバーの「Request Namespace」をクリックします。

・ダイアログが表示され、質問に回答します。また、作成を希望するNamespaceも入力します。

・作成依頼が完了すると、ステータスがPendingに変更されます。承認後、サービスが利用可能になります。

 

実際にアプリケーションをデプロイしアプリケーションマネージャを利用するには、この承認が完了するまで待つ必要があります。

しかしながら、開発ツールはすぐに利用可能です。

Windows Azure AppFabric Developer Tools for Visual Studio 2010をインストールすると、プロジェクトテンプレートに「AppFabric」テンプレートが追加されます。
#現時点ではC#のみのサポートです。

新規にAppFabricプロジェクトを作成するか、サンプルをダウンロードして、コードを表示してみましょう。

以下の例は、サンプルContosoPizzaをVisual Studioで開いた例です。

 

 

この例では、3つのワークフロー、1つのWCFサービス、1つのASP .NET Webアプリケーションから構成されています。

新しい種類のサービスを追加する場合には、右上の「Add New Service」をクリックします。

この例は、Service Bus Queueを新たに追加している例です。

 

 

既に存在するサービスタイプのサービスを追加する場合には、各サービスタイプの「Add Service」を追加することで、定義とプロジェクトが作成されます。

この段階では、各エンドポイントの参照関係までを設定することができます。そのため、各サービスの関連を定義して、細かなインプリメントの段階に引き継ぐことが可能です。

AppFabric Applicationsの利用が可能になった時点で、さらにアプリケーションマネージャーについてもご紹介しましょう。

イオンb-mobile提携のSIMカードを購入してみました

6月 11th, 2011

昨日から発売が開始されたイオンとb-mobile提携のSIMカード。

ドコモのネットワークを利用できて、最小のプランで月980円から利用可能という手軽さと、原則的に拘束期間のない気軽さもあって、モバイルルーターをお使いの人や、データ通信を専門でスマートフォンを利用されている方には朗報なプランだといえます。

幸い、私の職場に隣接しているイオンが、昨日より販売を開始する店舗であったため、帰宅前に契約をしてみました。

しかし、そこで「初めて分かった事実」も何点かありましたので、この情報をシェアしたいと思い、この記事を書いている次第です。

各種ニュースサイトでは月額料金の話しか書かれていません。且つ、従来の日本通信のSIMカードは基本的にプリペイドカードになっています。

そんな訳で、私も「SIMを買いに行く」程度のノリでイオンの携帯電話コーナーに向かってしまったのでした。

しかし、そこに待っていたのは・・・・。

1.本人確認資料が必要です
そう、単に「SIM買うぜ!」と思っていた私に驚きをもたらした最初の要因こそ、「運転免許証などの本人確認資料が必要である」ということでした。
幸いにも、運転免許証を持ち合わせていたので、これは難なくクリア。

2.申込書の記入が必要
通常、プリペイドのSIMを購入する際、個人情報の提出は不要であるケースがほとんどです。
しかし、本人確認資料が必要ということ=申込書の記入が必要ということです。
ある意味、普通に携帯電話の契約をしに行ったのと変わりない状況でした。

3.クレジットカードが必要
これは意外でした。最初は1か月分だけ買うノリで居たため、クレジットカードの提示が必要&契約申込書にカードの情報の記載が必要である点には驚きました。
原則、月々の利用料金はカード払いになります。なので、クレジットカードが必須となりますので、注意してください。

4.ニュースには書かれていなかった「初期費用」が掛かります
これが最大のインパクトだったといっても過言ではありません。
なんと、手続時に「SIM代」として3,150円が掛かります。これはどこにも書いてなかったので、行ってみて「なにそれ~」と怒ってしまう状況かもしれません。

もちろん、これらの事項は契約時に説明があり、これに同意した上で申し込みます。
なので、この条件が納得いかない場合は、申込みを止めることも可能です。

ただ、拘束期間が存在しなかったり、ちょっとしたデータ通信用の回線が月980円で利用可能である気軽さを考えると、アリかなぁ、、、と思います。

とはいえ、初期費用の3,150円が「損したぜ」と思わない程度使い続ける自信のある方にはおすすめです。

なお、契約後もプランの変更が可能ですので、利用料に応じてよりブルジョアなプランに変更することも可能です。

 

Windows Azure AppFabric SDK V2.0 May Updateが公開されました

5月 18th, 2011

現在、米国アトランタで開催中のMicrosoft Tech・Ed North AmericaでWindows Azure AppFabric Service Bus V2サービスの新しいCTP提供を開始するアナウンスがありました。

これを受けて、Windows Azure AppFabric V2 SDKのCTP版がMay Updateに更新されています。サービスの正式な提供開始へ向けた準備として、多くのUpdateが提供されています。まず、Queueという概念が導入されました。高信頼のメッセージングプラットフォームとしてService Busが利用できるようになります。May UpdateのAPIにはQueueに対応したAPIおよびサンプルが提供されています。

V1で実行されていたコードをV2環境で実行するには数行のコード変更のみでマイグレーション可能になっています。

それではコードを見ていきましょう。

このコードがV1用のコードです。

 

//エンドポイントのURIを生成

Uri address = ServiceBusEnvironment.CreateServiceUri(“sb”,


ConfigurationManager.AppSettings["Namespace"], “HelloAppFabric”);

//エンドポイントに対する資格情報を生成


TransportClientEndpointBehavior SBCredential

= new
TransportClientEndpointBehavior();

//SharedSecretを選択し、資格情報に設定

SBCredential.CredentialType

= TransportClientCredentialType.SharedSecret;

//資格情報に発行者(issuer)を設定

SBCredential.Credentials.SharedSecret.IssuerName

= ConfigurationManager.AppSettings["Issuer"];

//資格情報にIssuer Keyを設定

SBCredential.Credentials.SharedSecret.IssuerSecret

= ConfigurationManager.AppSettings["DefaultKey"];

//ServiceHostのインスタンスを生成

ServiceHost host = new
ServiceHost(typeof(HelloAppFabric));

//サービスバスを介したRelayエンドポイントを追加

var ep = host.AddServiceEndpoint(


typeof(IHelloAppFabric),


new
NetTcpRelayBinding(),

address);

//エンドポイントにServiceRegistoryの設定を反映

IEndpointBehavior serviceRegistrySettings

= new
ServiceRegistrySettings(DiscoveryType.Public);

//エンドポイントの構成にServiceBusの資格情報を追加

ep.Behaviors.Add(serviceRegistrySettings);

ep.Behaviors.Add(SBCredential);

// サービスをOpen

host.Open();

Console.WriteLine(“Service Started…”);

Console.WriteLine(“Press [Enter] to exit”);

Console.ReadLine();

host.Close();

 

そして、下がV2のコードです。

 

//エンドポイントのURIを生成

Uri address = ServiceBusEnvironment.CreateServiceUri(“sb”,


ConfigurationManager.AppSettings["Namespace"], “HelloAppFabric”);

//エンドポイントに対する資格情報を生成


TransportClientEndpointBehavior SBCredential

= new
TransportClientEndpointBehavior();

//SharedSecretを選択し、資格情報に設定

SBCredential.CredentialType

= TransportClientCredentialType.SharedSecret;

//資格情報に発行者(issuer)を設定

SBCredential.Credentials.SharedSecret.IssuerName

= ConfigurationManager.AppSettings["Issuer"];

//資格情報にIssuer Keyを設定

SBCredential.Credentials.SharedSecret.IssuerSecret

= ConfigurationManager.AppSettings["DefaultKey"];

//ServiceHostのインスタンスを生成

ServiceHost host = new
ServiceHost(typeof(HelloAppFabric));

//サービスバスを介したRelayエンドポイントを追加

var ep = host.AddServiceEndpoint(


typeof(IHelloAppFabric),


new
NetTcpRelayBinding(),

address);

//エンドポイントにServiceRegistoryの設定を反映

IEndpointBehavior serviceRegistrySettings

= new
ServiceRegistrySettings(DiscoveryType.Public);

//エンドポイントの構成にServiceBusの資格情報を追加

ep.Behaviors.Add(serviceRegistrySettings);

ep.Behaviors.Add(SBCredential);

// サービスをOpen

host.Open();

Console.WriteLine(“Service Started…”);

Console.WriteLine(“Press [Enter] to exit”);

Console.ReadLine();

host.Close();

 

両者のコードを比較して何か気づきませんか?

そうです。まったく一緒なのです。

つまり、「参照設定」でMicrosoft.ServiceBus.dllの参照を、V1.0からV2.0に変更するだけです。もちろん、AppFabric Labで作成してあるName Spaceやキーへの変更は必要です。これらの情報を構成情報に外だししておくことで、コードをまったく書き換えることなくV2へ移行することが可能です。この点がAzure AppFabric SDK V2.0 February Updateからの変更点です。

いうまでもありませんが、クライアント側のコードも変更不要です。

このように従来のコードを書き換えることなく、Service Bus V1で実行されていたコードをService Bus V2で実行することが可能になります。

もちろん、この例はこれまで実行していたコードをそのまま移行する例にすぎません。

Service Bus V2 CTP May Updateで追加された新たな機能は、追ってご紹介していきたいと思います。

Windows Azure SDK 1.4 RefreshでAzure Connectが利用できない場合の対処法

4月 28th, 2011

Windows Azure SDK 1.4 Refreshをインストールして、Windows Azure Connectが利用できなくなってしまった方はいらっしゃいませんか?

実は私自身、罠にはまりました。Windows Azure SDK 1.4 Refreshの環境下でWindows Azure Connectを有効にしてアプリケーションをデプロイしても、Virtual NetworkにRoleが反映されないという現象が発生していました。

現在、Windows Azure ConnectはBetaであるため、何らかのUpdateがあったのかと思ったのですが、単にWindows Azure SDK 1.4 Refreshの不具合によるものでした。

この問題を解決したUpdateが太平洋時間の4/25にリリースされました。

Windows Azureチームのブログでも紹介されていますが、以下の手順でアップデートを実行してください。

  1. コントロールパネルの「プログラムと機能」でWindows Azure SDK 1.4 Refreshをアンインストールする
  2. Windows AzureのWebサイトから更新されたWindows Azure SDK 1.4 Refreshを入手し、再インストールする

以上で、Windows Azure Connectが利用可能になります。

なお、最新の環境では日本語版のオペレーティングシステムにもローカルエンドポイントを構成することが可能になりました。