Making Applications Scriptable via PowerShell

Making Applications Scriptable via PowerShell

  • Comments 5

OpenXtra has a blog entry PowerShell + Network Monitor = Powerfull Netman Tool which observes that if took a network manager tool and coupled it with PowerShell, you would have an awesome combination. A long time ago I was the architect for NetView so I feel qualified to offer this observation: YOU TOTALLY GET IT!

Most management products and certainly all monitoring products should be embedding and/or leveraging Windows PowerShell. If you are working on a product like this, you owe it to yourself (and your customers) to get PowerShell in focus and include in your next version. If you are a customer of one of these products, you should start beating up your vendors to get this included in their next release. Not only would this provide incredible power to the management tool but pretty soon, you won't be able to manage things unless you support PowerShell (that should be a wakeup call for any of you that haven't yet groked the fact that the ONLY way you can manage Exchange 2007 is via PowerShell).

There are a couple of ways to integrate PowerShell and a management product:

  1. Provide cmdlets to expose the functions of the Mgmt product.
  2. Launch PowerShell to respond to an event or action.
  3. Embed PowerShell into the application.

 

The first 2 have been talked about a lot so I'd like to spend a bit of time discussing the 3rd. We made the PowerShell engine available as a DLL explicitly so that applications could embed it into their applications to make them scriptable(1). The application can create one or more instances of a RUNSPACE (a SPACE to RUN PowerShell scripts or commands) and then invoke scripts or commands to run in those RunSpaces. We also provide APIs so that you can expose portions of your application as variables to those scripts.

Lee Holmes has a great blog entry HERE showing exactly what I'm talking about. He has a graphical LOGO application which exposes a TURTLE object as a variable and then executes scripts. The script can then do things like $Turtle.Right(15) or $Turtle.Forward(300).

The benefit of this approach is that you can make your application scriptable with incredibly low latency for performing the actions. Making your application scriptable means never(2) having to say, "that's a great idea – hang in there for a couple of years till we get around to putting that in our next version". If your application is scriptable, you get to say, "That is a great idea, here is how you can script that today and if enough people ask for it, we'll hardwire it into our next version". The business impact of this architecture cannot be overstated. It provides incredible agility in the marketplace and empowers your customers, your ISVs and your field people.

This pattern is absolutely critical for management products because "dealing with stuff nobody thought of" is the ontological definition of a management product. If you are working on a management product and are not adopting about this architecture – you are probably making a mistake. But the technique and its advantages are in no way limited to Management products. Lots of products (CAD systems, Games, Office, etc) get great advantage by embedding scripting engines.

 

  1. Hat's off to superstar John Ousterhout and his fantastic work with TCL. TCL was what first introduced me to this idea of an embeddable scripting engine and the power this approach provided.
  2. OK OK – I'm overstating the case by saying "never". That depends on what you've exposed and how you've exposed it.

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

 

 

 

 

Leave a Comment
  • Please add 4 and 8 and type the answer here:
  • Post
  • Thanks for spotting my post. Very kind. Extracting data from applications is a great application for PowerShell. Far too much data is locked away so that it can't be gotten at by third party apps.

  • PingBack from http://msdnrss.thecoderblogs.com/2007/08/29/making-applications-scriptable-via-powershell/

  • I feel a bit of passion coming through in this post and I have to say I agree totally - this is SUCH a powerful model.  By providing a native scripting interface to an application using a COMMON scripting engine the versatility and power of the application is increased many times over - for basically very little cost.

    This is the model that worked so well for Rexx.  OK, I know Rexx is pretty much dead in the Windows world, but back in the day on OS/2 (and on the Amiga even) pretty much all decent apps came with exactly this built-in scripting capability, but using Rexx instead of PowerShell.  This meant I could buy an app and know I could manage it/control it from a powerful scripting environment I already knew.  

    Examples using Rexx are still around: THE (The Hessling Editor - an Xedit Clone), and PMGlobe (a 3D world map) spring to mind.  Check them out if you want to see how this model works.

    Anyway - a great call to action.  Get that PowerShell interface in your apps now guys:-)

    Chris Warwick

  • > Rexx

    That is another great tool.  We had actually considered using Rexx's text parsing model.  In many ways it is MUCH easier than REGEX.  In the end, I decided that REGEX was much more powerful and would be more familar to the UNIX folks that would be using PowerShell (My perception was that they would outnumber the Rexx crowd).  I considered supporting both but decided against it.  Every time I fumble with REGEX, I wonder if that might have been a wrong decision.

    Jeffrey Snover [MSFT]

    Windows Management Partner Architect

    Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell

    Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

  • In referance to making applications scriptable I want to do this with compmgmt.mmc more specifically the filemgmt.dll so that I can deal with NAS based file share's where are not accessable via the wmi32_share object.

    I thought I read somewhere that all windows dlls were accessable in powershell to use the pre-define methods and properties in a powershell script?

    If this is the wrong place to post this I appologize

    Df

Page 1 of 1 (5 items)