incubator-nuvem-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: SCA contribution/composite
Date Mon, 13 Jun 2011 07:01:10 GMT
On Sun, Jun 5, 2011 at 4:21 AM, john pradeep <yehohanan7@gmail.com> wrote:
> Hi Jean,
> *
> *
> *IIRC contributions don't have a namespace.*
>
>       I didnt try out this yet, but I figured out that sca contributions
> have an option to export namespaces :
>       <export namespace="http://nuvemstandalone" />

Right, contributions do not have a namespace, but they can export the
namespaces of the XML artifacts they contain, like SCA composites,
WSDLs, XSDs etc. Then other contributions can import these namespaces
to allow their XML artifacts to reference them.

> *I'm not sure how to reuse feature composites, as you'll need to configure
> their components for specific apps, hosts, ip addresses, user ids etc.*
>
>      I was actually looking into these options to see if we can avoid nuvem
> client's to directly wire every components by referring
>      to  implementation classes directly, instead thought it will be good
> to just allow the client to refer to just few components with
>      their component names.
>
>      I am trying to find out if there is a way in tuscany which will allow
> nuvem clients to define few global properties before importing
>      the contributions? if yes then I think we can resolve those values
> before injecting the properties into the nuvem components.
>
>      Any Idea if tuscany has such features in place?


I'm not sure if Tuscany has any side configuration properties on top
of the SCA SCDL configuration language, but you may want to compare
the complexity and usefulness of the following:

Option (a) standard SCA component implementation reuse

What's reused is not a component, it's a component implementation.

An app developer reuses foo.Bar.java, configures component Bar123 from
it. To understand how to configure Bar he needs to learn SCA, look at
an example BarExample component and foo.Bar.java, or some
documentation that describes what can be configured from it, and the
component interface.

Option (b) service endpoint reuse

A component Bar is deployed at http://foo.com/bar, provides a service
at that particular endpoint address. The app developer invokes that
service. To understand how to use it he needs to learn its interface
and a description of the rendered service.

Option (c) SCA component reuse + some side configuration properties to
configure that adjust that component's behavior?

An app developer reuses component Bar. To understand how to reuse Bar
he needs to learn SCA, look at the Bar component declaration, its
implementation foo.Bar.java, or some documentation that describes how
Bar configures it, the component interface, and now also learn how to
use these new properties that are used as a second configuration layer
for foo.Bar.

For (c), chances are that you're going to have to define new side
configuration properties for bindings, policies, wiring etc. Once
you've done that you've basically defined a new configuration
language, equivalent to SCA, on top of SCA, and you can ask the
question: Why do I now have 3 levels of indirection to tell my
component implementation what to do? :)

Anyway, this is all just theory. My guess is that you should be OK
with options (a) and (b), but a concrete example would probably help
better explore how to reuse component implementations vs services vs
component configurations.

>
> Thanks,
> John
>
>
> On Sun, Jun 5, 2011 at 8:29 AM, Jean-Sebastien Delfino
> <jsdelfino@gmail.com>wrote:
>
>> Hi John,
>>
>> Your proposal looks good to me, with a few comments:
>>
>> IIRC contributions don't have a namespace.
>>
>> I'm not sure how to reuse feature composites, as you'll need to configure
>> their components for specific apps, hosts, ip addresses, user ids etc.
>>
>> They're useful though, as examples, templates or palettes that the
>> developer can review before creating his own. But then their namespaces
>> don't matter.
>>
>> Thoughts?
>> --
>> Jean-Sebastien
>>
>> Sent from my iPhone
>>
>> On May 31, 2011, at 3:31 PM, john pradeep <yehohanan7@gmail.com> wrote:
>>
>> > Hi,
>> > I am trying to organize the composite and contribution files for all
>> modules
>> > and thought of the below approach.
>> >
>> > 1. Each SCA contribution corresponding to a cloud platform will have a
>> > specific namespace
>> >    *Example:* <contribution xmlns="
>> > http://docs.oasis-open.org/ns/opencsa/sca/200912"
>> > xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
>> > xmlns:xmpp="*http://nuvemstandalone*">
>> >
>> > 2. we will have a composite for each feature with the same namespace as
>> it
>> > is defined in its sca contribution but the name of the composite itself
>> will
>> > indicate the feature
>> >   * Example:*<composite xmlns="
>> > http://docs.oasis-open.org/ns/opencsa/sca/200912"
>> > xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
>> > *targetNamespace="http://nuvemstandalone" name="xmpp"*>
>> >
>> > 4. The component/service names within the composites will be Identified
>> with
>> > the same names across all SCA contributions to keep it consistent.
>> >
>> > 5. Since the component names are maintained same across all platforms,
>> the
>> > client will always refer to the same component/service name but  will
>> import
>> > the right namespace to choose the contribution (google, standalone etc)
>> >
>> > I haven't tried to import a composite just by its name space in tuscany
>> yet,
>> > but i assume it should be possible?
>> >
>> > Please let me know your thoughts.
>> >
>> >
>> > Regards,
>> > John
>>
>



-- 
Jean-Sebastien

Mime
View raw message