tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws" <simonsl...@googlemail.com>
Subject Re: [C++] Requirements for a pluggable C++ Tuscany implementation
Date Fri, 01 Sep 2006 08:05:29 GMT
On 8/29/06, Oisin Hurley <ohurley@iona.com> wrote:
>
> Simon - apologies I've been away from this for the last week...
>
> [deletia]
> >> ...and this is why :)  There are number of responsibilities of an
> >> extension - which you accurately describe - and there are a number
> >> of responsibilities of a plugin, related to configuration and
> >> lifecycle
> >> and I think it would be a Good Thing to keep them as separate
> >> development
> >> efforts. What do you think?
> >
> > Do you mean that a plugin may have responsibilities that are a sub-
> > set or
> > super-set of those of a particular extension?
>
> Actually I see that the plugins responsibilities are a disjoint set -
> meaning that the plugins are unconscious of the value of their content
> and are used only as a way to bang a bunch of libraries together in
> a predictable manner and correctly initialize/deinitialize them.



Ah, OK, I see. I was getting a little confused  because Pete has being
doing  work on  refactoring the C++ implementation to separate core function
from extensions from bindings. I had assumed (wrongly in the first instance)
some overlap between that activity and this conversation. What you are
advocating a more wide ranging approach review of C++ SCA deployment.

> We could probably have the same conversation re. deploying
> > components and
> > composites into the C++ SCA infrastructure as opposed to deploying
> > parts of
> > the C++ SCA infrastructure.
>
> +1
>
> > Maybe we need to be a bit more explicit about what we anticipate
> > being in a
> > plugin. For examle,
> >
> > 0..n Component type container implementations
> > 0..n Binding implementations
> > 0..n Host adapters
> > [0..n Components
> > 0..n Composite(s) should these be included as well? Seems unlikely
> > that you
> > want to deply at the same time but you will want to deploy at some
> > time.]
>
> So there's two roads - one where one must be explicit about the content
> of the plugin in terms of architectural artifacts, this is the manifest
> style approach, and the other, where the plugin initialization code does
> the necessary registrations of architectural artifacts. These are not
> necessarily incompatible approaches either.



OK, from above, with this list I was trying elicit that you thought a plugin
was rather than necessarily manadate a plugin. Having said that, in the
context of SCA we can expect a finite set of things in plugins, assuming
that a component implementation is just classed as a component,  and the
list above still stands I think. What you are saying is that you envisage a
deployment approach where the plugin may have one or more of these types of
things as required to add some funtion or application to the runtime.

> Can we use exsiting technology for some of this, for example, there
> > has been
> > much discussion of OSGi on the java list, is OSGi wider that just
> > Java now?
>
> AFAIK OSGi is still Java only and a Google search didn't turn up much
> that
> was useful. In terms of existing technology, I'm not familiar with any
> technologies along this line that are open. That being said, a C++
> version
> of OSGi would be a beautiful thing :)


Your right, Google doesn't turn up anything. I'm sure I read some mail on a
mail list about it but there you go I must be dreaming.


My gut feeling is that plugin/extension should be decoupled, but the
> only
> strong point I can see for it in the current architecture is the fact
> that
> databindings are not explicit as an extension - there is scope for
> say an
> interface.mumble that has databindings of say XMLBeans or JiBX. If the
> databinding can be an extension in its own right, then maybe the
> simplifying
> assumption of plugin == extension may be the way to go. From the
> point of
> view of deployment, there may be a greater need for a non-extension
> plugin
> to package application code to be 'deployed'. Maybe we should have that
> conversation about deployment now?
>
>   cheers
>    --oh


Sebastien has used Pete's extension framewok to refactor the bindings. It's
a good question you raise though about data bindings. The only options
currently are SDO and native and assumtions are made depending on what
interfaces/bindings you choose. More though required in the future!

I can see it being useful to packagage individual extensions or groups of
extensions for the runtime to consume.  It's also to the case that we will
want to package applications. Current when I build C++ SCA I get a deploy
stucture that holds the SCA core and extensions framwork

deploy
   bin
   extensions
     cpp
       bin
       include
       lib
       xsd
     ws
       reference
         bin
         lib
       service
         bin
         lib
       xsd
   include
   lib
   xsd

And when I build a sample, BigBank for example, I get a separate deploy dir

deploy
   bin
   configuration
     Composite Name
        top level.composite
   packages
     Composite Name
        everything required for the composite

Now I should be able to zip this deploy up and move it to another runtime
instance and assuming I have $TUSCANY_SCA/SDOCPP set up it should run OK.
However this all depends on the hosting environment. The ease of use of
"plugin" deployment really depends on getting the hosting framework right.
Currently with web service bindings I have to configure Axis manually by
copying some files around. It would be nice to have a binding specific
hosting approach, for example, in the case of Axis bindings we could create
a separate part of the deployment that represents the service as axis would
see it. Anyhow, I don;t feel close enough to it yet to make specific
suggestions. I'm starting to play with BigBank again so maybe we can keep
the plugin/deployment thread alive as we learn more about it.

Regards

Simon


---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message