XINS is based on several standard such as POJO, Servlet API, SOAP, REST or Ant which eases the integration with other frameworks.
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
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
name>.smd or by calling the meta function
_SMD to the API you want to invoke. An example is
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.
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
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
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).
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
includes="xins.properties" web-path="WEB-INF" /> element in
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
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
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
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 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
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.version build properties.
Also as there is no runtime properties, the file specified in the
org.xins.server.config build property will be