Design a WSDM interface for Java application servers
To expose the management capabilities of a Java application server via Web services, you need as a foundation the following three things:
- WS-Resource Properties (WSRP) which allow you to manipulate the state of a resource.
- WSDM Identity which provides the standard means of distinguishing one resource from another.
- WSDM ManageabilityCharacteristics which provides clients with a list of capabilities implemented by the resource.
All other features that you add to the Java application server interface depend on one or more of these capabilities.
In addition to basic WSRP and WSDM definitions, you may also want to monitor the performance of the server to keep track of whether it is underutilized (or worse, overburdened). To do this, a PerformanceMonitoring capability is defined with the following resource properties:
- NumberOfTransactions, a metric that tells the client how many total transactions were processed in a given time period.
- TransactionThroughput, a metric that tells the client the percentage of transactions that succeed.
- CurrentTime, a property that is needed to enable the WSDM Metrics capability which maintains the first two metrics.
By adding this capability to the resource type, you alert clients to the fact that they can get performance data directly from the resource. In the real world, you would probably have many more performance metrics, but the example properties here make the point -- performance metrics can be added to a resource interface independently of any other properties or operations. If you were to remove them, the other definitions (WSRP, WSDM, etc.) would not break.
In addition to performance monitoring, the resources also have some features that are directly related to their roles as Web servers. All Web servers have some basic properties and operations that can be described in a Web service interface. For the sake of simplicity, pick two properties and two operations and make them part of a generic WebServer capability:
- Name, the name of the server (as opposed to its host or location).
- Port, the port number of the server.
- Start, an operation that starts the actual server resource.
- Stop, an operation that stops the actual server resource.
As with the PerformanceMonitoring capability, there are many features of Web servers that could make their way into a generic WebServer capability, but for now, the example is short to make it easy to follow.
Now, Java application servers are Web servers, but they are also much more than that -- they have features that are not found on a simple HTTP server and management clients are likely to be interested in those features. To expose some of the Java-specific features of the server resources, define a JavaServer capability that has properties and operations related to the deployment of Java Web applications, like so:
- ApplicationName, the names of all applications currently deployed on the server.
- DeployApplication, an operation that allows clients to deploy a new application on the server.
By separating out the Java-specific features from the general Web server features, you have prepared yourself to reuse the WebServer capability in other resources. The same is true for the PerformanceMonitoring capability. If you need to implement another resource type with Muse and it happens to include a server component or request processing of some kind, apply the current capabilities instead of writing new ones (or cutting-and-pasting the old ones).
Finally, a Java application server is a complex resource type that registers many events every minute and has many clients trying to communicate with it. It is probably the case that management clients need to keep tabs on the server's events as closely as possible. For this purpose, add the WSN NotificationProducer capability to the resource definition. This capability enables the publishing of events to multiple subscribers.