Jeffrey Snover of Microsoft has written a very interesting post on PowerShell cmdlet development, prompted by the release of my latest updates to the WebSphere MQ PowerShell cmdlets.
By way of background, the cmdlets let you administer WebSphere MQ from the Windows PowerShell command prompt and scripting environment. One of WebSphere MQ’s biggest strengths is the breadth of it’s platform support, so it was no surprise that one of the most requested features to be added to the cmdlet library has been to be able to use PowerShell with WebSphere MQ queue managers on non-Windows servers.
Windows PowerShell (as the name suggests!) only runs on Windows systems. The current version of PowerShell only runs on the local system, however one of the much-talked about additions to version 2 (now in an alpha “Community Technology Preview” release), is the introduction of remoting: “the ability to run PowerShell commands against remote computers“.
A good compromise to being able to run PowerShell on multiple platforms is to be able to use a Windows workstation to manage resources remotely on non-Windows servers. This is the approach that I adopted with my latest additions to the WebSphere MQ cmdlets.
I have stuck with PowerShell 1.0 rather than use the upcoming v2.0 CTP for the WebSphere MQ cmdlets, and so (rather than using the new remoting functionality) had to write my own code to handle communication between the Windows PowerShell command prompt and queue managers on remote servers. This was something I was writing a blog post on, but Jeffrey has beaten me to it with a good overview of the pros and cons for cmdlet developers about whether to write your own remoting code or wait for use the V2-provided remoting capabilities.
He has covered everything that I wanted to say, so I’ll just highlight a couple of points that were particularly relevant to me.
Platform Support – This was the most compelling argument for me writing my own approach to remote code. As I mentioned above, WMQ covers multiple platforms and I want our customers to be able get the benefits of PowerShell administration for their queue managers on Solaris, Linux, HP-UX, AIX and so on – as well as Windows. (I even want to be able to use PowerShell to administer queue managers on the z/OS mainframe platform, but I’m still working on that).
At the moment, there is no sign of a cross-platform PowerShell, and the V2.0 CTP approach to remoting is to use Windows-specific WinRM to communicate with remote servers. Even if V2 was fully released at this point, the lack of support for UNIX-based operating systems is a bit limiting. I really hope that we will see a Linux version of PowerShell soon.
Why not use both? – When PowerShell V2 is fully released, it might be that a good approach would be to use the native PowerShell support for administering remote Windows queue managers, but use the custom remote code I’ve written for UNIX-based queue managers.
Alternatively, and perhaps more usefully, for Windows-only environments, a Windows workstation running PowerShell V2 could administer remote Windows queue managers using a combination of the custom remote cmdlet code and native PowerShell remoting. The WMQ cmdlets could be used to access remote queue manager objects while the native PowerShell remoting could let administrators access WMQ config files, WMQ registry keys, queue manager logs, SSL key repository files, and more. The two approaches could actually work together quite nicely.
Tags: cmdlet, powershell, websphere mq, wmq