Using Dynamic Languages to Implement Services

Overview

JavaScript, also known by its formal name ECMAScript, is one of the many dynamic languages that are growing in prevalence in development environments. It provides a quick and lightweight means of creating functionality that can be run on a number of platforms. Another strength of JavaScript is that applications can be quickly rewritten.

Celtix provides support for developing services using JavaScript and ECMAScript for XML(E4X). The pattern used to develop these services are similar to JAX-WS Providerimplementations that handle their requests and responses (either SOAP messages or SOAP payloads) as DOM documents.

Implementing a Service in JavaScript

Writing a service in JavaScript is a two step process:

1. Definethe JAX-WS style metadata.
2. Implementthe services business logic.

Defining the Metadata

Normal Java providers typically use Java annotations to specify JAX-WS metadata. Since JavaScript does not support annotations, you use ordinary JavaScript variables to specify metadata for JavaScript implementations. Celtix treats any JavaScript variable in your code whose name equals or begins withWebServiceProvideras a JAX-WS metadata variable.

Properties of the variable are expected to specify the same metadata that the JAX-WS WebServiceProviderannotation specifies, including:

• wsdlLocationspecifies a URL for the WSDL defining the service.
• serviceNamespecifies the name of the service.
• portNamespecifies the service's port/interface name.
• targetNamespacespecifies the target namespace of the service.

The JavaScript WebServiceProvidercan also specify the following optional properties:

• ServiceModeindicates whether the specified service handles SOAP payload documents or full SOAP message documents. This property mimics the JAX-WS ServiceModeannotation. The default value is PAYLOAD.
• BindingModeindicates the service binding ID URL. The default is the SOAP 1.1/HTTP binding.
• EndpointAddressindicates the URL consumer applications use to communicate with this service. The property is optional but has no default.

Example 1 shows a metadata description for a JavaScript service implementation.

Implementing the Service Logic

You implement the service's logic using the requiredinvokeproperty of the WebServiceProvidervariable. This variable is a function that accepts one input argument, a javax.xml.transform.dom.DOMSourcenode, and returns a document of the same type. The invokefunction can manipulate either the input or output documents using the regular Java DOMSourceclass interface just as a Java application would.

Example 2 shows an invokeproperty for a simple JavaScript service implementation.

Implementing a Service in ECMAScript for XML(E4X)

Writing a Celtix service using E4X is very similar to writing a service using JavaScript. You define the JAX-WS metadata using the same WebServiceProvidervariable in JavaScript. You also implement the service's logic in theWebServiceProvidervariable's invokeproperty.

The only difference between the two approaches is the type of document the implementation manipulates. When working with E4X, the implementation receives requests as an E4X XML document and returns a document of the same type. These documents are manipulated using built-in E4X XML features.

Example 3 shows an invokeproperty for a simple E4X service implementation.

Deploying Scripted Services

Celtix provides a lightweight container that allows you to deploy your Javascript and E4X services and take advantage of Celtix's pluggable transport infrastructure.Note:Script based services can work with SOAP messages. So, while they are multi-transport, they can only use the SOAP binding.
You deploy them into the container using the following command:java org.objectweb.celtix.js.rhino.ServerApp -aaddressURL -bbaseAddressURLfile.js file2.jsfile3.jsx ...
The org.objectweb.celtix.js.rhino.ServerAppclass, shorted to ServerAppbelow, takes one or more Javascript files, suffixed with a .js, or E4X files, suffixed with a .jsx, and loads them into the Celtix runtime. If ServerApplocates JAX-WS metadata in the files it creates and registers a JAX-WS Provider<DOMSource>object for each service. The Provider<DOMSource>object delegates the processing of requests to the implementation stored in the associated file. ServerAppcan also take the name of a directory containing Javascript and E4X files. It will load all of the scripts that contain JAX-WS metadata, load them, and publish a service endpoint for each one.

ServerApphas three optional arguments:
ArgumentDescription| -aaddressURL | Specifies the address at which ServerApppublishes the service endpoint implementation found in the script file following the URL. |

Table 1.: Optional Arguments

The optional arguments take precedence over any addressing information provided in EndpointAddressproperties that appear in the JAX-WS metadata.

For example, if you deployed a Javascript service using the command shown in Example 4, your service would be deployed at http://celtix.objectweb.org/goodness.

To deploy a number of services using a common base URL you could use the command shown in Example 5. If the service defined by hello_world.jsxhad port name of helloWorld,ServerAppwould publish it at http://celtix.objectweb.org/helloWorld. If the service defined by goodbye_moon.jshad a port name of blue,ServerAppwould publish at http://celtix.objectweb.org/blue.

You can also combine the arguments as shown in Example 6., your service would be deployed athttp://celtix.objectweb.org/goodness. ServerApp would publish three service endpoints:

• The service defined by hello_world.jsxat http://celtix.objectweb.org/helloWorld.
• The service defined by goodbye_moon.jsat http://celtix.objectweb.org/blue.
• The service defined by chocolate.jsxat http://celtix.objectweb.org/goodness.