In Windows 8/Windows server 2012 we introduced new Management Infrastructure (MI) API for writing WMI provider and client applications. This blog post will explain our goals for "Improving developer Experience" and WHY we did a new API for client and provider, instead of updating existing WMI API.
We will continue to cover “HOW” to write providers and client applications using the new API in the blog series started by Haowei.
First a bit of recap:
Last year in March we had a blog post from Jeffrey and Wojtek explaining the big picture of Standards Based Management in Windows Server 2012 and Window 8 . To recap, our goal for WMI and WinRM in Windows 8 was the following
* Dramatically reduce the effort required to write WMI providers and standards-based management tools
* Update our code to comply with the latest DMTF standards
* Tightly integrate WMI, WinRM and Windows PowerShell
* Provide a clear and compelling value proposition for everyone to use standards based management on Windows or any other platform.
WMI was introduced way back during the days on Windows NT ; yes – and it just seems like yesterday but a lot of water has flown under the bridge. Things were changing for server - we are now best Cloud OS, and manageability is one of our key differentiators ( instead of some side thought as it used to be)
In the early days of Windows 8 planning, we had detailed discussions with partners and customers. Few things popped up early on
1. Writing WMI providers and client applications is complex. There is a learning curve and it requires knowledge of underlying infrastructure (COM, complex ref-counting , WMI engine complexities and so on)
2. Our infrastructure was not fully aligned with latest DMTF standards.
3. Last but not the least, some partners were not clear if they should write WMI providers or PowerShell cmdlets (We said both, and the answer was "come on - that is a lot of duplication")
This was great feedback. In order to meet the goals for Windows server to be the best cloud OS and meet our commitment for standards based management, we made it a goal to "Improve developer experience". This can be explained as following..
1. Simplify provider development process
- Hide the complexity of underlying infrastructure.
> Developer should focus 100% on business logic.
- Streamline end to end process (design, develop, deploy, test) -
> Generate strongly typed skeleton code from MOF,
> Provide compile time checking and type safety.
> Reduce the amount of code required to be written.
> Simplify provider registration.
2. Simplify client development
- Hide the complexity of underlying infrastructure (including the protocol - DCOM or WinRM)
- Simple Sync and Async models for all standard operations.
3. Enable tight integration with PS.
- Make WMI and CIM standard first class citizen in PowerShell
- Remove duplication of effort in writing WMI provider and PS Cmdlets.
4. Align with latest DMTF standards.
- Make WsMan as the default protocol for client-server communication
- Update the schema to CIM schema 2.6
As you can see, it was simply not possible to achieve the goals outlined above with existing API. We needed a new "model" built from scratch - retrofitting and old model was not going to get us where we wanted to go.
We introduced new “Management Infrastructure API” or MI API for writing providers and client. This is going to be the API going forward - although old API is still supported, it will be in maintenance mode. All our future development effort will go towards the new API.
By the end of Windows 8 development cycle – we were glad to see many-fold increase in adoption of WMI and WinRM. We changed the developer perception (inside Microsoft) from “COM-plex to CIM-plified”.
To summarize, following were some of the highlights for Server 2012 release last year.
- Biggest increase in number on providers shipping in box in many releases
- ~1000 new cmdlets written using new MI provider API – with WS-Man as the default remoting protocol.
- New Server Manager built using MI Client API - with WS-Man as the default remoting protocol.
- New CIM Cmdlets built using MI Client API - enabling PowerShell to manage non-Windows systems and devices. (This was covered in a previous blog: Introduction to CIM Cmdlets)
Hope this blog explained the rationale and reason behind introducing a new model for writing providers and clients. Questions /comments are welcome - leave a note in the comments section below and we will get back to you.
Program Manager - Standards Based Management