WS-Management Specification

The WS-Management specification builds upon several other Web Service specifications including:
  • SOAP 1.2
  • XML Schema
  • WSDL/1.1
  • WS-Addressing
  • WS-Eventing
  • WS-Enumeration
  • WS-Transfer
  • WS-Policy
  • WS-Trust
  • WS-Security
  • WS-Security Utility
There are a variety of locations where these specifications are extended, but the WS-Management specification also serves as a consolidation point for how to use these other specifications to achieve a holistic view of resource management.

There are meaningful extensions to each of the specifications and the specification seems to be loosely organized around the various specifications that WS-Management uses to form the basis of resource management.  The TOC (if you're interested) is:
  • Introduction
  • Addressing
  • WS-Management Control Headers
  • Resource Access
  • Enumeration
  • Custom Actions
  • Eventing
  • Metadata and Discovery
  • Security
  • Transports and Message Encoding
  • Faults
Overall, its pretty dry reading and you don't really get a feel for many of the important pieces of the specification.  Some of the early sections like Addressing have substantial examples, but I felt the real meat of the specification was in the Enumeration and Eventing sections.  These had fewer examples, unfortunately.  I'm going to spend the next few weeks, I think, looking into how to implement these in the wiseman project. 

There are numerous extensions to the base specifications identified above.  Most of the extensions are focused on enhancments to the addressing schemes to deal with the granularity of resources, reliability options in the underlying web services interactions, efficiency of information retrieval (due to the often large data sets associated with a resources), and options in the underlying protocols to address often complex management networks.

One interesting extension to WS-Event is the concept of a "Bookmark" <wsman:Bookmark>.  Bookmarks are sent from the server and associated with an event generated in the server.  A client can store the bookmark on their side.  Later, the client can send the bookmark to the server as the position to start receiving events from in the server side's log.  The implications of bookmarks on the server code are simply that the server must have a log of events with bookmarks rather than a fire/forget model.  The clients can also start replaying events from the server from any location in the bookmark history (with server-side limitations such as bookmark longevity taken into account).  This is a convenient way to ensure lossless eventing.

Overall, the additions to the specification are good for not just the management arena, but Web Services in general.  As a result, it seems that over time, it would be more helpful to see the WS-Management enhancements to the underlying specifications be pushed back to their specifications of origin (such as WS-Event).  The reason is simple, in its current state, off the shelf Web Services tools (such as Axis) will be unlikely to support WS-Management out of the box...necessitating projects like wiseman (referenced earlier).  This is an unfortunate reality of creating new specifications.  Hopefully, as I mess around with wiseman I'll come to a different conclusion (and if anyone knows better, please correct me early ;-)

FURTHER, I've never found that operating Web Services at the SOAP tier was efficient for programmers.  Language bindings based on the WSDL are the way to go.  BUT, language bindings and stubs/skeletons are complex (I've worked with them since CORBA days in SOM, RMI, and numerous distributed object technologies).  It is more efficient to get reuse from existing tools than to have to build more tools.

Next, the WS-Management specification can only go so far.  WS-Management gives an efficient and optimized framework for interaction with the management path of resources.  Frankly, that's the easy part.  Standard MODELS are the difficult part.  Storage Management has the Storage Management Initiative (SMI) to aid in this effort with the SMI Specification (SMI-S).  The mapping from SMI-S models to WSDL and through the WS-Management extensions is a critical next step (already being worked on).

Once the mappings are figured out, then the move from WBEM to WS-MAN should get under way.  It will take 1-2 iterations to get everything proper and efficient.

You'll notice I moved from WS-Management into Storage Management...but remember, I'm a storage management kind of guy.  The implication you should be getting is that I believe WS-Management is the shortest path to integrate Systems and Application Management with Storage Management.  The efficiency of having a single underlying management protocol for all tiers of the data path (from origin of the data to data's resting places) is a necessity to create a single "machine" out of the disparate networked components.  Without the single underlying protocol, models and tools, it is inefficient to build global management tools and, as such, the barrier to entry will be too high to create tools to efficiently manage the entire data ecosystem.  What does this matter to the end user?  Well, the COST of the management tools will be prohibitive and only accessible to companies with a serious amount of money to invest.

Standards that bridge the gap between systems and storage will create innovation and competition.

Bring on WS-Management.

(I reserve the right to back-peddle and ignore everything in this post after I get some hands on coding experience :-)


Comments:

nice summary, looking forward to hearing more about your experiences as you play more. I have high hopes of this becoming a very useful standard for all of us.

Posted by Jon Greaves on June 28, 2006 at 01:26 AM MDT #

Post a Comment:
Comments are closed for this entry.
About

pmonday

Search

Archives
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today