ant elder wrote:
On 3/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
<snip/>
One reason the SPI module is so large is that it does define many the
interfaces for the components in you diagram. I think there is room
for a reorganization there to clarify the usage of those interfaces.
I would propose we start with that ...
There have been several emails now which I think show some agreement
that we
can do some SPI refactoring. Here's something that could be a start of
this
work:
One area is the extension SPI, on our architecture diagram [1] thats the
"Extensions" box at the top right. In the past we've had a lot of
problems
with extensions continually getting broken as the SPIs keep changing.
This
has made maintaining extensions to be in a working state a big job and it
has led to some donated extension just being abandoned.
One of the reasons for this is that the SPIs more reflect the
requirements
of the Tuscany runtime than the requirements of the extension being
contributed. For example, a container extension needs to enable creating,
initializing, invoking and destroying a component, along with exposing
the
components services, references and properties. Those things have
remained
pretty constant even though the SCA specs and Tuscany runtime and SPI
have
undergone significant changes.
I think we should be able to create SPIs for these type of functions
which
clearly represent the requirements of a particular extension type, and
that
doing this would go along way to making things more stable. All this
code is
there in the current SPI so its mainly just a mater of refactoring
parts out
into separate bits with clearly defined function and adding adapter
code so
the runtime can use them.
You can even envisage that if this is successful it could define a
runtime
extension SPI for all the extensible areas of SCA assembly which could
eventually be standardized to provide portable SCA extensions in a way
similar to JBI.
What do people think, is this worth looking at? If so I'd like to make an
attempt at doing it for bindings and components using the Axis2
binding and
script container as guinea pigs. This should be pretty transparent to the
rest of the kernel as other than the adapter code it could all be
separate
modules.
I think it's a very good idea. It may be interesting to try this as well
with simpler component implementation and binding extensions, this could
be an echo-binding that just echoes what it's passed, or a crud
component implementation extension that just implements fixed
create/retireve/update/delete methods for example. It would help
illustrate the extension development model without the complexity of the
Web service or script handling getting in the way. We probably need both
to help refine the SPIs, real axis2 and script extensions and simpler
ones that show the minimum required to develop an extension. I'll happy
to help with this SPI work.
Comments?
...ant
[1]
http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
