[jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1605) management API needs a portable and complete serialization format

management API needs a portable and complete serialization format ----------------------------------------------------------------- Key: JBMESSAGING-1605 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1605 Project: JBoss Messaging Issue Type: Bug Components: Configuration and Management Reporter: Jeff Mesnil Assignee: Tim Fox Fix For: 2.0.0.CR1 Attachments: patch-JBMESSAGING-1605.txt to work in a replicated environment; JBoss Messaging needs a Management API which requires complex parameter. E.g. public void createConnectionFactory(String name, List<Pair<TransportConfiguration, TransportConfiguration>> connectorConfigs, String connectionLoadBalancingPolicyClassName, long pingPeriod, ...); TransportConfiguration also contains a Map<String, Object> of parameters. Currently, the management code does not allow for such complex API. It only works with simple types (primitives + Strings) and String[]. Moreover, the management API returns results (attribute values or operations results) serialized using Java serialization which won't be portable on other platforms. We need to define a encoding format for Management API that allow complex parameters and be portable. One idea'd be to use JSON[1] for that (JSON for Java is 7 classes[2] we could import in JBM source code). With that, the management operations would be composed of a JSON string containing: - the name of the resource - the name of the operation - an orderded list of the parameters (as complex as they are) When JBM receives a management operations, it must decode the JSON strings and find the relevant methods to call. There is an issue here, JSON does not contain any information on the types of parameters. One solution is to add the parameter type in the JSON string (e.g. this JSON object can be decoded as a TransportConfiguration class) but it add extra burden on the client sending the message and is not well suited for portability reason. Another solution would be to add an additional layer on the server side. When a management message is received, we extract the name of the resource, the operation name and the number of parameters of the operation. We'd have a mapper which will know based on this information what method should be called on the resource and cast the parameters from JSON to the appropriate types (e.g. Boolean, String, int but also TransportConfiguration). The only constraint this solution have is that there must not be 2 methods on the same resource, with the same name and the same number of parameters. The cardinality of the methods must differ to be able to identify it uniquely. If the methods have the same numbers of parameters, they must have different names (e.g. createConnectionFactoryWithDiscoveryGroup() vs. createConnectionFactory() which takes a List of Pair of TransportConfiguration) For return type, we could return a JSON String containing the result. This would allow for complex results (similar to CompositeData and TabularData from JMX). [1] http://www.json.org/ [2] http://www.json.org/java