XINS can easily be integrated with the Spring Framework.

XINS generates POJO's for requests and result on the client and server side. The classes and the methods are public so that they can be called from another package. The generated POJO's try to follow the Java Beans specification as much as possible.

For example, if you want to use Spring AOP transaction for a specific API, you can define as point cut all methods starting with call in the generated CAPI class.

On the server side, XINS is a Servlet so you can use it with org.springframework.web.servlet.*.

XINS also includes a Spring framework package. The package is located in org.xins.common.spring (javadoc). This package is adding a few convinient classes for validation, factory bean and client interceptor.

The Dojo toolkit has several ways to communicate with the server.

One of it is JSON-RPC (dojo.rpc.JsonService) which is also supported by XINS on the server side with the _xins-jsonrpc calling convention. The easiest way to use this JsonService is in combinaison with a SMD (Simple Method Description). SMD is a file which describes the name of the methods of the API with the expected parameters. There are two ways to get this file from XINS. Either execute the xins smd command that will generate the file build\smd\<api name>.smd or by calling the meta function _SMD to the API you want to invoke. An example is provided in demo\capis\javascript\callMyFunctionDojo.html.

You can also use dojo.rpc.YahooService where calls will be received by the _xins-json calling convention. This service is also able to read and interpret the SMD file.

GWT has mostly two ways to communicate with a server. They first have their own RPC system. GWT also facilitates the call to APIs using the Yahoo JSON protocol which matches the _xins-json calling convention.

An example is provided at http://gwt.google.com/samples/JSON/JSON.html.

Note that XINS also supports the callback parameter which is use to indicate to the call which method should be called with the output parameter when the response returns.

The others (than Dojo and GWT) AJAX frameworks are also supported.

They have different ways to call XINS. They can use the _xins-json or _xins-jsonrpc calling conventions but also the _xins-std and parse the returned XML themselve or use the _xins-xslt calling convention in combination with an XSLT stylesheet that transform the XML in the HTML to insert dynamiccally in the page.

Several examples of the later are provided in the demo\capis\javascript directory.

Mule is the most popular open source Entreprise Service Bus (ESB).

As XINS is a Servlet, you can register a handler on the URI (embedded Jetty), or bind through an existing web container (servlet endpoint).

Documentation can be found in the org.mule.providers.http.jetty package or in the org.mule.providers.http.servlet package.

Most of modern ESB support the possibility to plug JavaEE servers to it and as part of the JavaEE specification there is the possibility to deploy and run Servlet, there shouldn't be any problem to install XINS APIs in an ESB and/or JavaEE server.

The main problem can only be to indicate where find the runtime properties file, as it is normally done using the org.xins.server.config system property. If you cannot set this property, you can also include the runtime property file to use in the WAR file as WEB-INF/xins.properties. Use the <content dir="<path>" includes="xins.properties" web-path="WEB-INF" /> element in impl.xml file.

Orchestration is also an important feature in ESB. It can be done using WS-BPEL as XINS APIs can communicate using SOAP with the _xins-soap calling convention. The API can also give the WSDL file to indicate the SOAP message format with the _WSDL meta function.

XINS uses Ant to generate the different files. It is also possible to run the tests or the API with Ant targets. The easiest way to do it is to use the xins task as described in the the section called “xins task”.

Another possibility is to look at the nbbuild.xml file included with the petstore demo and can be used for other existing APIs or new APIs. Note that some of the targets are NetBeans specific but most of them not.

XINS also has support for Maven 2.

Each stable releases are added in the Maven 2 repository (http://www.ibiblio.org/maven/org.xins/). Note that not only the jar files are included, the source code and the Javadoc are also included.

If you want to build your API using API using Maven, you can execute xins maven command which will create the <api name>.pom in the apis\<api name> directory. Note that the external dependencies (other than XINS) are not included in the generated POM and you should add them manually.

On the client side it is possible to either call the standard calling convention or use a standard protocol such as SOAP or XML-RPC.

As the standard calling convention is simple, it should be easy to write a script that creates a URL, send it and parses the XML response returned.

Some of the script also have libraries to call a server by using SOAP or XML-RPC. XML-RPC clients are listed at http://www.xmlrpc.com/directory/1568/implementations.

Examples with different script are provided in the demo\capis directory.

You can also implement an API using a script language. In this case you need to use a library to pass the input parameters to the script and get the output parameters from the script. An example is provided in XINS using Groovy as script language in the demo\xins-project\apis\toolbox directory.

Since XINS 2.3, a new command xins appengine allow to package the API and deploy it on the Google App Engine.

You will need to specify the location of the appengine SDK with the appengine.sdk.dir property.

The Google App Engine requires a appengine-web.xml in the WEB-INF directory. If you don't have one XINS will create one for you (in build/webapps/<api name>/war/WEB-INF). You may need to change the application name and version (. and _ are not accepted in version). Another possibility is to set appengine.api.name and appengine.api.version build properties.

Also as there is no runtime properties, the file specified in the org.xins.server.config build property will be used.