Community
Participate
Working Groups
It's currently difficult for adopters to determine the outputters required for retrieving data from COSMOS services. COSMOS can use DOJO's simple method description to provide a clear abstraction for adopters to invoke any COSMOS services. This will make mash-ups a lot easier. The simple method definition is a JSON file defining the APIs available for adopters to invoke. Here's an example of a definition file: { "serviceType": "JSON-RPC", "serviceURL": "http://localhost:8080/HelloWorld/hello", "methods":[ { "name": "add", "parameters":[ {"name": "x"}, {"name": "y"} ] } ] } and here's how it can be invoked in JavaScript: var svc = new dojo.rpc.JsonService("http://localhost:8080/AJAXProject/examples/misc/remote/definition.smd"); var myDeferred = svc.add(5, 8); myDeferred.addCallback(myCallbackMethod); This enhancement will involve: 1) Defining Simple Method Descriptions for COSMOS services (e.g. Broker.getDataManagers()) 2) Rewriting existing code to use SMD files instead of a parameterized URL
Changing Priority to P2. P2 - enhancements that are targeted for the iteration P3 - enhancements that could potentially be pushed out of the iteration
Discussed in Community call and agreed to push out to i12.
Reassigning to JT as discussed in DV call
Reference doc http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo/ajax-transports/remote-procedure-call-rpc - JT
Note: References to "simple method description" refer not to the english language phrase but an actual DOJO element called "Simple Method Description(tm)", I personally would've named it something else...but that's just me. - JT
All services now have smd files in their WebContent/WEB-INF/services/<servicename> directories. - JT
Looking at changing the structure of the SMD file instead of the EPR of the service list as the serviceURL, the serviceURL will be a pointer to some bridge code (very similar in functionality to an outputter) and the EPR will be embedded in the SMD file somehow...exactly how is still unclear. - JT
Here's what I can do so far.... For doing a query, I've got a smd file that looks like this { "serviceType": "JSON-RPC", "serviceURL": "http://localhost:8081/COSMOSUI/json?service=SMDService", "methods":[ { "name": "MyQuery", "parameters":[ {"name": "query"}, {"name": "mdrEPR"}, {"name": "uuid"}, {"name": "username"}, {"name": "password"}, {"name": "soapversion"}, ] } ] } if OutputterDelegator, in the delegateRequest method, I trap for this kind of query like this String service = req.getParameter("service"); //$NON-NLS-1$ if (service.equals("SMDService")) { JSONObject jsonObject = new JSONObject(req.getReader().readLine()); if (jsonObject.get("method").equals("MyQuery")) { JSONArray jsonArray = (JSONArray)jsonObject.get("params"); String query = (String) jsonArray.get(0); String mdrEPR = (String) jsonArray.get(1); String uuid = (String) jsonArray.get(2); String username = (String) jsonArray.get(3); String password = (String) jsonArray.get(4); String soapversion = (String) jsonArray.get(5); What would then have to happen is these values would be set in the IParameter object map that is passed to the outputter, then the outputter is called as it normally is. Then in Navigator.js getCMDBfReponse, instead of calling SubmitQuery it'd look like this var ws = new dojo.rpc.JsonService("http://localhost:8081/mysmd.smd"); var deferredObject = ws.MyQuery(item.query,queryEPR,item.uuid,null,null,null); deferredObject.addCallback(onItem:function(response) { item.queryResponse = response; if (args.onItem){ args.onItem(response); } });
Moving to i13 as discussed in DV call
Comments from sheldon You should create a class that implements a IParameters that takes in a JSONArray instead of a HTTPRequest. Also I'm thinking we should add a new method on the IOutputter class that returns a static String array that defines the parameters and the order. This will make the outputters backward compatible and able to work with http requests. This is the method I'm thinking. public String[] getParameterMetaData() Each outputter would define this method. From your example the outputter would define the getParameterMetaData as follows: public String[] getParameterMetaData(){ return {"query", "mdrEPR","uuid","username", "password", "soapversion"}; } In the OutputterDelegator class we could add the following code JSONParametersImpl parameters = new JSONParametersImpl(jsonArray); IOutputter outputter = createOutputter(service, req.getSession()); parameters.setParameterMetaData(outputter.getParameterMetaData); You can implement the JSONPatametersImpl.getParameter as follows public String getParameter(String name) { //get index int idx = -1; for (int x =0; x<metadata.length; x++){ if (metadata[x].equals(name)){ idx = x; break; } } return request.getParameter("Parameter"+x); }
I've written JSONParametersImpl. should come up with a convention for service names, like prefixing them with SMD or something. That way we can say if (service.getName().startsWith("SMD")) { // do SMD stuff } - JT
(In reply to comment #11) > I've written JSONParametersImpl. > should come up with a convention for service names, like prefixing them with > SMD or something. > > That way we can say if (service.getName().startsWith("SMD")) { // do SMD stuff > } > > - JT > We should not change the service name. We should add a parameter called inputType One could call the services as follows: json?services=/org/eclipse/cosmos/myoutputter&inputType=SMD
yes ok, that sounds good. - JT
Moving ER out of i13 as it can not be contained.
