On Mon, Jan 14, 2013 at 1:03 PM, Thomas Gentsch <firstname.lastname@example.org> wrote:
On Sun, 2013-01-13 at 23:35 -0800, Jean-Sebastien Delfino wrote:
> On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <email@example.com
> Q: Is there some kind of request routing?:-)
> A: Local calls are resolved during OS-loader-time. One
> component calling
> another is written as regular C++ code which results in
> compiled code as
> unresolved reference that must be satisfied during runtime by
> the target
> component which in turn must be loaded as shared library
> No, if I remember correctly (as M3 was a long time ago,)
But then the wrapper and proxy must exist - either hand-written or
> wires were resolved by Composite::resolveWires, then invocation of a
> component involved CPPServiceWrapper::getServiceWrapper to load the
> component library, lookup a factory function named after the service
> name, create an instance of CPPServiceWrapper, and eventually
> executing generated code in CPPServiceWrapper::invokeService to
> dispatch the call to the target C++ component method.
The CppCalculator example though has neither. I did not
verify all the others, most have WSDL as it seems.
Maybe as long everything happens within *one* lib ... ?
Proxies and wrappers are generated at build time. That's why you can't find them in the source tree, as we usually don't commit generated build outputs to the Apache source repository.
Actually I was thinking that its even not a bad idea to let the OS
loader (or even the linker) resolve the calls as it is probably the
fastest way possible.
That could be challenging in the following configurations:
a) several components, say C1 and C2, implementing the same service WSDL interface 'I' + operation 'o' (as the linker wouldn't know which one to pick);
b) dynamic wiring decided by a component's implementation logic (as the linking would happen too early);
c) a composition of components written in different languages, in particular scripting languages (as linking would only apply to C and C++ components).
... but that's still an interesting idea to explore. I've not thought too much about it, but you may be able to come up with a generation scheme addressing some of these challenges.
True, but the real power of open-source is if the "community" jointly
> I've worked on C++ M3, trunk and even the Java project so I can
> imagine why someone would prefer one or the other. The good thing is
> that they're here in the open and you can do what you want with the
> code, use the bits you prefer, mix them, or even contribute to
> maintain or change them to something you like, if you're interested.
works on the same thing. Of course I cannot force anybody :-)
Also, I quite like the idea of following a standard (if it is any good,
which I cannot really tell yet).
So, in theory, I could start a project, let's say "sca-oasis", based on
M3 ... originally I'd be the only one working on it, maybe others join,
maybe not. Would that then still be "Apache Tuscany"?
For it to be 'Apache Tuscany' you'd have to discuss and contribute your ideas to the Apache Tuscany community here in the open -- which you are doing right now :) -- and contribute code changes or additions to the Apache Tuscany project repository. If you're interested, you can start with patches in JIRA issues (which allow you to grant license to Apache for your contributions) and at some point the community can even give you committership.
We should discuss what you have in mind on this list (I'd suggest a different thread as this one is getting long) but for example 'adding support for the OASIS SCA assembly spec to the M3 code', 'integrating some of the M3 code and trunk', 'adding a code generator to trunk (the one from M3 or another)' or any other ideas you have, would all be valid ideas to discuss and evolve the project IMO.
>Maybe here I'm in the SDO world again ... :-) All the schema/type stuff
> I'm not sure if you're talking about validating the data exchanged
> with SCA components (which could be done with a validating proxy) or
> about generating static code from schema type definitions, but both
> approaches should work nicely along M3 or trunk (for the latter you'd
> need a generator like scagen on top of the runtime invocation
is nicely integrated and I don't need to directly deal with libxml2 or
If you like SDO, that could be an area where you could contribute too. For example (just thinking out loud) you could try to get SDO to work with JSON, as JSON is getting so much traction these days, or (going back to your code generation idea), first make sure that SDO still works with modern C++ compilers and the latest Libxml2 parser, re-activate its build etc, then generate C++ SCA component skeletons that use SDOs.