Hi Sebastien, I've used this new layout for the Python extension work I've just put up, and it all seems to work fine :-) I went through the pain of creating an interface.python that made users define the operations and their return types in the .componentType file due to the issue you described below. Your work meant I could throw all that out - much nicer and far less work for users :-)
Cheers Andy On 9/12/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
While working on our Ruby component implementation extension I ran into a few issues with how parameters and return values are passed to the tuscany::sca::Operation objects representing SCA invocations. An Operation object carries the parameters and return value of an SCA invocation. The Operation also keeps track of the C++ types of its parameters and return value. Before my changes our code was forcing the client of an invocation to decide ahead of time the type of the return value (as well as allocate storage for it). Also our Web service binding relied partly on the type information in incoming SDOs, partly on the type information from the WSDL/XSD defining the service interface, and partly on the type information associated with the Operation parameters and return value. This approach works OK in pure statically typed environments (e.g. C++ components with C++ interfaces, WSDL/XSD defining the service interfaces, and no use of xsd:Any) but starts to break when components exchange data without having pre-defined all the types (typical with scripting languages like Ruby, Python, or Javascript), when we want to allow for type conversions (int to a long, long to a double etc.) or when we start to use xsd:any in service interfaces. I also ran into a number of memory violation problems when a callee would store data allocated on the stack into a return value, and the data would become invalid once the callee returned. Finally we currently have memory leaks as the parameters and return values allocated on the heap never seem to be freed. To start fixing these issues I implemented the following simple scheme: - A service proxy gets parameters in some form from its client (the WSServiceProxy gets data out of DataObject, the RubyServiceProxy gets Ruby VALUEs). - The proxy is responsible for converting the parameters to the corresponding C++ types, then adds them to the Operation. - A service wrapper gets the parameters out of the Operation, looks at the C++ types recorded in the Operation, and converts them to the types expected by the wrapped service (for example the WSServiceWrapper populates properties of a DataObject, the RubyServiceWrapper converts the data to Ruby VALUEs). - The service wrapper then gets back a result from the wrapped service (out of a DataObject in WSServiceWrapper, a Ruby VALUE in RubyServiceWrapper), converts it to the corresponding C++ type, and stores it in the Operation's returnValue. - The client service proxy then gets the Operation's returnValue, and is responsible for converting it to the expected type on the client side (set it into a DataObject property in WSServiceProxy or convert it to a Ruby VALUE in RubyServiceProxy). Basically, the sender converts data to the corresponding/closest C++ type, the receiver looks at the type of the data and performs the necessary conversion, if any. In most cases there is no conversion at all. I also adjusted the XSLT used to generate CPP proxies to implement that scheme and call Operation::getReturnValue() in proxy methods to get the up-to-date pointer to the return value. Could you guys please take a look at what I did and let me know if you think that there is any problem with this approach. We still have the memory leak issue as I have not added the missing free() calls yet, but at least assignments and type conversions are working now and I see no memory segmentation violation or garbage data in return values anymore. Thanks... -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
