I've a couple of questions based on I'd like to also have a Python container
for the Java runtime, and from the perspective of how the the existing
JavaScript and Groovy containers work that we already have for the Java
runtime.
In the implementation.python element do you really need separate path and
class attributes? This is likely because I don't know anything about Python
or the C++ runtime work but for comparison a JavaScript impl looks like:
<js:implementation.jsscript="org/apache/tuscany/container/javascript/function/HelloWorld.js"/>
For references, could you just use the .componentType side file to define
references as an alternative to using new annotations? For JavaScript, if
the .componentType side file defines a reference then the JavaScript
container uses the dynamic nature of the language to automatically define a
variable with the same name as the reference. I don't have a great example
but you can see this in the e4x.js testcase where the script uses a variable
named extHelloWorldService which is the name of the reference defined from
the .componentType side file:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/containers/container.javascript/src/test/resources/org/apache/tuscany/container/javascript/function/e4x.js
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/containers/container.javascript/src/test/resources/org/apache/tuscany/container/javascript/function/e4x.componentType
...ant
On 8/31/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
Hi all,
I'm inches away from getting an extension working that allows Python
scripts
to be used as components in SCA C++. I should be putting that up some time
tomorrow - I'll start a thread about a few minor issues with the extension
framework that I've come across, but it hasn't been too complex to get
this
going.
At the moment the extension provides an implementation.python element to
the
.composite of the form:
<implementation.python module="PythonModuleName"
path="relative/path/to/module" class="PythonClassName"/>
This allows other C++ components or C++ clients to call the service
implemented by code inside the Python module. The service interface is
currently described by a C++ header file, and uses the
interface.cppinterface binding. Currently, references from the Python
components are not
enabled (see below).
There are two further areas that are needed for full integration of Python
into SCA (or SCA into Python):
1) A programming model for SCA in Python to allow Python components or
Python clients to call SCA services. This will enable components with
Python
implementations to have references.
We could either create a Python extension that will emulate the service
lookup that we do in C++, e.g. a Python equivalent of the following C++
snippet:
// First, get the current ComponentContext
osoa::sca::ComponentContext myContext =
osoa::sca::ComponentContext::getCurrent();
// Find the required service, as referenced in
CalculatorImpl.componentType
DivideService* divideService =
(DivideService*)myContext.getService("divideService");
// Finally, invoke the service
result = divideService->divide(arg1, arg2);
Alternatively, we could look at doing some kind of annotations within the
Python component module - I'm not sure whether Python has annotation
support
(I don't believe so), or whether there is a way to 'fake' it to make
comments/documentation act as annotations.
2) An interface.python extension so that python components do not have to
have their interfaces converted to a C++ or WSDL description. Due to the
loose typing that Python allows this isn't the easiest thing to do - most
functions have signatures like: def myMethod(arg1, arg2) - and (as far as
I
can currently tell) there is no way to determine the types of the
arguments
or return values aside from at invocation time.
At the moment the SCAGEN tool generates the C++ component proxy and
wrapper
classes based on the C++ header specified in the interface.cpp element in
the .componentType file. If the .componentType file has an
interface.pythonelement instead, and specifies the Python module,
generating the correct C++
code neccessary to call the python service is hard. Alternatively, the
interface.python could specify the function signatures itself, but that
starts to stray into WSDL territory, e.g:
<interface.python>
<function name="myMethod">
<argument name="arg1" type="string"/>
<argument name="arg2" type="int"/>
<return type="string"/>
</function>
</interface.python>
There may well be a way to specify things a bit tighter in Python that i
don't know about - I'll keep looking into this.
What do people think about these various issues? Has anyone got any
suggestions?
Thanks!
Andy
