Return-Path: X-Original-To: apmail-tuscany-dev-archive@www.apache.org Delivered-To: apmail-tuscany-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 11186EB78 for ; Mon, 14 Jan 2013 07:35:28 +0000 (UTC) Received: (qmail 99860 invoked by uid 500); 14 Jan 2013 07:35:27 -0000 Delivered-To: apmail-tuscany-dev-archive@tuscany.apache.org Received: (qmail 99461 invoked by uid 500); 14 Jan 2013 07:35:21 -0000 Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tuscany.apache.org Delivered-To: mailing list dev@tuscany.apache.org Received: (qmail 99412 invoked by uid 99); 14 Jan 2013 07:35:19 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jan 2013 07:35:19 +0000 Received: from localhost (HELO mail-ie0-f174.google.com) (127.0.0.1) (smtp-auth username jsdelfino, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jan 2013 07:35:19 +0000 Received: by mail-ie0-f174.google.com with SMTP id c11so4559256ieb.5 for ; Sun, 13 Jan 2013 23:35:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.219.233 with SMTP id pr9mr6104672igc.19.1358148918133; Sun, 13 Jan 2013 23:35:18 -0800 (PST) Received: by 10.64.23.241 with HTTP; Sun, 13 Jan 2013 23:35:17 -0800 (PST) In-Reply-To: <1357594110.2492.150.camel@parsley> References: <1353690145.2516.732.camel@parsley> <1353879062.2516.1164.camel@parsley> <1354297394.2683.969.camel@parsley> <1355950801.2478.897.camel@parsley> <1357594110.2492.150.camel@parsley> Date: Sun, 13 Jan 2013 23:35:17 -0800 Message-ID: Subject: Re: Porting Tuscany C++ to C++11 and some code cleanup From: Jean-Sebastien Delfino To: dev@tuscany.apache.org Content-Type: multipart/alternative; boundary=14dae934120fd142a804d33aafd7 --14dae934120fd142a804d33aafd7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch 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 > > 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 > > > > --14dae934120fd142a804d33aafd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 7, 2013 at 1:28 PM, Thomas Gentsch <= span dir=3D"ltr"><tg@e-= tge.de> wrote:

Hello JS,


Hi Thomas, Happy New Year!
= =A0
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
=A0
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 inv= ocation of a component involved=A0CPPServiceWrapper::getServiceWrapper to l= oad the component library, lookup a factory function named after the servic= e name, create an instance of CPPServiceWrapper, and eventually executing g= enerated code in=A0CPPServiceWrapper::invokeService to=A0dispatch the call = to the target C++ component method. =A0

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 maintai= ning it).
=A0
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 w= iring dynamically.
=A0
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) st= ubs.

In M3 ServiceWrapper and ServicePr= oxy were generated from WSDL by scagen and were used for both local and rem= ote invocations.
=A0=A0

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.
=A0
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 c= ompare trunk in 2013 and M3 from 2006/2007. The code has evolved slowly but= after 6 years I'm not really surprised.
=A0
Q: Besides of people using it, is there anybody besides you working on
it?

I'm not really sure. I've b= een the only one pushing changes to trunk recently. I noticed a new lightwe= ight-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 th= ere may be more clone branches here or on github for example, as the code i= s open to anyone who wants to hack on it.
=A0
Q: To which extent are both the M3 and trunk versions "stable"? M= 3
probably in the sense that nobody works on it anymore but is it mostly
complete/usable?

M3 has not changed sin= ce 2007. Trunk is moving slowly as I only spend a little spare time on it o= n 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 c= ase.
=A0
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.
=A0=

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<= br> familiar with yet.

I've worked on C= ++ M3, trunk and even the Java project so I can imagine why someone would p= refer 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 t= hem, or even contribute to maintain or change them to something you like, i= f you're interested.
=A0

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 u= se that library along with SCA.
=A0
Also, type enforcement is not necessarily a disadvantage (admittedly
slower though)

I'm not sure if you&= #39;re talking about validating the data exchanged with SCA components (whi= ch could be done with a validating proxy) or about generating static code f= rom schema type definitions, but both approaches should work nicely along M= 3 or trunk (for the latter you'd need a generator like scagen on top of= the runtime invocation mechanism.)
=A0

Many thx again + regards,
=A0 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
> <jsdelfino@apache.org&g= t; wrote:
> =A0 =A0 =A0 =A0 Hi all,
>
>
> =A0 =A0 =A0 =A0 I had a few more offline Q&A exchanges with Thomas= , and
> =A0 =A0 =A0 =A0 thought it'd be useful to share a summary here: >
>
> =A0 =A0 =A0 =A0 Q: In the C++ trunk, is DataObject now replaced by
> =A0 =A0 =A0 =A0 tuscany::value and tuscany::list?
>
>
> =A0 =A0 =A0 =A0 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<= br> > comparisons of floating point number values.
>
>
> - Jean-Sebastien




--14dae934120fd142a804d33aafd7--