Page History

To improve the Tuscany databinding framework for simplicity and flexibility,
I come out a list of potential TODOs. Your feedback/ideas/help will be very
welcome.

Overview

• Refine/simplify the databinding SPIs (for better extensibility and
  consumeablity)
• Make the databinding framework easy to use as a utility in addtion to an
  interceptor (Ideally, other projects can leverage this framework without
  pulling into the whole tuscany runtime. I think we are very close.)
• Use MIME types to model the databinding ids (for example, application/xml,
  application/x-java-serialized-object, image/jpeg)
• Support MIME based binary data types (incuding the xmime extensions in
  WSDL/XSD)
• Improve the performance of key transformers (such as JAXB <--> AXIOM, we
  could reuse some JAXB code from Axis2 JAXWS support)
• Better support for collective/aggregate data types such as
  java.util.Collection
• Support annotations of a java type (for example, an InputStream can be
  used to contain different formats of data) to further constrain the data
  type (We could use the JAXB annotation for this purpose)
• Find better ways to represent the databinding requirements for bindings
  which weakly-typed message structure (no well-defined wire format) such as
  JMS Message or JCA Record
• JAX-WS Holder support (additional detail below)
• RPC-literal
• XML Catalog for XML artifact resolving
• More and better documents

http://markmail.org/message/4iazlvo23qq3tho4?q=Future+improvements+for+Tuscany+databinding+framework

JAX-WS Holder Support Detail

This section describes the JAX-WS Holder support in more detail, and gives several sub items
that provide support.

Jira discussed on http://issues.apache.org/jira/browse/TUSCANY-2332.
Discussion from the Tuscany dev list http://marc.info/?l=tuscany-user&m=121895603228804

• Update Tuscany org.apache.tuscany.sca.interfacedef.Operation or Typedef class to provide more IDL information than just name and input and output and fault data types. Allow meta data to be attached to input and output types to support more IDL languages. Specifically, WSDL and web services support the notion of an INPUT/OUTPUT parameter (e.g. mode=WebParam.Mode.INOUT). (Done Jira TUSCANY-2332)

• On the client side, JDKInvocationHandler implementation must understand the Holder pattern and be able to remove the generic data (e.g. T in Holder<T>) and pass along the generic data to Java interface factory. (Done Jira TUSCANY-2332)

• On the server side, JavaImplementationInvoker must understand the Holder pattern and be able to package the generic data (e.g. T) into a Holder and pass along to the Java implementation. (Done Jira TUSCANY-2332)

• Support Holder pattern on request input/parameter path and void return type. (Done Jira TUSCANY-2332)

• Support multiple Holder patterns on request input/parameter path. (Tuscany 2.x)

• Support Holder patterns on non-void return types. (Tuscany 2.x)

• Support the common pattern <T> method( <T> ) where a data type T is provided on input and again returned on response. Recognize same data type and reuse it, and save the cost of doing an object construction. (Tuscany 2.x)

• Provide test cases that illustrate these issues. (Done - There is an OrderService Order project that provides this functionality and demonstrates various Holder patterns. This is attached to Jira TUSCANY-2332 and will be committed via separate Jira.)

Note: Jira Tuscany-2332 has the limitation that only one input parameter Holder is supported, and this is further limited to methods with void return type (implementation uses return type to return in out parameter).