You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2012/12/06 10:04:09 UTC
Re: Porting Tuscany C++ to C++11 and some code cleanup
On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> OK, many thx for this info!
>
> Regarding SDO - yes, I noticed that there was not a lot of activity
> during the last years.
> Hello out there: Is there anybody else still using this?
>
> Rgd SDO as SCA-internal data-flow mechanism - what is being used now?
> I know about libxml2 (actually its being used in SCA/SDO :-), nothing
> yet about JSON, will read.
>
Hi Thomas,
Here's a short overview of what's used now.
Data read/write functions are provided for XML (using Libxml2 [1]), JSON
(using Mozilla SpiderMonkey but I've started to migrate to Jansson [2]),
and Lisp/Scheme S-expressions [3].
Here's how to read XML in a C++ component:
<customer
age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>(415)765-4321</phone></customer>
// A list of strings containing the above XML doc, obtained from an input
stream for example
const list<string> ls = ...;
// Read the XML doc (the failable<...> result type helps encapsulate error
handling)
// See below for a description of the 'value' data type
const failable<value> fe = xml::readElements(ls);
// Assuming no failure, get and print the result
const value e = content(fe);
cout << e << endl;
The result is a list like follows (using the S-expression syntax here for
conciseness: element, customer, attribute, age are symbols, 21 is a number,
"johndoe" is a string, (x y) is a list of x, y):
((element customer (attribute age "21") (element name "johndoe") (element
phone "(650)123-4567") (element phone "(415)765-4321")))
The runtime is schema-less. You do not need an XML schema to read/write any
XML.
If you don't care about the XML element vs attribute representation you can
strip it like this:
const value v = elementsToValues(e);
to get this:
((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
"(415)765-4321"))))
Note the @age attribute name, which follows the Badgerfish [4] convention
often used to name XML attributes in JSON documents for example.
The same data can be constructed and represented in the various programming
languages supported by the runtime, as follows:
C++:
list<value>(list<value>("customer", list<value>("@age", 21),
list<value>("name", string("johndoe")), list<value>("phone",
list<value>("(650)123-4567", "(415)765-4321"))));
using the following C++ types:
- string, similar to std::string but lighter and faster for small strings,
with builtin conversions from/to native char*;
- list<T>, a lightweight list/lazy-list type with useful Lisp/Scheme-like
[5] functions incl. cons, car, cdr, map, filter, reduce, assoc, etc;
- lambda<R(P...)>, a function type similar to std::function but lighter and
faster;
- value, a dynamic value type (type can be number, boolean, symbol, string,
list<value>, lambda<value(list<value>)>, value*) with builtin conversions
from/to native double, bool, char*, C++ lambdas and pointers.
Python:
((customer, ("'@age" 21), ("'name", "johndoe") (phone, ("(650)123-4567"
"(415)765-4321"))),)
using Python tuples [6] and native Python data types for strings, numbers
and booleans.
JavaScript / JSON:
{"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
using JSON arrays and native Javascript types.
Scheme:
((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
"(415)765-4321"))))
just an S-expression.
Java (there's experimental support for running Java components on the C++
runtime):
list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
list("'phone", list("(650)123-4567", "(415)765-4321"))));
using java.lang.Iterable [7] for lists and native Java data types for
strings, numbers and booleans (the list(...) function is a static 'builder'
function returning a java.lang.Iterable<?>.)
To summarize: fast and schemaless support for XML, JSON and S-expressions,
with lightweight representation using lists and simple types in the
supported programming languages.
Hope that helps.
[1] http://www.xmlsoft.org
[2] http://www.digip.org/jansson/
[3] http://en.wikipedia.org/wiki/S-expression
[4] http://badgerfish.ning.com
[5]
http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
[6]
http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
[7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
- Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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.
Yes
> 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.
...
>
> > 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).
>
>
+1
> 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.
...
>
> > 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
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
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:
>
> Hello JS,
>
>
>
> Hi Thomas, Happy New Year!
Many thx! Same back!!
> now, I did some more reading etc and believe now that I mostly
> understand what's going on :-)
>
> The main missing pieces were these (correct? Possibly my
> terminology is
> a bit fuzzy :-):
> Q: When are SDOs used (in SCA M3) and when not?
> A: If an interface of a service uses complex types as in/out
> params or
> return value, otherwise simple types (like int, bool, string)
> are used.
> Complex types (i.e. class instances) an XSD are passed in/out
> as SDO
>
>
>
> Yes
>
> 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 ... ?
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.
But, OK, will look again :-)
> In trunk, the equivalent of invokeService is the apply function, and
> currently needs to be written by hand as scagen has not been
> maintained (but could be brought back if somebody was interested in
> maintaining it).
>
> Q: What is the purpose of composite files with pure C++
> modules?
> A: If a composite consists only of local components all calls
> are
> resolved by the OS loader. In that case basically the
> composite
> definition file mainly states which interfaces are in which
> shared lib
> and in which order are the libs to be loaded.
>
>
>
> See above, both M3 and trunk resolve wiring dynamically.
>
> Q: How are remote request handled?
> A: Remote interfaces are described using WSDL, which must be
> processed
> using the tool scagen to generate a "ServiceWrapper" and a
> "ServiceProxy" that act as client (proxy) and server (wrapper)
> stubs.
>
>
> In M3 ServiceWrapper and ServiceProxy were generated from WSDL by
> scagen and were used for both local and remote invocations.
>
>
> However, some things are still unclear:
> Q: If there is nothing like request routing, how does the
> "wiring" work
> if the calls are actually hardcoded?
>
>
>
> See above.
>
> Besides of these questions a few non-technical ones:
> Q: The trunk code stream looks to me like a complete re-write.
> With even
> the component interfaces changing and nobody complaining I
> guess that
> there is nobody actually really using Tuscany SCA C++?
>
>
> I just checked M3 again and it looks that way now when we compare
> trunk in 2013 and M3 from 2006/2007. The code has evolved slowly but
> after 6 years I'm not really surprised.
>
> Q: Besides of people using it, is there anybody besides you
> working on
> it?
>
>
> I'm not really sure. I've been the only one pushing changes to trunk
> recently. I noticed a new lightweight-sca clone branch recently but
> can't remember who created it. When I get tech questions here, in
> email or IRC, and find time, I try to answer without bothering people
> asking what they're doing with the code, so there may be more clone
> branches here or on github for example, as the code is open to anyone
> who wants to hack on it.
> Q: To which extent are both the M3 and trunk versions
> "stable"? M3
> probably in the sense that nobody works on it anymore but is
> it mostly
> complete/usable?
>
>
> M3 has not changed since 2007. Trunk is moving slowly as I only spend
> a little spare time on it on some weekends or holidays. Complete and
> usable are subjective notions, as IMO an open-source project is not
> 'complete' as long as people are still interested in evolving it, and
> 'usable' depends on the use case.
>
> Q: What about interoperability with Tuscany Java? I suppose
> both M3 and
> trunk are OK as long as the binding is the same (and on the
> wire it is
> XML or whatever anyway). Which common binding types exist?
>
>
> With M3, REST. With trunk, REST and SOAP.
>
>
> Generally I have to admit that I liked the old implementation
> more,
> though this maybe caused by the new language features in trunk
> I'm not
> familiar with yet.
>
>
> 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"?
Maybe I'll post something in tuscany-users like "anybody using it?" ...
>
> Q: With the new value/list types, if there is no relation with
> XSD
> anymore, can you also query information about object types,
> e.g. which
> properties a class shall have? This is probably not needed in
> the SCA
> code, but maybe in custom extensions ...
>
>
> There isn't anything in the runtime to allow you to query the types,
> but if you have an XML (or JSON) schema, and a schema library that
> you'd like to use with your types, there's no reason why you couldn't
> use that library along with SCA.
>
> Also, type enforcement is not necessarily a disadvantage
> (admittedly
> slower though)
>
>
> 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 ...
Many thx again!!!
tge
>
> Many thx again + regards,
> the
>
> On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino
> wrote:
> > On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino
> > <js...@apache.org> wrote:
> > Hi all,
> >
> >
> > I had a few more offline Q&A exchanges with Thomas,
> and
> > thought it'd be useful to share a summary here:
> >
> >
> > Q: In the C++ trunk, is DataObject now replaced by
> > tuscany::value and tuscany::list?
> >
> >
> > A: Yes
> >
> >
> >
> >
> > BTW I just committed a number of changes I made over the
> holidays,
> > including some improvements to tuscany::value and
> tuscany::list, in
> > particular to work with lists, nested lists and trees of
> key/value
> > pairs (aka associations) as well as some minor improvements
> to handle
> > comparisons of floating point number values.
> >
> >
> > - Jean-Sebastien
>
>
>
>
>
--
........................................................
Thomas Gentsch
Römerstr. 76
70180 Stuttgart
Tel : (+49) 0711 - 46915652
mobil : (+49) 0173 - 6620507
e-mail: tg@e-tge.de
........................................................
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> Hello JS,
>
>
Hi Thomas, Happy New Year!
> now, I did some more reading etc and believe now that I mostly
> understand what's going on :-)
>
> The main missing pieces were these (correct? Possibly my terminology is
> a bit fuzzy :-):
> Q: When are SDOs used (in SCA M3) and when not?
> A: If an interface of a service uses complex types as in/out params or
> return value, otherwise simple types (like int, bool, string) are used.
> Complex types (i.e. class instances) an XSD are passed in/out as SDO
>
>
Yes
> 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.
In trunk, the equivalent of invokeService is the apply function, and
currently needs to be written by hand as scagen has not been maintained
(but could be brought back if somebody was interested in maintaining it).
> Q: What is the purpose of composite files with pure C++ modules?
> A: If a composite consists only of local components all calls are
> resolved by the OS loader. In that case basically the composite
> definition file mainly states which interfaces are in which shared lib
> and in which order are the libs to be loaded.
>
>
See above, both M3 and trunk resolve wiring dynamically.
> Q: How are remote request handled?
> A: Remote interfaces are described using WSDL, which must be processed
> using the tool scagen to generate a "ServiceWrapper" and a
> "ServiceProxy" that act as client (proxy) and server (wrapper) stubs.
>
In M3 ServiceWrapper and ServiceProxy were generated from WSDL by scagen
and were used for both local and remote invocations.
>
> However, some things are still unclear:
> Q: If there is nothing like request routing, how does the "wiring" work
> if the calls are actually hardcoded?
>
>
See above.
> Besides of these questions a few non-technical ones:
> Q: The trunk code stream looks to me like a complete re-write. With even
> the component interfaces changing and nobody complaining I guess that
> there is nobody actually really using Tuscany SCA C++?
>
I just checked M3 again and it looks that way now when we compare trunk in
2013 and M3 from 2006/2007. The code has evolved slowly but after 6 years
I'm not really surprised.
> Q: Besides of people using it, is there anybody besides you working on
> it?
>
I'm not really sure. I've been the only one pushing changes to trunk
recently. I noticed a new lightweight-sca clone branch recently but can't
remember who created it. When I get tech questions here, in email or IRC,
and find time, I try to answer without bothering people asking what they're
doing with the code, so there may be more clone branches here or on github
for example, as the code is open to anyone who wants to hack on it.
> Q: To which extent are both the M3 and trunk versions "stable"? M3
> probably in the sense that nobody works on it anymore but is it mostly
> complete/usable?
>
M3 has not changed since 2007. Trunk is moving slowly as I only spend a
little spare time on it on some weekends or holidays. Complete and usable
are subjective notions, as IMO an open-source project is not 'complete' as
long as people are still interested in evolving it, and 'usable' depends on
the use case.
> Q: What about interoperability with Tuscany Java? I suppose both M3 and
> trunk are OK as long as the binding is the same (and on the wire it is
> XML or whatever anyway). Which common binding types exist?
>
With M3, REST. With trunk, REST and SOAP.
>
> Generally I have to admit that I liked the old implementation more,
> though this maybe caused by the new language features in trunk I'm not
> familiar with yet.
>
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.
>
> Q: With the new value/list types, if there is no relation with XSD
> anymore, can you also query information about object types, e.g. which
> properties a class shall have? This is probably not needed in the SCA
> code, but maybe in custom extensions ...
>
There isn't anything in the runtime to allow you to query the types, but if
you have an XML (or JSON) schema, and a schema library that you'd like to
use with your types, there's no reason why you couldn't use that library
along with SCA.
> Also, type enforcement is not necessarily a disadvantage (admittedly
> slower though)
>
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.)
>
> Many thx again + regards,
> the
>
> On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino wrote:
> > On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino
> > <js...@apache.org> wrote:
> > Hi all,
> >
> >
> > I had a few more offline Q&A exchanges with Thomas, and
> > thought it'd be useful to share a summary here:
> >
> >
> > Q: In the C++ trunk, is DataObject now replaced by
> > tuscany::value and tuscany::list?
> >
> >
> > A: Yes
> >
> >
> >
> >
> > BTW I just committed a number of changes I made over the holidays,
> > including some improvements to tuscany::value and tuscany::list, in
> > particular to work with lists, nested lists and trees of key/value
> > pairs (aka associations) as well as some minor improvements to handle
> > comparisons of floating point number values.
> >
> >
> > - Jean-Sebastien
>
>
>
>
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hello JS,
now, I did some more reading etc and believe now that I mostly
understand what's going on :-)
The main missing pieces were these (correct? Possibly my terminology is
a bit fuzzy :-):
Q: When are SDOs used (in SCA M3) and when not?
A: If an interface of a service uses complex types as in/out params or
return value, otherwise simple types (like int, bool, string) are used.
Complex types (i.e. class instances) an XSD are passed in/out as SDO
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
Q: What is the purpose of composite files with pure C++ modules?
A: If a composite consists only of local components all calls are
resolved by the OS loader. In that case basically the composite
definition file mainly states which interfaces are in which shared lib
and in which order are the libs to be loaded.
Q: How are remote request handled?
A: Remote interfaces are described using WSDL, which must be processed
using the tool scagen to generate a "ServiceWrapper" and a
"ServiceProxy" that act as client (proxy) and server (wrapper) stubs.
However, some things are still unclear:
Q: If there is nothing like request routing, how does the "wiring" work
if the calls are actually hardcoded?
Besides of these questions a few non-technical ones:
Q: The trunk code stream looks to me like a complete re-write. With even
the component interfaces changing and nobody complaining I guess that
there is nobody actually really using Tuscany SCA C++?
Q: Besides of people using it, is there anybody besides you working on
it?
Q: To which extent are both the M3 and trunk versions "stable"? M3
probably in the sense that nobody works on it anymore but is it mostly
complete/usable?
Q: What about interoperability with Tuscany Java? I suppose both M3 and
trunk are OK as long as the binding is the same (and on the wire it is
XML or whatever anyway). Which common binding types exist?
Generally I have to admit that I liked the old implementation more,
though this maybe caused by the new language features in trunk I'm not
familiar with yet.
Q: With the new value/list types, if there is no relation with XSD
anymore, can you also query information about object types, e.g. which
properties a class shall have? This is probably not needed in the SCA
code, but maybe in custom extensions ...
Also, type enforcement is not necessarily a disadvantage (admittedly
slower though)
Many thx again + regards,
tge
On Wed, 2013-01-02 at 23:49 -0800, Jean-Sebastien Delfino wrote:
> On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
> Hi all,
>
>
> I had a few more offline Q&A exchanges with Thomas, and
> thought it'd be useful to share a summary here:
>
>
> Q: In the C++ trunk, is DataObject now replaced by
> tuscany::value and tuscany::list?
>
>
> A: Yes
>
>
>
>
> BTW I just committed a number of changes I made over the holidays,
> including some improvements to tuscany::value and tuscany::list, in
> particular to work with lists, nested lists and trees of key/value
> pairs (aka associations) as well as some minor improvements to handle
> comparisons of floating point number values.
>
>
> - Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Sat, Dec 29, 2012 at 6:20 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Hi all,
>
>
> I had a few more offline Q&A exchanges with Thomas, and thought it'd be
> useful to share a summary here:
>
>
> Q: In the C++ trunk, is DataObject now replaced by tuscany::value
> and tuscany::list?
>
>
> A: Yes
>
>
>
BTW I just committed a number of changes I made over the holidays,
including some improvements to tuscany::value and tuscany::list, in
particular to work with lists, nested lists and trees of key/value pairs
(aka associations) as well as some minor improvements to handle comparisons
of floating point number values.
- Jean-Sebastien
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Hi all,
I had a few more offline Q&A exchanges with Thomas, and thought it'd be
useful to share a summary here:
Q: In the C++ trunk, is DataObject now replaced by tuscany::value
and tuscany::list?
A: Yes
Q: Why are most files in kernel/ C++ header files?
A: They’re C++ templates that you can just include, similar to what other
C++ frameworks like boost do for example.
Q: In M3 a C++ component implementation looked like this:
virtual commonj::sdo::DataObjectPtr /*AccountReport*/
getAccountReport(const string customerID) {
...
}
What does a C++ component implementation look like with the code in trunk?
A: With trunk, a C++ component implementation must contain this function:
const value apply(const list<value>& params) {
// implement your own dispatch code here, for example
// if first element of params is “getAccountReport” then
// call your own getAccountReport function, which could look like
// const value getAccountReport(const value customerID)
}
The apply() function is a component invocation dispatch mechanism. It
shouldn’t be too difficult to provide a tool to generate the body of
apply() from a WSDL+XSD to lift the programming model to a level of
abstraction close to M3.
I was initially planning to do that but then found that writing apply() by
hand was good enough for me. I'm not sure about the value of requiring an
app developer to write a WSDL+XSD, use a tool to generate code, link with
that code, understand the additional moving parts and data conversion etc,
just to avoid having to write that apply() function... but if somebody
wants to do it, I can try to help integrate that support.
Q: Is the runtime implemented as Apache HTTPD modules?
A: Yes, the runtime plugs into Apache HTTPD as a set of HTTPD modules but
it should be possible to integrate with other servers too.
Q: Are C++ component implementations packaged as dynamic libraries?
A: Yes, the runtime also supports other component implementation
technologies and languages incl. Python, OpenCL C99 (for GPU programming),
Java (experimental) and a subset of MIT Scheme (useful for self-contained
testing).
Q: Which communication protocols are supported?
A: REST Web services using XML, ATOM, RSS or JSON over HTTP, and JSON-RPC.
Communication with SOAP services is supported using a configurable SCA
component wrapping Axis2/C in components/webservice/.
Q: Which versions of SCA are implemented?
M3 implements a subset of the OSOA (pre-OASIS) SCA assembly spec and a
subset of the corresponding SCA C++ component implementation spec.
Trunk implements a subset of the OASIS SCA assembly spec. The C++ component
implementation model is different from the spec, but like I said above it
shouldn't be too difficult to generate C++ implementations as per the spec
on top of the current dispatch mechanism.
Hope that helps.
- Jean-Sebastien
On Wed, Dec 19, 2012 at 1:00 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> Hi JS,
>
> I'm still looking through the docs, code, etc. I can find.
>
> One thing I discovered: it does not look to me as if SDO support has
> been removed from Java SCA, at least I found some related activity in
> 2011:
>
> http://www.mail-archive.com/user@tuscany.apache.org/msg03435.html
>
> http://www.mail-archive.com/dev@tuscany.apache.org/msg17116.html
>
> (the latter is quite funny because I actually submitted this against C++
> but seems as if the same problem occurred with Java? :-)
>
> More later ... :-)
> Rgds,
> tge
>
> On Thu, 2012-12-06 at 01:04 -0800, Jean-Sebastien Delfino wrote:
> > On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
> >
> > OK, many thx for this info!
> >
> > Regarding SDO - yes, I noticed that there was not a lot of
> > activity
> > during the last years.
> > Hello out there: Is there anybody else still using this?
> >
> > Rgd SDO as SCA-internal data-flow mechanism - what is being
> > used now?
> > I know about libxml2 (actually its being used in SCA/SDO :-),
> > nothing
> > yet about JSON, will read.
> >
> >
> > Hi Thomas,
> >
> >
> > Here's a short overview of what's used now.
> >
> >
> > Data read/write functions are provided for XML (using Libxml2 [1]),
> > JSON (using Mozilla SpiderMonkey but I've started to migrate to
> > Jansson [2]), and Lisp/Scheme S-expressions [3].
> >
> >
> > Here's how to read XML in a C++ component:
> > <customer
> > age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>
> (415)765-4321</phone></customer>
> >
> >
> > // A list of strings containing the above XML doc, obtained from an
> > input stream for example
> > const list<string> ls = ...;
> >
> >
> > // Read the XML doc (the failable<...> result type helps encapsulate
> > error handling)
> > // See below for a description of the 'value' data type
> > const failable<value> fe = xml::readElements(ls);
> >
> >
> > // Assuming no failure, get and print the result
> > const value e = content(fe);
> > cout << e << endl;
> >
> >
> > The result is a list like follows (using the S-expression syntax here
> > for conciseness: element, customer, attribute, age are symbols, 21 is
> > a number, "johndoe" is a string, (x y) is a list of x, y):
> > ((element customer (attribute age "21") (element name "johndoe")
> > (element phone "(650)123-4567") (element phone "(415)765-4321")))
> >
> >
> > The runtime is schema-less. You do not need an XML schema to
> > read/write any XML.
> >
> >
> > If you don't care about the XML element vs attribute representation
> > you can strip it like this:
> > const value v = elementsToValues(e);
> > to get this:
> > ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> > "(415)765-4321"))))
> >
> >
> > Note the @age attribute name, which follows the Badgerfish [4]
> > convention often used to name XML attributes in JSON documents for
> > example.
> >
> > The same data can be constructed and represented in the various
> > programming languages supported by the runtime, as follows:
> >
> >
> > C++:
> > list<value>(list<value>("customer", list<value>("@age", 21),
> > list<value>("name", string("johndoe")), list<value>("phone",
> > list<value>("(650)123-4567", "(415)765-4321"))));
> > using the following C++ types:
> > - string, similar to std::string but lighter and faster for small
> > strings, with builtin conversions from/to native char*;
> > - list<T>, a lightweight list/lazy-list type with useful
> > Lisp/Scheme-like [5] functions incl. cons, car, cdr, map, filter,
> > reduce, assoc, etc;
> > - lambda<R(P...)>, a function type similar to std::function but
> > lighter and faster;
> > - value, a dynamic value type (type can be number, boolean, symbol,
> > string, list<value>, lambda<value(list<value>)>, value*) with builtin
> > conversions from/to native double, bool, char*, C++ lambdas and
> > pointers.
> >
> >
> > Python:
> > ((customer, ("'@age" 21), ("'name", "johndoe") (phone,
> > ("(650)123-4567" "(415)765-4321"))),)
> > using Python tuples [6] and native Python data types for strings,
> > numbers and booleans.
> >
> >
> > JavaScript / JSON:
> >
> {"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
> > using JSON arrays and native Javascript types.
> >
> >
> > Scheme:
> > ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> > "(415)765-4321"))))
> > just an S-expression.
> >
> >
> > Java (there's experimental support for running Java components on the
> > C++ runtime):
> > list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
> > list("'phone", list("(650)123-4567", "(415)765-4321"))));
> > using java.lang.Iterable [7] for lists and native Java data types for
> > strings, numbers and booleans (the list(...) function is a static
> > 'builder' function returning a java.lang.Iterable<?>.)
> >
> >
> > To summarize: fast and schemaless support for XML, JSON and
> > S-expressions, with lightweight representation using lists and simple
> > types in the supported programming languages.
> >
> >
> > Hope that helps.
> >
> >
> > [1] http://www.xmlsoft.org
> > [2] http://www.digip.org/jansson/
> > [3] http://en.wikipedia.org/wiki/S-expression
> > [4] http://badgerfish.ning.com
> > [5]
> http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
> > [6]
> http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
> > [7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
> >
> >
> > - Jean-Sebastien
>
>
>
Re: Porting Tuscany C++ to C++11 and some code cleanup
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi JS,
I'm still looking through the docs, code, etc. I can find.
One thing I discovered: it does not look to me as if SDO support has
been removed from Java SCA, at least I found some related activity in
2011:
http://www.mail-archive.com/user@tuscany.apache.org/msg03435.html
http://www.mail-archive.com/dev@tuscany.apache.org/msg17116.html
(the latter is quite funny because I actually submitted this against C++
but seems as if the same problem occurred with Java? :-)
More later ... :-)
Rgds,
tge
On Thu, 2012-12-06 at 01:04 -0800, Jean-Sebastien Delfino wrote:
> On Fri, Nov 30, 2012 at 9:43 AM, Thomas Gentsch <tg...@e-tge.de> wrote:
>
> OK, many thx for this info!
>
> Regarding SDO - yes, I noticed that there was not a lot of
> activity
> during the last years.
> Hello out there: Is there anybody else still using this?
>
> Rgd SDO as SCA-internal data-flow mechanism - what is being
> used now?
> I know about libxml2 (actually its being used in SCA/SDO :-),
> nothing
> yet about JSON, will read.
>
>
> Hi Thomas,
>
>
> Here's a short overview of what's used now.
>
>
> Data read/write functions are provided for XML (using Libxml2 [1]),
> JSON (using Mozilla SpiderMonkey but I've started to migrate to
> Jansson [2]), and Lisp/Scheme S-expressions [3].
>
>
> Here's how to read XML in a C++ component:
> <customer
> age="21"><name>johndoe</name><phone>(650)123-4567</phone><phone>(415)765-4321</phone></customer>
>
>
> // A list of strings containing the above XML doc, obtained from an
> input stream for example
> const list<string> ls = ...;
>
>
> // Read the XML doc (the failable<...> result type helps encapsulate
> error handling)
> // See below for a description of the 'value' data type
> const failable<value> fe = xml::readElements(ls);
>
>
> // Assuming no failure, get and print the result
> const value e = content(fe);
> cout << e << endl;
>
>
> The result is a list like follows (using the S-expression syntax here
> for conciseness: element, customer, attribute, age are symbols, 21 is
> a number, "johndoe" is a string, (x y) is a list of x, y):
> ((element customer (attribute age "21") (element name "johndoe")
> (element phone "(650)123-4567") (element phone "(415)765-4321")))
>
>
> The runtime is schema-less. You do not need an XML schema to
> read/write any XML.
>
>
> If you don't care about the XML element vs attribute representation
> you can strip it like this:
> const value v = elementsToValues(e);
> to get this:
> ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> "(415)765-4321"))))
>
>
> Note the @age attribute name, which follows the Badgerfish [4]
> convention often used to name XML attributes in JSON documents for
> example.
>
> The same data can be constructed and represented in the various
> programming languages supported by the runtime, as follows:
>
>
> C++:
> list<value>(list<value>("customer", list<value>("@age", 21),
> list<value>("name", string("johndoe")), list<value>("phone",
> list<value>("(650)123-4567", "(415)765-4321"))));
> using the following C++ types:
> - string, similar to std::string but lighter and faster for small
> strings, with builtin conversions from/to native char*;
> - list<T>, a lightweight list/lazy-list type with useful
> Lisp/Scheme-like [5] functions incl. cons, car, cdr, map, filter,
> reduce, assoc, etc;
> - lambda<R(P...)>, a function type similar to std::function but
> lighter and faster;
> - value, a dynamic value type (type can be number, boolean, symbol,
> string, list<value>, lambda<value(list<value>)>, value*) with builtin
> conversions from/to native double, bool, char*, C++ lambdas and
> pointers.
>
>
> Python:
> ((customer, ("'@age" 21), ("'name", "johndoe") (phone,
> ("(650)123-4567" "(415)765-4321"))),)
> using Python tuples [6] and native Python data types for strings,
> numbers and booleans.
>
>
> JavaScript / JSON:
> {"customer":{"@age":"21","name":"johndoe","phone":["(650)123-4567","(415)765-4321"]}}
> using JSON arrays and native Javascript types.
>
>
> Scheme:
> ((customer (@age "21") (name "johndoe") (phone ("(650)123-4567"
> "(415)765-4321"))))
> just an S-expression.
>
>
> Java (there's experimental support for running Java components on the
> C++ runtime):
> list(list("'customer", list("'@age", 21), list("'name", "johndoe"),
> list("'phone", list("(650)123-4567", "(415)765-4321"))));
> using java.lang.Iterable [7] for lists and native Java data types for
> strings, numbers and booleans (the list(...) function is a static
> 'builder' function returning a java.lang.Iterable<?>.)
>
>
> To summarize: fast and schemaless support for XML, JSON and
> S-expressions, with lightweight representation using lists and simple
> types in the supported programming languages.
>
>
> Hope that helps.
>
>
> [1] http://www.xmlsoft.org
> [2] http://www.digip.org/jansson/
> [3] http://en.wikipedia.org/wiki/S-expression
> [4] http://badgerfish.ning.com
> [5] http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lists.html#Lists
> [6] http://docs.python.org/2/tutorial/datastructures.html#tuples-and-sequences
> [7] http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html
>
>
> - Jean-Sebastien