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
