<implementation.script>

Tuscany supports SCA components implemented in a wide variety of dynamic or scripting languages by using the <implementation.script> SCDL extension.

Any language that supports the "Scripting for Java" APIs defined by JSR-223 is supported, this includes Groovy, JavaScript, JRuby, Jython, and many others.

To use these languages the SCA assembly SCDL is extended with an "implementation.script" element which has the following options:

   <implementation.script [ script="" | language="" ] >
     [inline src]
</implementation.script>

The source code for the script may be defined in a seperate file pointed to by the 'script=' attribute, or the source code maybe embedded within the SCDL inline inside the <implementation.script> element.

The 'language=' attribute defines the language of the program. The language attribute is optional when the source code is in a separate file in which case the file extension of the file is used to determine the language.

Some examples:

A Ruby program defined in a file 'myScript.rb' in a folder named 'test':

   <implementation.script script="test/myScript.rb"/>

A JavaScript program defined inline:

   <implementation.script language="js">
      function sayHello(name) {
         return "Hello " + name;
      }
</implementation.script>

When using inline scripts which contain special characters such as XML markup you may need to enclose the source within a CDATA region, for example:

   <implementation.script language="js"><![CDATA[
      function sayHello(inXML) {
         return <sayHelloResponse>Hello { inXML..name }</sayHelloResponse>;
      }
]]></implementation.script>

The previous example demonstrated using JavaScript's E4X language extension for manipulating XML. Many dynamic languages have enhanced XML capabilities like this which can make working with XML much easier than in a more traditional language such as Java. For example, along with JavaScript's E4X, Ruby has ReXML and Groovy has its markup builders.

Tuscany tries to simplify this for the script program developer and will try to automatically ensure arguments are in the native XML format of the language when the component is wired to a WSDL interface.

As an example of this the following shows a composite that can replace the Tuscany helloworld-ws-service sample and requires no other files other than the asscociated WSDL document packaged with the contribution:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
        xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
	targetNamespace="http://helloworld"
        name="helloworldws">

    <service name="HelloWorldService" promote="HelloWorldServiceComponent">
       <interface.wsdl interface="http://helloworld#wsdl.interface(HelloWorld)" />
       <binding.ws/>
    </service>

    <component name="HelloWorldServiceComponent">
        <tuscany:implementation.script language="js"><![CDATA[

           function getGreetings(xmlIn) {
              return <ns1:getGreetingsResponse xmlns:ns1="http://helloworld">
                        <ns1:getGreetingsReturn>Hello { xmlIn..*::name.toString() }</ns1:getGreetingsReturn>
                     </ns1:getGreetingsResponse>
           }

        ]]></tuscany:implementation.script>
    </component>

</composite>

Best practice? Using inline scripts can make creating simple components very easy however there are issues around whether or not this is best practice. Depending on the circumstance consideration should be given as to if it would be better to define the script in a seperate file.