Hi Simon
On 8/15/06, Simon Laws <[EMAIL PROTECTED]> wrote:
Sounds like an great idea Andy. I would interested in solving the same
problem for PHP, i.e. have a PHP container running in the C++ runtime so
that you can call PHP scripts as services and have to scripts call other
services.
Hopefully the work I'm doing with Python will make it easy for other
component language extensions to be written. I've tried to think about
generic cases as I've gone.
The hard part I guess is getting in and out of the Python or PHP
environments. This is not so much of a problem when the script is acting
as
a client making calls via references Calls can be made into the C++ model
to
work out what to do. Also the script can control access to the underlying
transport for sending requests and receiving replies. At least in the
simple
blocking send/receive case. It is more of a challenge on the service end.
We
need a request to be recieved and be dispatches to the correct script
function. We can probably approach this in one of two ways.
A) have the script environment handle the request as it would normally and
then call down into C++ to work out what method to call
B) have C++ work out what to do and have is call into the script
environment.
Python has a pretty clear embedding API written in C, so it's most sensible
to do B for Python - I'm going to write a wrapper that will initialise the
Python environment and then call the Python module defined in the SCDL.
In the PHP environment apprach A is taken by the PHP SOAP extension in as
much that you create a SOAP server in your PHP code and then tell it to
process the HTTP input (the SOAP XML) that is held in the PHP context. I'm
reliably informed that approach B is also possible and in fact this
approach
must be what is happing inside the CGI adapter for PHP for Apache, I.e.
apache recieves an HTTP requests and fires up a PHP runtime to handle it.
For usability, I guess you'll want to carry on using approach A, as that is
the main way that PHP users will want to operate. It should be possible (via
PHP extensions) to configure and start a Tuscany runtime which has a
language extension allowing it to call into other PHP scripts (or Python, or
C++, etc)
A question that springs to mind. In the Python case what are you proposing
for the interface description, i.e. you say that you can use introspection
to find the method at runtime. In the component type descripition are you
going to use WSDL to describe the interface that the script presents. If
so
how is the WSDL to be generated?
For now, I plan to use either of the "official" interfaces - WSDL or a C++
header - users will have to hand crank these to match the signatures of the
Python functions. I'd like to extend the allowed interfaces (which is why
"interface" is one of the extension types that can be defined in the "
Tuscany.config" below) to have an <interface.python> which would be
understandable to the system and the SCAGEN tool, but I haven't got that far
yet :-)
Anyhow I need to think about this some more. If we can explore both of
these
at the same time maybe we can extract some generalizations.
Sounds good, let's keep this conversation going.
Cheers,
Andy
On 8/15/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> On 8/15/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > This looks a reasonable approach. The runtime will need to call the
> > extension to load it's part of the model. So ModelLoader will need to
> know
> > which library to call for a particular implementation type. The
> mechanism
> > should be the same for all implementation types so the existing
> > implementation.cpp should be refactored and not hard wired into the
> core.
> >
> > I think it would be good to prototype this in a branch to experiment
> with
> > what works and what doesn't!
>
>
> I agree - my committer access isn't through yet, so for now I'll work
> locally, and then upload it into a new branch for review when I can.
>
> It may be worth considering defining the extensions as composites???
>
>
> This sounds like a good idea, but I can't quite get my head around how
it
> works! The "Extending Chianti" document is mostly empty, but I believe
> this
> is how tuscany java includes and employs extensions. Can anyone point me
> to
> some examples or documentation for this?
>
> Thanks
> Andy
>
>
> >
> > On 14/08/06, Andrew Borley <[EMAIL PROTECTED]> 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
> > >
> > >
> >
> >
> > --
> > Pete
> >
> >
>
>
