dale lane

When I wrote the PowerShell snap-in for WebSphere MQ, I chose to implement it as a set of cmdlets.

PS C:\> $myqmgr = Get-WMQQueueManager DALE
PS C:\> Get-WMQQueue -Qmgr $myqmgr

They are new commands for WebSphere MQ – commands that let you get, create, modify new objects representing WebSphere MQ objects.

The commands are consistent with existing commands in syntax and style, to be sure. But, they’re still new commands.

I didn’t have to do it this way.

I could have implemented it as a provider. It could have looked something like this:

PS C:\> cd WMQ:
PS WMQ:\> dir 

Name
----
DALE
QMGR2
QMGR3
QMGR4

PS WMQ:\> cd DALE
PS WMQ:\DALE> dir

Name
----
Queues
Channels
Listeners
Services

PS WMQ:\DALE> cd Queues
PS WMQ:\DALE\Queues> dir

Name
----
MyQueue1
MyQueue2
MyQueue3
...

There aren’t new commands.

It’s a new data source.

It exposes WebSphere MQ and it’s objects as a data provider, in a way which is consistent with existing providers like the filesystem, registry hives, and so on.

Did I make the right choice?

This was a tough decision, and I changed my mind on this countless times. In the early days of writing the WMQ PowerShell library, I would start writing cmdlets, then abandon it and start on a provider… then abandon it and go back to cmdlets. Back and forth.

Looking at it again today, I’m still not 100% convinced that I made the best choice. But there came a point where I had to choose one way and stick with it.

That feels like a long time ago now, but I’m remembering it because I’m trying to make the same decision again – this time for DB2.

I mentioned last week that I’m toying with the idea of writing a PowerShell extension for DB2. And one of the first design decisions to make is “cmdlet or provider”.

What do people think? Which would be the best way to work with DB2?

Actually… the decision doesn’t have to be quite so black-or-white. Perhaps a good compromise is to use a combination of both. In hindsight, that might have been a better approach for the WMQ extension.

Microsoft SQL Server perhaps provides some context for the best approach to follow. I’ve not had a chance to see their implementation, but there is an interesting perspective on it on Richard Siddaway’s blog:

…overall impression was that the provider model was the incorrect path to take for administering SQL Server via PowerShell.

Having spent a long time thinking about the provider vs cmdlet model for using PowerShell I think in the long run that the cmdlet model is the more powerful administrative tool.

Cmdlets provide access to a very rich and powerful interactive experience at the command line and also provide a tremendously powerful scripting capability. The provider gives us the capability to interactively browse the data store which can be very useful but it does not provide any more interaction with the objects than could be achieved through scripting in PowerShell (possibly using .NET classes to extend the scripting capabilities).

I remember being very keen to use the Active Directory provider from the PowerShell Community Extensions when it became available. Having experimented with the provider I have effectively stopped using it apart from in PowerShell demos – always impressive to dir through AD! – or to occasionally browse AD.

I am not anti-provider. I just think that the cmdlet model gives more flexibility and functionality for administrators.

The other Microsoft products – notably Exchange 2007 – have provided a rich suite of cmdlets that provide a superb interactive and scripting experience. A provider only model will leave SQL Server a second class citizen in the integration and automation world.

Perhaps a good compromise is cmdlets for administrative tasks, and a provider for data related tasks.

In WMQ terms:

• cmdlets for defining / altering / deleting queues
• providers for getting or putting messages

What would that approach look like in DB2?

Tags: ibm, microsoft, powershell, websphere mq

This entry was posted on Tuesday, February 12th, 2008 at 11:31 pm and is filed under code, ibm. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.