Currently we use java.lang.Method to represent operations in the
runtime. It has been brought up by various people that this is not
ideal, for example, in dealing with E4X, data binding, and proxying
strategies that do not rely on reflection. It has also been an issue
with callbacks as we are having to imbed knowledge of Java
annotations related to asynchrony into the connector. Instead, I
think we need to have a general base representation of operations and
service contracts in general. One of the original problems we
encountered that forced us to move from a neutral representation to
java.lang.Method was the complexity of dealing with the model when
code needed to map from the general representation to the specific
operation, e.g. a method on a class. This can probably be alleviated
by using the pattern we have adopted with the current model where a
base class is extended with one that provides a more specific
representation, for example JavaMappedProperty, JavaMappedReference,
and JavaMappedService. Similarly, we could do something to the effect
of JavaMappedServiceContract.
Another issue that has come up is representation of data binding
types for parameters. We could perhaps have a generic representation
of an operation, Operation, that has a getParameterTypes() which
returns a collection of Class elements. The actual class elements
would correspond to type system of the specific data binding used.
Now that the wiring has been moved completely into the wire service
and we are working on a number of extension types, I believe it would
be a good time to get this figured out.
Thoughts?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
