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]
