I was thinking it would be a system service since it appears to be
applicable to a wide variety of things in the runtime. Having it as a
system service also allows it to be managed and autowired to other
extension points (e.g. services, bindings, components that may want
to use it).
If it were a system service, we could also make the mediator itself
extensible so people could plug in their own transformation code. It
would be similar to the SCDL loader or builder registries where the
transformation extensions would be system services that self-
registered with the mediation registry. If this makes sense to do,
having a transformation extension could involve writing the extension
as a POJO and a SCDL component entry and dropping it into the runtime.
I think it was Sebastien who mentioned it would be valuable to be
able to drop any extension point into a specific runtime location and
have it registered in the runtime. In a similar way, perhaps we
could even eliminate the need to write SCDL and just have the class
(or jar) "deployable" to the runtime directly. We could place
restrictions such as without SCDL, the class would need to be
decorated with @Service so arbitrary things don't get picked up (i.e.
we may want to restrict arbitrary things on the classpath from being
registered). What do people think?
Ant has been dealing with E4X in JavaScript so perhaps that could be
one of these mediation extensions. Raymond, was this similar to where
you were thinking of taking the mediation layer?
Jim
On Jun 28, 2006, at 11:06 PM, Liu, Jervis wrote:
Hi Raymond,
I think the question to be answered is how this data mediation is
supposed to be used. For example, shall I use this data mediation
as a java util just same as how I use SDOXMLHelper.java before? In
this way, the data mediation might look like a replacement or
enhancement to SDOXMLHelper.java (and other similar helper
classes). Or, as one email suggested, do not embed this into SCA
core, instead make data mediation act as a pluggable system
service, which can be used in a wilder context, such as content-
based routing, data transformation etc.
Cheers,
Jervis
-----Original Message-----
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 29, 2006 12:37 AM
To: [email protected]
Subject: Re: Status of databinding module in sandbox and DataMediation
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]
