Thanks for bringing this up Andy. I think there are a few separate topics in
this note and they probably need their own thread for discussion but this is
a good starting point.
I certainly would like to restructure the code and src tree structure a
little and this is a great time to do it having just released the M1 and as
we are starting to implement the 0.95 spec model. The existing code is still
based around what I would call a prototype implementation.
I'll come back with some more comments/detail on what you have below. We may
also like to think about build and test while we are at it and what src tree
layout would help us to build e.g. core or model separately and unit
test them.
Cheers,
On 09/08/06, Andrew Borley [EMAIL PROTECTED] wrote:
Hi All,
As well as the assembly model changes (for the 0.95 spec) that Sebastien
is
heroically getting though at the moment, would it be worth starting to
think
about restructuring the SCACPP codebase? It strikes me that we need to
make
Tuscany more modular than it currently is, to help with understandibility
and maintainability, and we also need to be thinking about the
extensibility
story (which itself instructs how we need to modularize things).
There are lots of areas where we should bring in the ability for users and
developers to extend SCACPP:
Service Extensions (aka Entrypoints in old-speak)
The current service binding (WS/Axis2C) essentially acts like a local
client, bootstrapping the runtime, finding the service and invoking the
appropriate operation - will all service extensions want to act in this
way?
In this case, Axis is calling Tuscany, so we configure Axis to be able to
find Tuscany but not the other way round - will other service extensions
need Tuscany to call back into the service extension? If so, do we want to
do this dynamically or via compile-time linking?
Reference Extensions (aka External Services in old-speak)
Reference extensions will need to be dynamically found and invoked, so
we
will probably need some kind of Tuscany runtime configuration side file
that
points at the library ( perhaps has some configuration parameters, etc).
We
could statically link, but then we would be forcing extension authors to
recompile the whole of SCACPP.
Component Language Extensions
I put some info up about this on the wiki, but rereading it after my
holiday and it's a tad unclear! Do we want to call components in other
languages via proxy code generated with SCAGEN? Will we want to generate
wrapper code in the other language, so that calling a component reference
works like a normal language call? Can we avoid the SCAGEN development
step?
How will we map data types from C++ to the language and back again?
Assembly Model Extensions
We need to allow people to add their own binding.xxx element (or
implementation.xxx, etc) to the sca.module (now sca.composite) file and
have
Tuscany use the extension when it reads it.
Data Binding Extensions
Allow other types of data to be passed between components and between
composites. I think at the moment we only allow C++ primitives and SDO
data
objects.
We will need to define SPIs for each of these areas - for Service and
Reference extensions we can probably base it on the WS entrypoint and
external service support in the current codebase, but the others will need
more thinking about.
I've veered off into extensibility here, without talking much about
restructuring - does anyone have any good ideas about where things should
go
or how to make the code more modular?
Cheers
Andy
--
Pete
