On 8/15/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Andrew Borley wrote:
> Hi All,
>
> I've been thinking a bit more about how we could do extensions.
> Specifically, I've been working through what would be needed to add a
new
> component language binding in to Tuscany. I'm basing this on adding
> support
> for components written in Python, as this is a language that is widely
> used,
> extensible, embeddable and includes introspection.
>
> To call a method in a Python module all we would need in the
> .composite file
> is something like the following information:
> <component name="DivideServiceComponent">
> <implementation.python module="DivideModule"
> path="/path/to/python/module"/>
> </component>
>
> The Python module will be in a file at
> "/path/to/python/module/DivideModule.py" and would have a method that
> implements a divide operation.
>
> Python's introspection can find the correct method and describe the
> method
> arguments and return types, so there is no requirement for code
generated
> via SCAGEN here (other languages may well need generated code).
>
> We therefore need a way to extend the assembly model with the <
> implementation.python> element and a way to extend Tuscany so that
> when it
> finds an <implementation.python> element, it knows to call a library
that
> will invoke the Python code.
>
> So to list things out we need to:
>
> 1) Define extensions for Tuscany in some way - perhaps a "Tuscany.config
"
> file that could have a schema like:
> <tuscany-config>
> <extension type="implementation or servicebinding or referencebinding
or
> interface"
> suffix="xs:NCName"
> library="xs:NCName"
> path="xs:NCName"?
> schema="xs:NCName"?>*
> <parameter name="xs:NCName">*
> some-parameter-value
> </parameter>
> </extension>
> </tuscany-config>
>
> So for example, a Python component langauge implementation extension
like
> this:
> <tuscany-config>
> <extension type="implementation" suffix="python"
> library="tuscany-python"
> path="/path/to/python/tuscany/extension/library"
> schema="xsd/tuscany-impl-python.xsd">
> <parameter name="pythonroot">/path/to/python/installation</parameter>
> </extension>
> </tuscany-config>
>
> would have a library named
> /path/to/python/tuscany/extension/library/libtuscany-python.so and a
> schema
> to define the <implementation.python> element at
> /path/to/python/tuscany/extension/library/xsd/tuscany-impl-python.xsd.
> The
> library would be initialised with a parameter named pythonroot with
value
> /path/to/python/installation.
>
>
> 2) Tuscany will need changing to:
> a) register any schemas named in the "Tuscany.config" file
> b) when the .composite files are read, notice the <implementation.python
>
> element and load and initialise the specified extension library with the
> contents of the <implementation.python> element and the parameters
> from the
> "Tuscany.config" file
> c) when the component is invoked, call the extension library with a
> tuscany::sca::Operation object. The extension will find the appropriate
> operation in the Python module, find the parameter and return types
> that the
> operation expects, map the C++ types to Python types, invoke the
> operation
> and finally map the return type from Python to C++.
>
>
> 3) Create an extension to Python that will add support for invoking
> references from Python components.
> e.g. enable the Python equivalent of:
> // 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);
>
>
> How does this sound as a start to enabling some extensions in SCACPP?
> I'm happy to get going implementing this, but it may be worth me
> working in
> a branch as there'll be lots of changes (& I don't yet have my committer
> access).
>
> Cheers
>
> Andrew
>
Andy,
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension, name
the library and associate it with an implementation type? As a first
step at least, I think it would be great to have a very simple scheme
where you just drop a library named implementation.python in a Tuscany
extensions or plugins directory, or just name the library how you want
but have in it an extern public functtion that will return the XSD
QNames that the library understands?
Yeah, I was thinking a "drop it in a directory" approach would be good, but
I couldn't think how to expose the information we need - specifically naming
the library/xsd file and/or having a set of known public functions is a good
way to go. I will do this first - possibly an xml config file would also be
useful - we should be able to support both?
2. Is there a way to define interfaces or something similar to
interfaces in Python? Could we have an <interface.python .../> extension
to save the Python developer from having to learn WSDL or C++?
Yep, like I said to Simon, I'd like to add an interface.python extension,
but haven't yet worked out what that will need to do or how it could be
done. AFAIK the interface.cpp is mainly used by the SCAGEN tool to generate
the proxy and wrapper code, and the interface.wsdl is mainly used to specify
a WSDL file that a service with a binding.ws can use. I guess it's legal to
use an interface.cpp (instead of interface.wsdl) in a service with a
binding.ws, but I don't expect that will currently work!
Cheers
Andy
