Hi all, I was recently asked to chat with a few people about the Ruby support in Tuscany, so I spent a bit of time looking at the support we provide in both the C++ and Java sides of Tuscany. There are a few differences that, in the absence of a spec, we should try to fix up so that we've at least got a consistent Tuscany story. (I'm not saying these are worth holding back M2 for - just thought I'd document them so we can get some discussion going).
1) implementation.rb element in SCDL. In Tuscany Java, a component is defined like: <component name="HelloWorldComponent"> <rb:implementation.rb script="HelloWorld.rb" class="Helloworld" xmlns:rb="http://tuscany.apache.org/xmlns/rb/1.0"/> </component> Whereas, in Tuscany C++ it is: <component name="HelloWorldComponent"> <implementation.ruby script="HelloWorld.rb" class="Helloworld"/> </component> These are pretty similar aside from the element name (implementation.rb vs. implementation.ruby) and the fact that Java have their own namespace whereas C++ use the SCA namespace http://www.osoa.org/xmlns/sca/1.0 namespace. My own preference is implementation.ruby and a tuscany namespace (http://tuscany.apache.org/xmlns/ruby/1.0 or similar). I couldn't find a schema for Java's implementation.rb, C++'s is at http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/xsd/sca-implementation-ruby.xsd The C++ schema doesn't actually include the script attribute used above (preferring module instead) - script is supported in the implementation. We should decide on a single schema for the implementation.ruby element. 2) Interface definitions Tuscany Java requires a WSDL or Java interface to be specified for a Ruby component via a componentType file or in a $SCA variable in the Ruby script, e.g: $SCA = { 'javaInterface' => 'helloworld.HelloWorldService' } Tuscany C++ does not require any interface specification, instead attempting to invoke a specified method but failing if the method name does not exist or the wrong number of parameters are supplied. I remember that there are currently restrictions in the Java runtime that mean an interface is required, but it would be cool if we didn't force Ruby scripters to write that Java or WSDL interface. C++ should support the use of a WSDL interface to allow Ruby components to be remotable. Perhaps we need a Ruby2WSDL tool that could work via annotations or the $SCA variable? 3) Ruby Client API I don't think Tuscany Java has a client API for Ruby. In C++ there is a client API library that matches the C++ client API, so that the SCA runtime can be loaded and invoked from a Ruby script as follows: require("tuscany_sca_ruby") hello = SCA::locateService("HelloWorldComponent") x = hello.sayHello("Everyone") print x, "\n" Should we create a Java version of this API so that Java components can be called from Ruby, etc? 4) Data type support Tuscany C++ maps the basic C++ data types to the Ruby int, float, boolean, string, etc internal types. SDO is also supported via a conversion to a REXML Document object. Other types will currently cause an exception to be thrown. Tuscany Java uses the JRuby conversion facilities to convert any Java object (including the Java basic types) to the correct Ruby type. I think SDOs (and other user-defined Java objects) are available inside the Ruby script via the JRuby JavaProxy (which dynamically maps a Java object to a Ruby object), so an SDO object inside Ruby is actually a real Java SDO object. We should probably have the data type conversions documented somewhere so people understand what gets mapped to what and what data types are supported. On the subject of a spec, do people think OSOA.org should be working on C&I specs for Ruby and scripting languages in general? The SCA for PHP folk have some documentation, but don't really talk about specifications on the PHP mailing lists as it tends to be a turn-off for the PHP community, who (IMO) like things to be a bit looser and free-flowing. What do people think? Cheers Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]