Re: [BRAINSTORM] Future improvements for Tuscany databinding framework
Raymond, All of these sound interesting. A minor point: In making the databinding framework easy to use as a utility it would help to refactor out the exception/fault matching code so it's not tied to an interceptor, as other users of the Mediator may need to do the same routine. Another possible addition to the list that we've talked about in the past: * Define a way to use wrapped WSDL together with non-wrapped (bare) Java On Mon, May 12, 2008 at 5:56 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, 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. * 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 * More and better documents Thanks, Raymond
Re: [BRAINSTORM] Future improvements for Tuscany databinding framework
Raymond Feng wrote: 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. Being a developer, I may be biased towards items that make the developer's life a bit easier, so I tend to favor ease of use over new features. Given that, here are 3 I would vote for: * Refine/simplify the databinding SPIs (for better extensibility and consumeablity) * 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) Additionally, I think the following item is well-worth the effort to popularize Tuscany and make it easier to adopt and implement. * More and better documents -- Thanks, Dan Becker
Re: [BRAINSTORM] Future improvements for Tuscany databinding framework
Raymond Feng wrote: Hi, 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. That's a nice list, I marked the items I feel really important with +1 and some comments. * Refine/simplify the databinding SPIs (for better extensibility and consumeablity) +1 to simplify and crisp-up some of the concepts and the interfaces that represent them, for example IIRC a databinding can have an id, a name, an alias, I'd suggest to just have an id :) * 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.) +1 I remember I needed that in the ATOM binding. Other bindings could leverage that too. * 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) +1 that's really really important. I can summarize the most annoying problems I've seen with SOA runtimes the last few years as follows: - I have this big giant XSD that my developers dreamed up and when I try to use it and XML instances of it the whole JVM blows up - Looks like my business object is copied and converted between XML and 8 different forms of Java databindings approx. 37 times per transaction, is there any way to improve that? :) * Better support for collective/aggregate data types such as java.util.Collection +1 and also I'd add support for Java Generics as that's becoming a common way of parameterizing generic business interface patterns. * 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 For that one, can you say a bit more about the scenario and the issues with the current databinding framework? * More and better documents Thanks, Raymond -- Jean-Sebastien
