Scripting Executor

Dynamic Language Tasks feature has been extended and now supports Scala based script execution.

Configuration

Here is how you would configure a processing unit This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity. to run a scripting executor with scala support and use it from a client proxy. For detailed information on the Scripting Executor framework, see Dynamic Language Tasks.

Processing Unit Configuration

<os-core:embedded-space id="space" space-name="mySpace"/>

<os-core:giga-space id="gigaSpace" space="space"/>

<bean id="scriptingExecutorImpl" class="org.openspaces.remoting.scripting.DefaultScriptingExecutor">
  <property name="executors">
    <map>
      <entry key="scala">
    <bean class="org.openspaces.remoting.scripting.ScalaLocalScriptExecutor">
    </bean>
      </entry>
    </map>
  </property>
</bean>

<os-remoting:service-exporter id="serviceExporter">
  <os-remoting:service ref="scriptingExecutorImpl"/>
</os-remoting:service-exporter>

<os-events:polling-container id="remotingContainer" giga-space="gigaSpace">
  <os-events:listener ref="serviceExporter"/>
</os-events:polling-container>

Client Side Configuration

<os-core:space-proxy  id="space" space-name="mySpace"/>

<os-core:giga-space id="gigaSpace" space="space"/>

<os-remoting:executor-proxy id="executorScriptingExecutor" giga-space="gigaSpace"
    interface="org.openspaces.remoting.scripting.ScriptingExecutor">
  <os-remoting:aspect>
    <bean class="org.openspaces.remoting.scripting.LazyLoadingRemoteInvocationAspect" />
  </os-remoting:aspect>
  <os-remoting:routing The mechanism that is in charge of routing the objects into and out of the corresponding partitions. The routing is based on a designated attribute inside the objects that are written to the Space, called the Routing Index.-handler>
    <bean class="org.openspaces.remoting.scripting.ScriptingRemoteRoutingHandler" />
  </os-remoting:routing-handler>
  <os-remoting:meta-arguments-handler>
    <bean class="org.openspaces.remoting.scripting.ScriptingMetaArgumentsHandler" />
  </os-remoting:meta-arguments-handler>
</os-remoting:executor-proxy>

Usage

3 new Script implementations have been added to support compilation and caching of compiled scala scripts. These provide the ability to explicitly set the static type for script parameters which is required when the runtime type is not public. In most cases, there is no need to define these as they can be deduced to use the parameter runtime type.

• org.openspaces.remoting.scripting.ScalaTypedStaticScript which extends StaticScript.
• org.openspaces.remoting.scripting.ScalaTypedStaticResourceScript which extends StaticResourceScript.
• org.openspaces.remoting.scripting.ScalaTypedResourceLazyLoadingScript which extends ResourceLazyLoadingScript.

Example

Import org.openspaces.remoting.scripting.ScalaTypedStaticScript into scope to use the methods demonstrated below.

val code = """
val readData: Any = gigaSpace.read(null)
val numberAsString = someNumber.toString
val setAsString = someSet.toString
numberAsString + " " + someString + " " + setAsString + " " + readData
"""

val script = new ScalaTypedStaticScript("myScript", "scala", code)
  .parameter("someNumber", 1)
  .parameter("someString", "str")
  // explicit type is requierd because the runtime type of the generated
  // set is not public
  .parameter("someSet", Set(1,2,3), classOf[Set[_]])

val result = executor.execute(script)

println("Script execution result: " + result)