You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2006/07/29 09:06:57 UTC
[PATCH] DataBinding improvements
Hi,
I posted a patch and a draft slide to JIRA TUSCANY-541 (http://issues.apache.org/jira/browse/TUSCANY-541?page=all). I'm sorry that I have to rush it out as a big patch since I go on vacation next week starting from tomorrow.
The patch includes the following:
1) Refactoring and refining of the design
2) Adding Interface and extension base class for extensibilities
3) Adding quite a few transformer implementations
There're still a bunch of issues that we need to flush out and I would like to hear your opinions as well.
1) What's the best way to identify a binding?
I'm thinking of two ways:
a) A flat naming scheme (for example, "sdo:dataobject" for SDO DataObject and "stax:xmlstreamreader" for XMLStreamReader)
b) A typing hierarchary, the 1st level is Technology (such as SDO, JAXB, SAX, DOM and StAX, the 2nd level is Java or XML type, ...
2) What's the extensibility story?
I imagine that a new data binding can be added to the Tuscany runtime with the following:
a) Add a component implementing DataBindingProvider interface (not in the code yet) and register with DataBindingRegistry
b) Contribute a loader and/or annotation processor which knows how to load/introspect the SCDL or java annotation to form DataBindingDefinition
c) Contribute a builder which can resolve DataBindingDefinition to create DataBinding instance so that it can be used by transformers to transform data from the source binding to target binding.
New transformers can be plugged into the system as well. The transformer implementation will be wrapped as a system component and register itself with the TransformerRegistry. The TransformerRegistry calculates the shortest path between two binding types and pass data through the transformer chain.
3) How do we deal with SCA properties?
I'm thinking about to load the XML section into a DOM tree and inject it to the component implementation based on the prefered databinding. The data transformation service will be used by property injectors.
4) For those who implements service/reference binding extensions, how do you want to leverage the databinding framework to deal with transformations such as SDO-->AXIOM or JAXB-->SOAP?
I assume the databinding framework provides a system service for this purpose.
More... (It's getting late now, my brain is hardly working :-(
Your review/feedback will be appreciated.
Thanks,
Raymond
Re: [PATCH] DataBinding improvements
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 29, 2006, at 1:26 AM, ant elder wrote:
> On 7/29/06, Raymond Feng <en...@gmail.com> wrote:
>
> <snip/>
>
> 4) For those who implements service/reference binding extensions,
> how do you
>> want to leverage the databinding framework to deal with
>> transformations such
>> as SDO-->AXIOM or JAXB-->SOAP?
>
>
> I've not looked at the databinding framework in much detail yet, but
> sometime ago there was discussion [1] about extensions just
> declaring what
> data formats they can support and the runtime would take care of any
> necessary transformations based on whats at each end of a wire. So
> like
> that, the Axis2 binding would somehow declare it supports AXIOM and
> just put
> the SOAP body OMElement into the Tuscany message payload.
>
> Is this still the intention for how this is going to work with the new
> databinding framework?
That was what I was expecting things to be able to do. Things
declared what they could put on the wire outbound and accept inbound
- that may be one format, it might be multiple ones.
Chatting with Raymond in Portland, we were talking about describing
the data using three identifiers:
1) the actual Java class that would be in the message. This might be
a user class, it might be some other class that provided access to
the data (e.g. some form of stream or event sink). It is always Java
because the runtime is written in Java.
2) the logical data format that the class represents, commonly the
name of a Java class or an XML type. If the user data is in the
message this will likely be the same; if we have something like a
stream head then it would describe what is on the stream.
3) Additional metadata about the data. This would include things like
the type of binding to use (for example, when the physical and
logical format refer to a Java interface but the user also wants a
specific implementation of that interface), whether the format is a
stream and if so if it is a source or a sink, estimates of the size,
and so on. This is additional information that helps decide which
transformers to use.
So in you example, the Axis2 binding would say at a minimum "I can
put data into requests that will be an OMElement that represents a
{insert QName here} XML type"
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [PATCH] DataBinding improvements
Posted by ant elder <an...@gmail.com>.
On 7/29/06, Raymond Feng <en...@gmail.com> wrote:
<snip/>
4) For those who implements service/reference binding extensions, how do you
> want to leverage the databinding framework to deal with transformations such
> as SDO-->AXIOM or JAXB-->SOAP?
I've not looked at the databinding framework in much detail yet, but
sometime ago there was discussion [1] about extensions just declaring what
data formats they can support and the runtime would take care of any
necessary transformations based on whats at each end of a wire. So like
that, the Axis2 binding would somehow declare it supports AXIOM and just put
the SOAP body OMElement into the Tuscany message payload.
Is this still the intention for how this is going to work with the new
databinding framework?
...ant
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/%3c4418A53D.2080606@apache.org%3e
Re: [PATCH] DataBinding improvements
Posted by Jim Marino <jm...@myromatours.com>.
Hi Raymond,
Thanks. I'll take a look starting Monday as I'm a little backlogged
on some other things. I had planned to refactor some of the property
injection which may fit well with this. More comments inline...
On Jul 29, 2006, at 12:06 AM, Raymond Feng wrote:
> Hi,
>
> I posted a patch and a draft slide to JIRA TUSCANY-541 (http://
> issues.apache.org/jira/browse/TUSCANY-541?page=all). I'm sorry that
> I have to rush it out as a big patch since I go on vacation next
> week starting from tomorrow.
>
> The patch includes the following:
>
> 1) Refactoring and refining of the design
> 2) Adding Interface and extension base class for extensibilities
> 3) Adding quite a few transformer implementations
>
> There're still a bunch of issues that we need to flush out and I
> would like to hear your opinions as well.
>
> 1) What's the best way to identify a binding?
>
> I'm thinking of two ways:
>
> a) A flat naming scheme (for example, "sdo:dataobject" for SDO
> DataObject and "stax:xmlstreamreader" for XMLStreamReader)
> b) A typing hierarchary, the 1st level is Technology (such as SDO,
> JAXB, SAX, DOM and StAX, the 2nd level is Java or XML type, ...
>
> 2) What's the extensibility story?
>
> I imagine that a new data binding can be added to the Tuscany
> runtime with the following:
>
> a) Add a component implementing DataBindingProvider interface (not
> in the code yet) and register with DataBindingRegistry
> b) Contribute a loader and/or annotation processor which knows how
> to load/introspect the SCDL or java annotation to form
> DataBindingDefinition
Yep, sounds right: the loader should do the read from XML; the
annotation processor can introspect the annotation.
> c) Contribute a builder which can resolve DataBindingDefinition to
> create DataBinding instance so that it can be used by transformers
> to transform data from the source binding to target binding.
>
Can you explain more, I'm having trouble following this?
> New transformers can be plugged into the system as well. The
> transformer implementation will be wrapped as a system component
> and register itself with the TransformerRegistry. The
> TransformerRegistry calculates the shortest path between two
> binding types and pass data through the transformer chain.
>
> 3) How do we deal with SCA properties?
>
> I'm thinking about to load the XML section into a DOM tree and
> inject it to the component implementation based on the prefered
> databinding. The data transformation service will be used by
> property injectors.
>
I'd probably have the standard builders (e.g. JavaComponentBuilder)
use the databinding transformation service when it is handling
properties (stored in a DOM representation) to create an
ObjectFactory that instantiates an instance of the property value.
For immutables, the binding service would return a
SingletonObjectFactory.
We may want to extend @Property to take an attribute which identifies
the databinding technology to use. We could also have a default by
component impl type.
> 4) For those who implements service/reference binding extensions,
> how do you want to leverage the databinding framework to deal with
> transformations such as SDO-->AXIOM or JAXB-->SOAP?
>
> I assume the databinding framework provides a system service for
> this purpose.
>
Yep. How about an XStream version for simple POJOs?
> More... (It's getting late now, my brain is hardly working :-(
>
> Your review/feedback will be appreciated.
>
> Thanks,
> Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org