Hi,
I had an IRC chat with Jeremy on this topic, please see the transcript
attached below.
Here's a summary.
1) SCDL extensions (maybe vendor-specific) can contribute extra context (for
example, SDO TypeHelper) to Tuscany runtime components.
2) We only support a fixed type of builders today and it should be generized
to support other types
3) A 2-step delegation can be applied.
Deployer -->
Builder -->
Generic Component Builder (keyed by ComponentDefinition.class) --->
ComponentBuilder keyed by Implementation classes
Generic Service Builder (keyed by BoundServiceDefinition.class) -->
BindingLoader keyed by Binding classes (Which can in turn support multiple
bindings)
Generic Reference Builder (keyed by
BoundReferenceDefinition.class) --> BindingLoader keyed by Binding classes
(Which can in turn support multiple bindings)
...
MyExtension Builder (keyed by MyExtensionDefinition.class)
Thanks,
Raymond
==========================================================================================================
(2:22:28 PM) rfeng: jim/jeremy?
(2:23:14 PM) jboynes: hi
(2:23:15 PM) rfeng: a question for you
(2:24:01 PM) rfeng: import.sdo populates a TypeHelper and I want to have it
accessible from runtime context Reference/Service
(2:24:17 PM) rfeng: import.sdo is done at "load" phase
(2:25:06 PM) rfeng: baiscally, I want pass or associate some info from load
phase to the runtime
(2:25:56 PM) rfeng: I hacked to store it in deploymentContext in the load
phase and retrieve it from the build phase
(2:26:45 PM) jboynes: not really in favour of that
(2:27:20 PM) jboynes: I'd be ok with storing it in the composite
(2:27:30 PM) rfeng: I understand, that's why I ask this question (The post
on the mailing list are for the same purpose)
(2:27:36 PM) jboynes: but not as a TypeHelper
(2:27:46 PM) jboynes: yeah (I've been on the phone for hours)
(2:28:44 PM) rfeng: The association of composite with some other runtime
context, yes, that's the feature I'm looking for
(2:29:11 PM) rfeng: what's in your mind instead of TypeHelper?
(2:29:46 PM) jboynes: I'd want a solution that is not tied to SDO i.e so
there is not SDO dependency in the code
(2:29:52 PM) jboynes: s/code/core/
(2:30:03 PM) rfeng: right, same here
(2:30:22 PM) jboynes: as we will have exactly the same issue with e.g. JAXB
(2:30:31 PM) rfeng: y
(2:31:31 PM) rfeng: In the post, I'm exploring the possibility that an
extensibility element can contribute runtime context to the SCA objects
(2:32:22 PM) jboynes: I didn't quite follow that but it seemed odd - iirc
Jim had issues
(2:32:53 PM) jboynes: I'm not sure how extensible this needs to be - i.e.
how generic
(2:33:03 PM) rfeng: ok
(2:33:20 PM) jboynes: e.g. SDO and JAXB can both be classified as "data
binding type systems"
(2:33:26 PM) rfeng: yes
(2:34:04 PM) jboynes: so with databinding as part of the runtime, adding a
type system would seem reasonable
(2:34:13 PM) rfeng: ok
(2:35:34 PM) rfeng: In the post, I'm trying to generalize the extensibility
requirement assuming some other vendors may have their own SCDL extensions.
(2:36:00 PM) jboynes: well, yes and no
(2:36:10 PM) jboynes: we don't have to understand their extensins
(2:36:28 PM) jboynes: (unless we choose to or they give us the code)
(2:36:44 PM) rfeng: true, but their extension should be able to plug in to
deal with it
(2:37:02 PM) jboynes: yes
(2:37:17 PM) jboynes: and we can do that
(2:37:37 PM) jboynes: then it becomes what happens to the configuration data
thus created
(2:37:44 PM) rfeng: not for builders at this moment, right? we accept
loaders by element qname
(2:38:19 PM) jboynes: and certain types of builders
(2:38:25 PM) rfeng: yes
(2:38:34 PM) jboynes: keyed on implementation and binding
(2:38:39 PM) rfeng: now we have a fixed set of builders
(2:38:49 PM) rfeng: fixed type of builders
(2:38:54 PM) jboynes: yes
(2:39:11 PM) jboynes: we could generalize that
(2:39:23 PM) jboynes: we probably should
(2:39:32 PM) rfeng: that's basically my post was asking for
(2:40:38 PM) jboynes: the problem is how to dispatch to them - what to key
off
(2:41:14 PM) rfeng: right, maybe based on the ModelObject class returned
from the load phase?
(2:41:49 PM) jboynes: the problem we had was that component builders
dispatch based on implementation tyoe
(2:42:04 PM) jboynes: we could do a two step delegation there
(2:42:22 PM) rfeng: yes
(2:42:32 PM) jboynes: delegate to a generic Component builder for
ComponentDefinition.class
(2:42:51 PM) jboynes: and then have it delegate based on the class of the
Implementation
(2:43:00 PM) rfeng: yes
(2:43:16 PM) jboynes: that would be similar to how we handle componentType
loading
(2:43:22 PM) rfeng: sounds reasonable and flexible
(2:43:29 PM) jboynes: we can do the same for services and references
(2:43:36 PM) jboynes: a generic service/reference builder
(2:43:39 PM) rfeng: y
(2:43:51 PM) jboynes: that then delegates based on the bindings
(2:44:20 PM) jboynes: fixing the problem we have right now where a
service/reference can only have one binding
(2:44:46 PM) jboynes: sounds good
(2:44:51 PM) rfeng: by nature, it's two levels of delegation
(2:45:08 PM) jboynes: I'm up to my ears in classloaders - is this something
you want to add?
(2:45:38 PM) rfeng: sure, I can do that. I'll summarize the chat and post to
the dev list 1st
(2:45:56 PM) jboynes: thanks
(2:46:05 PM) rfeng: thank you and ttyl
(2:46:12 PM) jboynes: I need to eat something (breakfast at 2:45 again :( )
----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 15, 2006 3:20 PM
Subject: Re: How to build SCDL model extensions?
Hi,
Here's an example I'm from.
1) I use "import.sdo" to configure the SDO type system for a composite.
The SDOImportLoader is added to deal with this SCDL extensibility element.
During "load" phase, it will populate a SDO TypeHelper instance.
2) For references or services with web service bindings in the same
composite, the Axis2 binding extension (or ideally DataBinding
interceptor) has to deal with SDO/AXIOM data transformation. The
transformer needs to access the corresponding TypeHelper instance (runtime
context contributed from the "import.sdo") for the composite.
So the bottom line is that I need to make some extra context (in addtion
to the base SCDL artifacts) available from the deploy phase to the runtime
in a flexible and extensible way so that the target invokers can leverage
these context to drive its invocations.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 15, 2006 10:41 AM
Subject: Re: How to build SCDL model extensions?
On Aug 15, 2006, at 10:24 AM, Raymond Feng wrote:
I don't think we're mixing the model and runtime here.
"MyExtensionDefinition" is the model object, which is the result of the
"load". Now I need to access the corresponding runtime metatdata
"MyExtension" which is supposed to be built from
"MyExtensionDefinition".
Can we step back and look at the use case we are trying to satisfy?
Runtime "metadata" sounds like the "model" to me. Perhaps what you need
is an ObjectFactory which handles this? That's how we handle other
extensions.
The reason I'm asking for this kind of extensibility is that not all
the extensions can be resolved at "load" time. For example, I may need
to resolve the "databinding.sdo" against an "import.sdo".
Can you elaborate?
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 15, 2006 10:12 AM
Subject: Re: How to build SCDL model extensions?
On Aug 15, 2006, at 9:58 AM, Raymond Feng wrote:
As defined by the SCA spec, we are allowed to add extensions to the
SCDL model, for example, we can add "myExtension" to a "composite"
as illustrated below.
<composite ...>
<ns1:myExtension xmlns:ns1="http://my.extension/";>
...
</ns1:myExtension>
</composite>
With the current extensibility story, I can register a loader to
load the "myExtension" XML stanza to creat "MyExtensionDefinition"
model object. Is the CompositeLoader supposed to add the
"MyExtensionDefinition" instance returned from my loader to its
extension map using ModelObject.getExtensions().put(...,
myExtensionDefinition) if it doesn't belong to the base SCDL model?
Assuming the answer is yes, then I would like to register a builder
to create the runtime metadata out of the MyExtensionDefinition
(AFAIK, this extensibility doesn't exist today) and attach it to the
owning SCAObject (unfortunately, SCAObject interface doesn't have
the extensions).
Why would this go on the runtime artifact as it sounds like we are
mixing runtime with model? Wouldn't it be better to handle this in
the model loading?
Does this requirement make sense? It comes out as I investigate the
"import.sdo" story.
Thanks,
Raymond
---------------------------------------------------------------------
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]
