tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
Subject Re: Porting Tuscany C++ to C++11 and some code cleanup
Date Thu, 17 Jan 2013 07:41:08 GMT
On Mon, Jan 14, 2013 at 1:03 PM, Thomas Gentsch <tg@e-tge.de> 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 <tg@e-tge.de> wrote:


> >
> >         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,)
> :-)
> > 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.
> But then the wrapper and proxy must exist - either hand-written or
> WSDL-generated.


> 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
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++

... 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.


> > 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.
> True, but the real power of open-source is if the "community" jointly
> 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

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.


> > 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
> > mechanism.)
> Maybe here I'm in the SDO world again ... :-) All the schema/type stuff
> is nicely integrated and I don't need to directly deal with libxml2 or
> so ...
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.

- Jean-Sebastien

View raw message