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 2007/05/22 19:33:45 UTC
Updated document: Extending Tuscany
Hi,
I have updated the "Extending Tuscany" document with the latest SPIs and
added the "Add databinding" section. Please review and comment.
http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Updated document: Extending Tuscany
Posted by Raymond Feng <en...@gmail.com>.
Hi, Simon.
I would appreciate if you can update the document directly. The document is
on the wiki but it's still in the PPT format. I was trying to convert it to
a wiki page but gave up due to the time constraint as I had to adjust the
formattings all by hand. Maybe we can try to see if there's utility
available to take care of the conversion.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <si...@googlemail.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, May 29, 2007 3:31 AM
Subject: Re: Updated document: Extending Tuscany
> Hi Raymond
>
> I've just been bringing up the binding-jms module so I took the
> opportunity
> to review your guide. Thanks for writing all this stuff down! I haven't
> gone
> through the databinding slides yet but I thought I would post what I had.
> I
> recorded comments (see below) as I went through it. I'm more than happy
> to
> help with new new/adjusted content if you like. Maybe we can move this
> guide
> onto the wiki to make it easier to access?
>
> Regards
>
> Simon
>
> ===============
>
>
> Slide 3.
>
> Do you mean the SCA Assembly Model as defined in the specification? We
> could
> add a reference to the spec to make this clear. If not what does this
> mean?
>
> Slide 4.
>
> Need to be clearer when stating "Tuscany core and extension modules can
> also
> define extension points where extensions can be added". Would be good to
> have some context before this slide. I.e. What is the structure of the
> extension mechanism, can we have an example of the kind of extensions that
> would be loaded for a running application and how they might be related.
> When might I want to
>
> - Plug and extension directly into the Tuscany runtime
> - Extend an extension point defined by the "Tuscany Core and extension
> modules" as this slide seems to imply I can
> - Provide a new extension point
>
> Slide 5.
>
> Under what circumstances do I need to contribute and extension point using
> the getExtensionPoints() method?
> Define "interested extension points".
> How might I link extension points that have a dependency on on another?
> How do I choose whether to unregister my extension during stop()?
>
> Slide 6.
>
> "The same instance will be used to invoke all the methods during different
> phases of the module activation." What methods am I expected to invoke
> using
> the single instance I have? Or does this mean that all startup methods
> will
> be invoked on a single instance of the Activiator class.
>
> Under what circumstances would I have more than one class in the
> META-INF/services/org.apache.tuscany.core.ModuleActivator file?
>
> Slide 7.
>
> Seems to be the same as slide 4 but with a different title.
>
> This slide has started using the term "Providers". I assume that it will
> define what a provider is and how if differs from the, presumably wider,
> extension term.
>
> Slide 8.
>
> Does "It's contracted by the SPI
> org.apache.tuscany.sca.provider.ImplementationProvider " mean that it
> simply
> implements the interface
> org.apache.tuscany.sca.provider.ImplementationProvider or is there some
> more
> involved "contracting"(?) protocol that I must observe.
>
> In what circumstances should it react to Start/Stop
>
> Slide 9.
>
> Same "contracted" point as slide 8.
> Same start/stop point as slide 8.
>
>
> Slide 10.
>
> Same "contracted" point as slide 8.
> What does "promoted component" mean in this context?
>
> Slide 11.
>
> Nice picture. Gives a really good overview. Could do with more like this.
>
> Slide 12.
>
> Slide 13.
>
> Slide 14.
>
> This slides starts using the implementation.crud extension as a sample.
> Would be good to have a slide describing what the intention of the
> implementation.crud extension to give people a bit of a lead in.
>
> Explain why no XML schema is required by the runtime.
>
> Slide 15.
>
> Last point. "provides" -> "provide"?
>
> Slide 16.
>
> How is the logical model associated with the Implementation Provider?
>
> Slide 17.
>
> Is start/stop called every time a component of the implementation type is
> started?
>
> Slide 18.
>
> There is a hidden level of infrastructure in the runtime. Ie.
>
> ExtensionPointRegistry
> StaxArtifactProcessorExtensionPoint
> ProviderFactoryExtenionPoint
> ...
>
> What is the complete list of these things that should be available ?
> What do they all do?
> Which ones do I need to register with and in what circumstances?
> What happens are run time with these registrations?
>
> Slide 19.
>
> Slide 20.
>
> Slide 21
>
> point 5. describe "respective extension points"
> point 6. what does contribute mean here? Check it in somewhere or put it
> on
> the classpath?
>
> Slide 22.
>
> Slide 23.
>
> EchoBindingImpl must also implement methods from the SPI interfaces it
> inherits via the
> base binding interface
>
> public String getURI()
> public void setURI(String uri)
> public String getName()
> public void setName(String name)
> public List<Intent> getRequiredIntents()
> public boolean isUnresolved()
> public void setUnresolved(boolean unresolved)
> public List<PolicySet> getPolicySets()
> public List<Object> getExtensions()
>
> Also requires properties to support these as appropriate.
>
> EchoBindingProcessor may also have to deal with other information such as
> Policy sets and intents
>
>
> Slide 24.
>
> It talks about Invokers rather than interceptors. I think this is out of
> date.
>
> Slide 25.
>
> Get the interface contract imposed by the binding protocol layer. Isn't it
> the interface imposed by the service?
>
> Slide 26.
>
>
> Slide 27.
>
> This looks quite complicated and could benefit from hand layout. Or even
> use
> a context diagram to show how the pieces relate.
>
>
>
> Haven't gone through the databinding slides yet.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Updated document: Extending Tuscany
Posted by Simon Laws <si...@googlemail.com>.
Hi Raymond
I've just been bringing up the binding-jms module so I took the opportunity
to review your guide. Thanks for writing all this stuff down! I haven't gone
through the databinding slides yet but I thought I would post what I had. I
recorded comments (see below) as I went through it. I'm more than happy to
help with new new/adjusted content if you like. Maybe we can move this guide
onto the wiki to make it easier to access?
Regards
Simon
===============
Slide 3.
Do you mean the SCA Assembly Model as defined in the specification? We could
add a reference to the spec to make this clear. If not what does this mean?
Slide 4.
Need to be clearer when stating "Tuscany core and extension modules can also
define extension points where extensions can be added". Would be good to
have some context before this slide. I.e. What is the structure of the
extension mechanism, can we have an example of the kind of extensions that
would be loaded for a running application and how they might be related.
When might I want to
- Plug and extension directly into the Tuscany runtime
- Extend an extension point defined by the "Tuscany Core and extension
modules" as this slide seems to imply I can
- Provide a new extension point
Slide 5.
Under what circumstances do I need to contribute and extension point using
the getExtensionPoints() method?
Define "interested extension points".
How might I link extension points that have a dependency on on another?
How do I choose whether to unregister my extension during stop()?
Slide 6.
"The same instance will be used to invoke all the methods during different
phases of the module activation." What methods am I expected to invoke using
the single instance I have? Or does this mean that all startup methods will
be invoked on a single instance of the Activiator class.
Under what circumstances would I have more than one class in the
META-INF/services/org.apache.tuscany.core.ModuleActivator file?
Slide 7.
Seems to be the same as slide 4 but with a different title.
This slide has started using the term "Providers". I assume that it will
define what a provider is and how if differs from the, presumably wider,
extension term.
Slide 8.
Does "It's contracted by the SPI
org.apache.tuscany.sca.provider.ImplementationProvider " mean that it simply
implements the interface
org.apache.tuscany.sca.provider.ImplementationProvider or is there some more
involved "contracting"(?) protocol that I must observe.
In what circumstances should it react to Start/Stop
Slide 9.
Same "contracted" point as slide 8.
Same start/stop point as slide 8.
Slide 10.
Same "contracted" point as slide 8.
What does "promoted component" mean in this context?
Slide 11.
Nice picture. Gives a really good overview. Could do with more like this.
Slide 12.
Slide 13.
Slide 14.
This slides starts using the implementation.crud extension as a sample.
Would be good to have a slide describing what the intention of the
implementation.crud extension to give people a bit of a lead in.
Explain why no XML schema is required by the runtime.
Slide 15.
Last point. "provides" -> "provide"?
Slide 16.
How is the logical model associated with the Implementation Provider?
Slide 17.
Is start/stop called every time a component of the implementation type is
started?
Slide 18.
There is a hidden level of infrastructure in the runtime. Ie.
ExtensionPointRegistry
StaxArtifactProcessorExtensionPoint
ProviderFactoryExtenionPoint
...
What is the complete list of these things that should be available ?
What do they all do?
Which ones do I need to register with and in what circumstances?
What happens are run time with these registrations?
Slide 19.
Slide 20.
Slide 21
point 5. describe "respective extension points"
point 6. what does contribute mean here? Check it in somewhere or put it on
the classpath?
Slide 22.
Slide 23.
EchoBindingImpl must also implement methods from the SPI interfaces it
inherits via the
base binding interface
public String getURI()
public void setURI(String uri)
public String getName()
public void setName(String name)
public List<Intent> getRequiredIntents()
public boolean isUnresolved()
public void setUnresolved(boolean unresolved)
public List<PolicySet> getPolicySets()
public List<Object> getExtensions()
Also requires properties to support these as appropriate.
EchoBindingProcessor may also have to deal with other information such as
Policy sets and intents
Slide 24.
It talks about Invokers rather than interceptors. I think this is out of
date.
Slide 25.
Get the interface contract imposed by the binding protocol layer. Isn't it
the interface imposed by the service?
Slide 26.
Slide 27.
This looks quite complicated and could benefit from hand layout. Or even use
a context diagram to show how the pieces relate.
Haven't gone through the databinding slides yet.