On 9/1/06, Simon Laws <[EMAIL PROTECTED]> wrote:
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 > > Hi AndySounds like great progress. 1) I would favour whatever hides SCA from the Python programmer the most so I like annotations. However if annotations are hard then the first approach would be a stake in the ground until you have a better feel for how the extension framework operates. 2) PHP is loosly typed also but you can get at the comments in the source so you can describe function signatures there and look at them at run time (see http://www.osoa.org/display/Main/PHP+and+SCA+White+Paper). Can you do the same in Python?
I think you can - there is certainly ways to document classes and functions, so following this PHP style may well be the way to go.
If you do use support in Python to get at types its likely to be a run time operation so we would need to rely on the generic proxies/wrappers in C++ and then call up into Python doing the apporpriate transformation as dictated by the runtime generated interface description. As this is likely to be a runtime thing I would go with WSDL to describe the interface. You then have the mechanism for describing the python script as a remote service ready to go. It would be good to have a component in C++ that is able to generate WSDL on the fly (this would be handy for PHP also) but we would have to agree how to describe the interface to the WSDL generator!
I agree that WSDL is a better interface standard to use than C++ header files! I'm not sure what our support for this currently looks like - I expect if you have a C++ component described by an interface.wsdl then either SCAGEN or the runtime would have problems - it's clearly the way to go to get remotable starting to work though.
Maybe you could say a little bit more about what you do now to help us envisage the development process and flow of control. - you write a python class/operation - you write your .componentType file including implementation.python - you hand craft a .h file to match the python class ? - you run SCA gen to generate the wrapper - you have some code that converts the wrapper call into a call into the Python engine targetted at the appropriate operation Is that correct?
Very close! - here's the definitive list: - you write a python class/operation - you write your .composite file including implementation.python - you hand craft a .h file to match the python class - you write your .componentType file including interface.cpp and specifying your hand crafted .h file - you run SCA gen to generate the proxy for your service - you create a C++ client or C++ component with a reference that calls the service as normal - the Tuscany runtime provides the client or component with the generated proxy so it looks like a normal C++ call - the extension provides the wrapper that calls the Python engine and invokes the appropriate operation Cheers Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
