Script Explorer Design Overview

In last weeks blog post Creating a Semantic Web for PowerShell I introduce our vision for establishing a semantic web in support of PowerShell and some of the benefits it could yield. That lead to the obvious question of what to do until major repositories, blog sites and forums have adopted some of the techniques described in the post – to which I answered Microsoft Script Explorer was the solution. Hopefully by the end of this post you will have a better understanding of how Script Explorer can help – and how you can extend Script Explorer to search your blogs / online forums – and share those extensions with other people.

In the illustration below you can see the high-level design of Script Explorer illustrated. The dotted line in the middle shows the divide between code and repositories that run / exist inside a corporate network vs those outside of the corporate network. One of the most interesting aspects of Script Explorer is something we have called the Aggregation Service. This service takes responsibility for helping us aggregate scripts from different sources based on your requirements. The service is able to take content from any number of repositories, regardless of what protocol they use or what format the scripts are exposed in and then aggregate the functionality and expose that data as an oData based feed.

As you can see in the illustration below there are typically two instances of the Aggregation Service running. The first (on the right-hand side) runs on Windows Azure and is responsible for aggregating feeds from different Internet based repositories such as TechNet or Posh. The second (on the left-hand side) runs along-side Script Explorer and takes responsibility for retrieving scripts from the external aggregation service as well as internal resources such as your local file system and any corporate repositories you want to stand up.

 

One of questions we have heard is wrt why through the Script Explorer UI have we limited ourselves to just TechNet and Posh repositories – and the good news is that we haven’t. The Aggregation Service includes a standard way to write new providers enabling you to search alternative sources of scripts and have them exposed directly inside Script Explorer simply by changing the configuration file. Another question we hear frequently is why only Bing? To which we obviously respond – why not Bing – what other search engine would you ever want to use! :-) Seriously though, for all you AltaVista or Yahoo fans out there – you can easily create a provider that used a different search engine if you wanted to. Similarly, if you have dedicated hours to posting PowerShell Scripts to your blog and want to enable people to find them – but don’t want to republish all scripts with a schema.org schema (more about this later) describing the Script – then take a stab at writing your own provider – and then share it with other folks. For creating a new repository or creating a new provider take a look at the sample posted on CodePlex. There will be more samples posted there in the coming weeks - plus if you have any questions / requests please make sure to post them there as well.

Comments

• Anonymous
  May 30, 2012
  Hi, Isn't it somewhat anti-PowerShell that we need to use the Script Explorer UI to query the aggregation service? Shouldn't the Script Explorer include a PowerShell module that enables us to query the aggregation service from the PowerShell prompt or within scripts? Regards, Jason

• Anonymous
  May 31, 2012
  Hi Jason - Thanks for the follow up. You raise a great point - and one that you will be happy to know we have already thought about. Our RC release will include samples that show you how to query the aggregation service directly via PowerShell. I will post an update when they are available. In terms of UI's being anti-PowerShell I tend to disagree with you on that point. For many Microsoft IT Pro's the GUI is a critical tool for enabling more efficient access to management / automation capabilities - and almost certainly a great bridge towards embracing PowerShell. Hence I think the best approach is to offer both a UI and a Scripting option. Make sense? Jason

• Anonymous
  June 04, 2012
  Hi Jason, I'm glad to hear there is something in the pipeline to enable the service to be queried directly from PowerShell. Regards, Jason