Hi Raymond,
I just downloaded the prototype. It looks great to me. A couple of questions
based on my immediate use case that is to do the data transformation(xml to
sdo, sdo to xml etc) in Celtix binding:
1. How do I use DataMediation as a system service in binding extension.
According to my understanding the steps involved are as below:
Step one: Look up TransformerRegistry.
Step two: Use input/output type to resolve a transformation path.
Step three: Invoke transformers in sequence according to the transformation
path.
Is this correct?
2. Performance:
As data transformation is Heavily used in binding to process inbound and
outbound messages, any minor improvement on performance may have a big impact.
I wonder how we can eliminate step one and two for messages processing. For
step one, maybe TransformerRegistry can be injected into SPI Binding during
composite loading phase? For step two, in a particular binding type the
transformation path should be fixed. In this case, can we store the required
transformer instances(and the sequence) as a static member in binding? This is
also relevant to the point 6 below, if transformers are handled internally
inside DataMediation service, we need to make sure the creation of transformer
chain and the maintenance of transformer instances does not have any negative
impact on performance.
Any comment?
3. Is Mediation service thread safe?
4. Shall we use this DataMediation to replace SDOXMLHelper.java and similar
util classes in M1?
5. If we are about to replace SDOXMLHelper, I guess the binding extension
doesn't need the TypeHelper anymore. But does the Mediation service need
TypeHelper?
6. To simplify the transformer interface, is it possible to hide following code
in Transformer?
List<Transformer> path = registry.getTransformerChain(XmlObject.class,
DataObject.class);
System.out.println("Path: " + path);
Object result = object;
for (Transformer transformer : path) {
result = transformer.transform(result, null);
}
Shouldn't the transformer chain be an internal knowledge of DataMediation
service? Given an input and an output type, it is the DataMediation service's
responsibility to figure out the shortest transformer chain and invoke the
chain in sequence. From users point of view, input and output type are all they
need to know.
Thanks,
Jervis Liu
-----Original Message-----
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 29, 2006 3:04 PM
To: [email protected]
Subject: Re: Status of databinding module in sandbox and DataMediation
Hi, Jim.
You can download the prototype from
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)TuscanyJava(2f)DataMediation/attachments/tuscany-databinding.zip.
The file can be directly unzipped into sca/databinding folder and the
project has been configured to be built with maven. You may see some test
case failures with maven but they are all running fine inside Eclipse. It's
probably due to a classpath issue that I have yet to figure out.
The prototype has the following features:
1) Experimental interfaces for Transformer, TransformerRegistry, DataPumper
and DataPipe.
2) A directed and weighted graph with the shortest path algorithm.
3) Experimental Transformer implementations for various data bindings,
including SDO, JAXB, XmlObjects, Axiom, StAX, DOM, Stream and String.
4) Maven build will automatically generates related classes for SDO,
XmlObjects and JAXB based on ipo.xsd
5) Test cases demonstrate the usage
Here are some TODOs in my mind.
1) Define the data mediation system service (similar to the
BuilderRegistry/Builder and LoaderRegistry/Loader relationships)
2) Define how to describe a data binding for SCA artifacts (for example,
references and services), something like <db:databinding.xxx/> (Potentially
a proposal for the spec?)
3) Work out the contract interfaces and extensibility for the framework
4) Align the property story with the framework which may be able to present
the property value in the specified databinding type to the component
implementations
5) Split the project into multiple ones: one for the framework and each per
data binding
6) Add more data bindings
Any feedback will be welcome.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, June 28, 2006 10:23 PM
Subject: Re: Status of databinding module in sandbox and DataMediation
> Hi Raymond,
>
> I think this would be really good to get it into the sandbox. Can you
> point me to the latest patch and we'll get it in ASAP?
>
> Jim
>
> On Jun 28, 2006, at 9:36 AM, Raymond Feng wrote:
>
>> Hi,
>>
>> Do you think if my prototype can be used as a seed to flush out a good
>> data mediation story? If so, does it make sense that somebody commits it
>> into the sandbox to get more people involved? I'll update the wiki page
>> as I add more things.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Jeremy Boynes" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Wednesday, June 28, 2006 9:01 AM
>> Subject: Re: Status of databinding module in sandbox and DataMediation
>>
>>
>>> On 6/28/06, Liu, Jervis <[EMAIL PROTECTED]> wrote:
>>>> Hi,
>>>>
>>>> databinding module in sandbox is not included as part of build at the
>>>> moment. Are we going to still have this module in the new core?
>>>
>>> I think so, yes.
>>>
>>>> In Monday's IRC chat, Jeremy mentioned that we need to fix the version
>>>> in the sdo databinding pom, is anyone working on this right now?
>>>>
>>>
>>> I'm not. Raymond also had a patch for it that I should apply - it's
>>> just that it is related the the type helper hierarchy issue that we
>>> still need to resolve.
>>>
>>>> Also SDOXMLHelper.java is missing from sdo databinding(java\sca
>>>> \databinding\sdo\src\main\java\org\apache\tuscany\databinding\sdo
>>>> \SDOXMLHelper.java in M1 repo). Is there any reason why it is not
>>>> there?
>>>
>>> No - it could just be that the code was copied before it was added.
>>>
>>>> I will need this class to do the conversion between xml stream and sdo
>>>> object in Celtix binding. Or maybe, we are going to the DataMediation
>>>> proposed by Raymond?
>>>>
>>>
>>> I think we will do something like that. I've not fully grokked Yang's
>>> mail on this yet (the streaming one).
>>>
>>> --
>>> Jeremy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
