On 8/29/06, Oisin Hurley <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
