So I went to the market and found some free demographics data available from the UN to mess around with and imported it to my Hadoop on Azure cluster via the portal.   Before you blindly go about importing data, you can first sample the goods.  In the Windows Azure Marketplace you can subscribe to published data, and build a query of your interest.  The most important thing here is that you need to take note of your primary account key and the query url.

Take note of the query and passkey.  Click on Show.

Sample the goods,  build your query.

Once we have the query we want, we need to go to our Hadoop on Azure portal, select Manage Cluster and then select DataMarket.  Here we will have to input our user name (from your email), the passkey obtained earlier, the query url you obtained as well and the name of the Hive table so we can access the data after the import is done.  Note: I’ve replaced the encoded space and quotation marks to avoid Bad Request errors.  This happened to me because I copied and pasted the query right out from the marketplace.  It took a couple of tries until I figured it out, oh well.  Run the query by selecting Import Data.

Now we can go to the Hive interactive console and take a look at the results.  We can type the show tables command for a list of the tables, and make sure ours is there.

Take into consideration that, although this looks like a table, it has columns like a table, and we can query the data as if it were stored in the table, it’s not.  When we create tables in HiveQL, partition them and load data, HDFS files are actually created and stored (and replicated and distributed through the nodes).

Now we can go on and type our HiveQL query.  Remember what’s happening under the hood.  This query is creating and executing a MapReduce job.  I’m also a newbie in the MapReduce world, so I trust Gert Drapers when he says a simple join in HiveQL is equivalent to writing a much more complex bunch of code, and that Facebook’s jobs are mostly written in HiveQL.  That means something, doesn’t it?

So we’ve executed our simple HiveQL query and seen the results.  We can always go back to the job history for that query, too (you can’t miss that big orange button in the main page).

Job History.

So, we’ve imported data from the marketplace and ran a simple HiveQL query.  In a future post we can go through the samples that are included when you setup your cluster and mess around with the Javascript console.  Refer to the previous post for additional links and resources.

Happy Learning.

As you might already know the Prism Library does not provide UI implementations for WPF interaction requests as out of the box, it only provides examples of these implementations for Silverlight, which can be used as a basis for the development of your own triggers and actions.

Hence, I created this blog with the purpose of demonstrating a possible approach to achieve this and to show how creating similar implementations in WPF should be quite straightforward.

Therefore, I created a sample which benefits from InteractionRequestTriggers and a custom TriggerAction<FrameworkElement> similar to the default PopupChildWindowAction class, which can be used to display a pop-up modal windows in Silverlight.

Introduction

The Prism documentation provides useful information on how a view model can make interaction requests directly to the view itself via an InteractionRequest object coupled with a behavior in the view. I recommend reading the following section of the Prism documentation to have a better understanding on how this works:

• Chapter 6: Advanced MVVM Scenarios, Using Interaction Request Objects

As mentioned in the Prism documentation:  the standard EventTrigger provided by Expression Blend can be used to monitor an interaction request event by binding to the interaction request objects exposed by the view model. However, the Prism Library defines a custom EventTrigger, named InteractionRequestTrigger, which automatically connects to the appropriate Raised event of the IInteractionRequest interface. Once the event is raised, the InteractionRequestTrigger will invoke the specified action. As mentioned before, the library only provides the PopupChildWindowAction class for Silverlight, which displays a pop-up window to the user. By default, the specific type of pop-up window displayed by the PopupChildWindowAction class depends on the type of the context object (e.g for a Notification context object, a NotificationChildWindow is displayed, while for a Confirmation context object, a ConfirmationChildWindow is displayed). Unfortunately the ChildWindow class used by these objects returned to display as part of the trigger action is only available for Silverlight.

Hence, when I created a custom TriggerAction similar to the PopupChildWindowAction provided with Prism, I had to change the returned type of the object to be displayed. In mi case I defined it as Window. The problem was that as a result of this change, the displayed popups would not be modals like with the ChildWindows implementations. Therefore, I also changed the way the action invokes its child window, and instead of calling the Window.Show() method in my PopupModalWindowActionBase’s Invoke method I used the Window.ShowDialog() method, which allows showing a modal window instead.

Basically these were all the changes I needed to obtain a similar implementation to the PopupChildWindowAction. Take into account that this implementation may change depending on your personal preferences and the requirements of your scenario. Although I believe it could be considered as a starting point.

Sample Application

You can download the sample in my SkyDrive account, under the name “ PopupModalWindowActionSample“.

Note that this code is provided “AS IS” with no warranties and confers no rights.

I hope you find it useful!

Updated 2012/05/15

Additional Considerations

After reviewing this approach we realize that some considerations should be taken for some scenarios. Particularly if passing a custom view using the PopupModalWindowAction‘s ChildWindow property. When doing so, you will find that you can’t show the dialog window more than once. This occurs as the view is of type window which won’t allow showing a windows once this is closed. Currently this could be achieved by creating a new custom window in the PopupModalWindowAction each time the InteractionRequest is raised, this is why the default windows implementation can be re open without problems.

Also if you want to keep the state of the view, this can be achieved without problems by passing the same instance of the Context object when raising the InteractionRequest.

Additionally, we have been thinking that a possible approach to reopen a custom window using the ChildWindow property may be possible passing a custom view to the ChildWindow property, and creating a new window each time the interaction is raised and use it to wrap the custom view as the content of this new window.

Big Data

So we generate massive amounts of data.  Massive.  Structured, not structured, from devices, from sensors, feeds, tweets, blogs, everything we do in our daily lives generate data at some point.  What do we do with it besides store it?  Ignore it?  Throw it away?  We could. But data is there for a reason.  We can extract valuable information from it.  We can discover new business insights, interesting patterns emerge, and most important we could save lives… so yes, it’s a big deal.  Ok, so we’ll leave the processing to multi-million dollar companies, they can afford it, right?  One misconception is that we need all this massive state of the art infrastructure to be able to handle big data.  We can setup nodes on affordable, commodity hardware, and achieve the same results.  Nice.  But I still need to maintain all these boxes, and they WILL fail eventually…

Hadoop is a scalable, hi fault tolerant open source MapReduce solution.  It runs on commodity hardware, so there is an economic advantage to it.

The main components of Hadoop are illustrated in the following diagram.

HDFS: Hadoop Distributed File System.  It’s the storage mechanism used by Hadoop applications.  Amongst other things, it stores replicas of data blocks on the nodes of your cluster, aid availability, reliability, performance, etc.

Map Reduce.  A programming framework that allows to create mappers and reducers.  The framework will construct a set of jobs, hand them over to the nodes for processing, and keep track of them.  The map operation let’s you take the processing to where the data is stored in the distributed file system.  The reduce operation summarizes the results from the mappers.

Hive: it provides a few things, such as the possibility to create a structure for data through the use of tables.  It also defines a SQL oriented language (QL, or Hive QL), in other words, MapReduce for mortals.  The magic behind this is that a Hive query can be translated to a MapReduce job, and present the results back to the user.  The need for Hive appeared because creating a relatively simple query in plain MapReduce jobs resulted in a cumbersome coding experience.

Sqoop: Bridge between the Hadoop and the relational world.  Because we also live in a relational world, right?  We can import data from SQL Server, let Sqoop store the data in HDFS, and make the data available for our MapReduce jobs as well.

Hadoop on Azure is Microsoft’s Hadoop distribution that runs on Windows, plus a hosting environment on Windows Azure.  I recently got invited to use the CTP version of Hadoop on Azure (I did ask for an invitation a few weeks ago) and started to get familiar with its features.  The huge benefit to this is that I don’t need to maintain all those nodes, I have my own cluster now, and I’m ready to handle massive amounts of data.  Tada!

In future posts I’ll be showing how to execute a simple MapReduce job, or how to get data from the Windows Azure Marketplace and query the data using Hive.  The following links lead you to useful resources if you are getting started with Hadoop on Azure.

Big Data, Big deal, video by Gert Drapers

Introduction to Hadoop on Azure, video by Wenming Ye

Hadoop on Azure portal, get invited!

Apache Hadoop

Happy learning

Recently I’ve been working with TeamCity 7 and getting involved in the continuous integration practice, so I would like to show my experience in this post.

For my project, “build” means the following things: compiling, checking Source Analysis, checking Code Analysis, running Unit Tests and measuring Code Coverage. Taking this into account, I will show you how to configure TeamCity 7 to perform all these tasks automatically in a VS2010 .NET solution, with .NET Framework 4 and a Git repository.

First of all I had to create a new project. I did this in the Administration > Projects section, clicking Create new project and providing a name for it. After that, I had to create a new configuration for my project. This configuration has various “steps” to configure.

Configuring General Settings

In this section I only provided a name for the new configuration. I left all the other values by default.

Configuring Version Control Settings

In this section I had to specify the URL of the Git repository that I’ve been using to commit the source files of my application. To do this, I clicked Create and attach new VCS root and then, when the New VCS Root windows is displayed, I specified the URL of my repository and set the authentication method to Private Key, indicating the Private Key Path too.

TeamCity will be monitoring my repository according to the triggers that I specify in the build execution. On each build, TeamCity will search for changes in my repository and will execute the defined Build Steps. I will show all of this configuration in in the next sections.

Configuring Build Steps

This is one of the most important parts of the configuration process, because Build Steps are the actions that will be executed when a new build runs. In my configuration, I had to create 3 Build Steps as shown in the following picture:

Step 1 – Source Analysis, Compilation and Code Analysis

This step will use a MSBuild runner with a ciserver.proj build file that resides inside the repository of the project. This build file has all the routines to check Source Analysis, Code Analysis and perform the compilation.

Ciserver.proj file

IMPORTANT: In order to successfully run this build file, you need to have Stylecop and MSBuild Extension Pack installed in the Server machine.

I defined all the paths to the working directory, FxCop and the Extension Pack at the beginning (they should be environment variables provided by TeamCity), so they can be passed to the tasks that are executed after that. In the ItemGroup tag I specified all the source code files in the repository, the assemblies to take into account, the rules to include, the soulution files and the ones that I want StyleCop to include in the checking.

• RunSourceAnalysis task: It depends on the StyleCop.dll assembly of the MSBuild extension pack. This task will take the files defined in the ItemGroup section and the Settings.Stylecop specified and will perform the check generating a log file with all the information of the execution.
• Compile task: It will perform the compilation of the solution. Notice that it depends on the RunCodeAnalysis task.
• RunCodeAnalysis task: It will check Code Analysis in the assemblies defined in the ItemGroup section, and generate the results in a txt file. It also depends on the Compile task.

All the result files generated by StyleCop and FxCop will then be used to show the Code Metrics reports in the TeamCity UI. I will show how to do this at the end of the post.

Step 2 – Run tests

This step will use MSTest runner with the Local.testsettings and test-metadata (.vsmdi) files generated by Visual Studio. In the test-metadata file I included the list of tests that I want the Build Process to execute.

All the other fields are left by default.

Step 3 – Measure Code Coverage

For this step, I decided to execute a Build file called teamCityCodeCoverage.proj with a MSBuild runner and measure the coverage manually instead of using one of the tools that TeamCity provides (NCover, PartCover, dotCover, etc).

The only things that I had to provide in TeamCity were the path to the Build file, the .NET Framework used and the platform (x86 in this case). I left all the other fields by default.

teamCityCodeCoverage.proj

When the Tests were run in the previous Build Step, a sort of TestResults folder is created in a temp folder inside TeamCity path. It is the ArtifactDirectory path that is displayed in the previous image. Inside of it we have 2 important assets: The Out folder with all the assemblies of the test results, and the data.coverage file with the coverage information inside a In folder. All these stuff will be passed to the CoverageConvert.exe tool (this is an internal tool developed by the engineering excellence team), which will process them and produce a CodeCoverage.xml file with all the results of the measurement. But this is a lot of information to show in a report, so I used some assemblies to transform this xml into a html file with the summary of the Coverage.

Folder with build files and Coverage tools

NOTE: The disadvantage of measuring Code Coverage like this is that these assemblies have no maintenance and are a blackbox, although they were developed here in Southworks.

Configuring Build Failure Conditions

In this section you can specify when the Build should fail. Notice that you can add custom Build Conditions apart from the ones provided by TeamCity. In my case, I added two build failure conditions when there are Source Analysis or Code Analysis violations. Basically in the ciserver.proj file I show a status message when the check of Code Analysis and Source Analysis finishes. This will be printed in the Build log of TeamCity, so I added my custom failure conditions to fail the build if the status messages of Source Analysis and Code Analysis in the Build log of TeamCity are failure.

Configuring Build Triggers

In this section you can specify the triggering of the Build Process. In this case, I decided that the build process should start after a new commit is detected in the Git repository, so I chose a VCS trigger.

How to Show the Code Metrics Reports in the TeamCity UI

TeamCity 7 provides custom report tags. These ones are useful to show reports generated by other tools, like in this case, Source Analysis, Code Analysis and Code Coverage. To make this happen, we have to store these 3 reports as artifacts from the build.

To do this, we specify the path to these files in the General Settings section of the Project Configuration Wizard.

After that, we will create a new report tag for each report, and retrieve the report from the artifacts generated by the last successful build. To do this, click Administration at the top right corner, click your project’s name and the click the Report tabs tab. There you can create all the tabs that you want, specifying the build which the artifacts will be taken from, and the file names. These artifacts will be taken from the data-directory path of TeamCity, in this case, under UsersUser.BuildServer7systemartifacts{projectname}….{file-name}.

Then, you can see the new tabs in the Project’s Home page, displaying the required reports.

I know that the Code Analysis report is not very consumable, but I will show another alternatives for reporting it in another post.

I hope that you find all this information useful!

Thanks!

http://woloski.com

NEW RSS

http://feeds.feedburner.com/woloski

Recently I found that these topics were often discussed in the Prism forum and, although there are samples already using these features provided by Prism as out of the box (e.g. Commanding Quickstart and Stock Trader Reference Implementation.) I thought that a small sample portraying all these functionalities together could become handy, especially one that shows the different behaviors of CompositeCommands (e.g. with and without the monitorCommandActivity parameter).

Introduction

As many of you might have read from the Prism documentation, CompositeCommands can be connected to several child commands so that when a CompositeCommand is invoked, its child commands are also invoked. Also, these commands support enablement, as they can listen to the CanExecuteChanged event of each one of its child commands. This way, when any call to the CanExecute method of the child commands returns false, the CompositeCommand’s CanExecute method will also return false and the corresponding invoker will be disabled.

Additionally, if its child commands implements the IActiveAware interface, the CompositeCommands provide the possibility to only execute and evaluate the corresponding Execute and CanExecute methods of the child commands that have its IsActive property set to true.

CompositeCommands can be configured to evaluate the active status of child commands (in addition to the CanExecute status) by specifying true to the monitorCommandActivity parameter in the constructor. In those cases DelegateCommands will become handy as they already implement the IActiveAware interface.

Basically, I created this sample with the purpose to highlight  the different possibilities that could be achieved when benefiting from these available functionalities.

Sample Application

The Solution is a small application, that contains a shell project, one module and an infrastructure project.

There you can find that the module’s Initialize method registers two views in a region which is attached to a ListBox control in the shell. As their view model implements the IActiveAware interface, when one view is selected their active state is changed accordingly. Particularly, I decided to use a ListBox as the region placeholder, so it could be possible to appreciate the state of the different views displayed in the region simultaneously, although it could be easily replaced with any control that inherits from the Selector class.

Each of these views contain a pair of buttons which are bound to its corresponding DelegateCommand and they also contain a CheckBox which will allow to select the returned value of each CanExecute method in order to appreciate the different behaviors when those values are changed.

All these inner buttons’ DelegateCommands will be registered as child commands of the two CompositeCommands that are defined as static classes in the Infrastructure project so they could become globally available. One of them (GlobalCommands.MyGlobalCommand) sets its monitorCommandActivity parameter value to true and the other one (GlobalCommands.MyResetCommand) sets it to false.

You can download the sample application from my SkyDrive account, under the name “CompositeCommand&IActiveAware“.

Note that this code is provided “AS IS” with no warranties and confers no rights.

I hope you find it useful!

Since the version 4.1 of Prism, the RegionActiveAwareBehavior has been modified to be able to sync the state (that is, the IsActive property of the IActiveAware interface) of “child” views and view models with their parents through the inclusion of the SyncActiveState attribute. However, a user in the following work item has posted that this behavior fails when adding views “at start-up” (for example, in the Initialize method of an IModule class.) We were able to reproduce the problem, find the cause behind it and implement a possible workaround for it:

How the RegionActiveAwareBehavior works

Based on my understanding, the RegionActiveAwareBehavior subscribes to the CollectionChanged event of the ActiveViews collection of the corresponding Region. When the aforementioned collection is changed, the behavior changes the state of the views that are added or removed from the collection. This means that this behavior only executes its logic when a view is activated or deactivated.

Through the inclusion of the SyncActiveState attribute, during the state change, this behavior now also checks for any scoped views with the aforementioned attribute and set its state too.

The problem

It seems that the aforementioned logic does not take into account one scenario: when a view is added to a region. For example, it is possible to add a “child view” into a “parent view” that is deactivated. In this case, as the ActiveViews collection would not be modified, the logic in the RegionActiveAwareBehavior will not execute. As a  result the value of the parent view’s IsActive property would be false while the value in the child view’s property could be true.

A quick work around for this could be to activate and deactivate all the views in the corresponding region in order to update the state of all the views. However, activating and deactivating all the views each time a view is added to a region might be bothersome, especially if any of those view or their corresponding view models perform some kind of logic when activated.

As another possible approach to solve this, I have created a behavior named RegionActiveAwareSyncOnAdditionBehavior that complements the existing RegionActiveAwareBehavior.

RegionActiveAwareSyncOnAdditionBehavior

This behavior has a similar logic to the RegionActiveAwareBehavior but performs a different task. Instead of subscribing to the changes in the ActiveViews collection, this behavior subscribes to the Views collection of the region, meaning that it will be notified when any view is added to the region. When a view is added to the region, the behavior check if it’s decorated with the SyncActiveState attribute. If so, the behavior then searches for a parent view or view model that implements the IActiveAware interface. If a parent is found, the value of the IsActive property of the added view is changed to match the one of its parent.

private void OnViewsCollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
    if (e.Action == NotifyCollectionChangedAction.Add)
    {
        foreach (var view in e.NewItems)
        {
            // We only sync the state of the view if it's an active view in its corresponding region
            if (this.Region.ActiveViews.Contains(view))
            {
                if (ShouldSyncActiveState(view))
                {
                    IActiveAware parent = FindIActiveAwareParent(view as DependencyObject);
                    if (parent != null)
                    {
                        InvokeOnActiveAwareElement(view, activeAware => activeAware.IsActive = parent.IsActive);
                    }
                }
            }
        }
    }
}

The ShouldSyncActiveState and InvokeOnActiveAwareElement methods used in the aforementioned code snippet are the same that the ones used in the RegionActiveAwareBehavior.

The question now is how the FindIActiveAwareParent method find the corresponding parent. The answer is simple: this method uses a modified version of the same logic used by the RegionManagerRegistrationBehavior to find the corresponding RegionManager, only that this method searches for IActiveAware elements instead:

protected static IActiveAware FindIActiveAwareParent(DependencyObject element)
{
    if (element == null)
    {
        return null;
    }

    DependencyObject parent = null;

#if SILVERLIGHT
    FrameworkElement frameworkElement = element as FrameworkElement;
    if (frameworkElement != null)
    {
        parent = frameworkElement.Parent;
    }

#else
    parent = LogicalTreeHelper.GetParent(element);

#endif

    if (parent == null)
    {
        return null;
    }

    // We check if the parent control implements IActiveAware
    IActiveAware activeAwareParent = parent as IActiveAware;
    if (activeAwareParent != null)
    {
        return activeAwareParent;
    }

    // If not, we check if the parent control's data context implements IActiveAware
    FrameworkElement parentFrameworkElement = parent as FrameworkElement;
    if (parentFrameworkElement != null)
    {
        IActiveAware activeAwareParentDataContext = parentFrameworkElement.DataContext as IActiveAware;
        if (activeAwareParentDataContext != null)
        {
            return activeAwareParentDataContext;
        }
    }

    // If none of the two implements IActiveAware, we keep climbing the tree.
    return FindIActiveAwareParent(parent);
}

You can find the behavior inside a sample at the end of this post. As a side note, I believe that this behavior and the RegionActiveAwareBehavior could be merged into one without problems; however, as they have a different logic, I am posting it as a different behavior (which depends of the original one to work) in order to make its code more readable.

Sample

The sample application is very simple. The behavior is registered in the Bootstrapper overriding the ConfigureDefaultRegionBehaviors method:

protected override IRegionBehaviorFactory ConfigureDefaultRegionBehaviors()
{
    IRegionBehaviorFactory factory = base.ConfigureDefaultRegionBehaviors();

    factory.AddIfMissing(RegionActiveAwareSyncOnAdditionBehavior.BehaviorKey, typeof(RegionActiveAwareSyncOnAdditionBehavior));

    return factory;
}

The Shell contains a MainRegion which is a TabControl. During the initialization of the HelloWorlModule five instances of a view containing a scoped region (named “SubRegion“) that implement IActiveAware are injected in that region. Also, in each of those scoped regions, another view implementing IActiveAware and decorated with SyncActiveState attribute is injected.

public void Initialize()
{
    IRegion mainRegion = this.regionManager.Regions["MainRegion"];

    for (int i = 0; i < 5; i++)
    {
        FrameworkElement view = ServiceLocator.Current.GetInstance<Views.ScopedRegionView>();
        IRegionManager scopedManager = mainRegion.Add(view, null, true);

        FrameworkElement subView = ServiceLocator.Current.GetInstance<Views.SubView>();
        scopedManager.Regions["SubRegion"].Add(subView);
    }
}

The application’s Shell has a “Check Views’ States” button that when clicked will write in the console the state of each view (you can find its output in the Output window of Visual Studio.) You will see that the state of each view is now synchronized.

You can find the sample in my SkyDrive account:

• RegionActiveAwareSyncOnAdditionBehaviorSample.zip

I hope that you find it useful!

The 2.0 release was built using the Silverlight 5 Beta bits, which already expired so some users were getting the message “This application was created for an expired beta release of Silverlight. Please contract the owner of this application and have them upgrade their application using an official release of Silverlight” when trying to use the application.

Happy editing,

Ez.

As it turns out, I also like Service Bus, and the powerful features it provides to build distributed applications, aid transactional behavior, etc.

In our scenario we have a company that runs an online store in all six Windows Azure data centers (how romantic), and, through Traffic Manager, the users can get routed anywhere.  How do we deal with the challenge of data consistency? Well, we can use Data Sync, for sure, but what if we are in a more restrictive scenario?  What if  we are not allowed to make changes to the database?  Well, the Data Sync option quickly fades away, doesn’t it?  Part of Data Sync’s magic consists of installing a Windows Service and a number of tables in your database to keep track of changes.  Busted.

So, how do we go about solving this problem?  I will go down the path of  Service Bus topics and subscriptions to comply with our restriction.  I choose Service Bus because we are already working with Windows Azure,  I’ve seen it in action, been working with it for the last couple of months and know that I can find a relatively simple way to manage this.  It’ll be wholesome to discuss other options as well.

This is a high level diagram of the idea

Our beloved customer places an order through any of the data centers.  Because the user can see his own orders, and because he might get routed by Traffic Manager to another data center, we need to have that information available everywhere, eventually.

We create a topic (let’s call it SyncTopic) in our favorite data center.  Just one (let’s add a budget restriction while we are at it, and a little bit of KISS). We create one subscription per data center, and we’ll have our SyncListener component running in each cloud subscribe to that topic.  The SyncListener will be responsible for writing the orders to the database.  Insert only, it makes the story easier  (that would depend on how we designed our data model, of course)

Every time a customer places an order, the SyncSender component (a separate worker role or a new task running in a worker role – you choose) posts a message to the topic, a copy of the order.  Each SyncListener will receive a copy of the message and perform the corresponding write operation to the db.  That is the big picture.

Implementation considerations.

This is all very nice if we draw it on paper, but we need to be sure that we are tackling other concerns, for example, and in no particular order of importance…

Sync loops: because the data center where the order originated also contains a SyncListener, it could potentially receive a copy of the order it already has.  We can avoid this by implementing a filter on the subscription, and filling the corresponding property in the BrokeredMessage.  The filter (a SQLFilter why not) can be something like  SenderDataCenter != ListeningDataCenter.

Conflict Resolution: we need to be covered here as well.  The path we choose will depend on our given context and might even take us back to square one.

Transactional Behavior: We would have to use the PeekLock mode to receive messages for starters, and we would have to have a supervising mechanism to deal with transient failures, we can also use Topaz.  Consider using the dead letter queue as well if something goes wrong when receiving the message.

Message size: What if our BrokeredMessage exceeds its size?  We need to consider another mechanism to get the required data through.  Maybe storing it in blob storage, and then passing a reference in the message for the listener to pick up.  The story gets complicated, but it could happen.

Security: Although the topic and subscriptions are used internally, it is always a good idea to secure them.  With ACS we can easily secure the edges.

Hybridness: now we need all the orders data on premise (wait, don’t we have that already? oops).  By setting up  a new subscription, and a SyncListener on premise we can now get a copy of the data.

and probably others…

Conclusion

We can go about it many ways.  Data Sync is simple and quick to setup.  We don’t have 100% control over it, but it gets the job done.   As our context changes, so does our need of considering other possibilities where we need greater control over things.  I am aware that this idea can trigger LOTS of other considerations I haven’t mentioned. Consider this post not as a definitive solution, but as a starting point to a fun discussion.

Happy Learning!

Topics in the video:

• Creating a new project, adding, and configuring the Storage NuGet package.
• Walkthrough the Storage Sample NuGet package (Blobs, Tables and Queues).
• Why you should use the proxies’ services?
• Installing and configuring the proxies’ services.
• Configuring your Windows Phone application to work with the proxies.
• Using ACS with the Windows Phone Storage NuGet Packages.
• Configuring your proxies and your Windows Phone application to use ACS.

If you haven’t seen it, here is your chance.