CL Measurement Point Service
From GEANT2-JRA1 Wiki
CL Measurement Point Overview
The idea behind the Command-Line MP Service is that it can be used to integrate any command-line measurement tool into the pSonar framework.
It will not have the full functionality envisioned for an MP. For example, there will be no scheduling. However, it should be possible to take the CL-MeasurementExecutor class and use it within a more functional MP that implements scheduling. This is just a dumb service engine to allow on-demand things to happen while the more difficult things are completed.
The CL-MeasurementExecutor class acts as a wrapper around any command-line tool. Each command-line tool will need to have a "bundle" defined for it. The ToolBundleFactory class will consult the service configuration to determine where the ToolBundles are and how to load them.
CL Measurement Point UML
Dia source for CL-MP-classdiagram (Use the "Save Link As..." feature of your browser - the correct filetype has not been defined.)
How the CL Measurement Point Fits Into the Framework
The client will create a request "Message". That message will hold some number of Data and Metadata elements. (Sometimes the Metadata is chained like a linked list so the Data elements are used to point at the "head" of each list of Metadata.) In the Java implementation each element is parsed into a Java object representation.
After the client sends the request XML message to the web service, it is parsed into the Java object representation and then passed into the "execute" method of a MessageHandler. (In this case the MeasurementRequest MessageHandler.)
The MessageHandler will understand the specific format of a MeasurementRequest message and be able to pull apart the message into individual requests. (A single Data object, and all the metadata objects required to serve that request.) It will create an instance of the appropriate ServiceEngine class. (In this case, the CL-MPServiceEngine.) Then the MessageHandler calls the takeAction method of that class with a Message object comprised of the single Data object and associated Metadata objects that uniquely define an individual request.
The CL-MPServiceEngine will look at the individual request. Because the only thing this version of the CL-MPServiceEngine will do is call the CL-MeasurementExecutor it is very, very simple. (In the future the CL-MPServiceEngine will need to understand some scheduling Metadata constructs and do more but for this prototype version I think we can just deal with a single Metadata element per request. Therefore, it will essentially just pass the Message object it receives right onto the CL-MeasurementExecutor)
The Metadata in the "request" Message that is passed into the makeMeasurement method of the CL-MeasurementExecutor will have an Eventtype element that will describe the type of measurement request that is being made. (Say, ping or bwctl) Based on that event type, the CL-MPServiceEngine will need to create an instance of the correct associated ToolBundle from the ToolBundleFactory and then call the runTool method of the ToolBundle. (I am not positive I have the method signature correct of runTool yet - I think it will only need the "leaf" Metadata to actually run the tool - but if that ends up wrong, then I may need to pass in something else. And I am almost certain that it will need to return a full Message object at this point.)
