XML Interface for Network Services

The specification-oriented approach is at the heart of XINS:

• first specifications need to be written;
• then documentation and code is generated from these specifications;
• then both testing and implementation can start.

From specifications, XINS is able to generate:

• HTML documentation
• test forms
• SOAP-compliant WSDL
• a basic Java web application
• unit test code (in Java)
• stubs (in Java)
• client-side code (in Java)

Technically, XINS is composed of the following:

• An XML-based specification format for projects, APIs, functions, types and error codes
• A POX-style RPC protocol (called the XINS Standard Calling Convention), compatible with web browsers (HTTP parameters in, XML out).
• A tool for generating human-readable documentation, from the specifications.
• A tool for generating WSDL, from the specifications.
• A Log4J-based technology for logging (called Logdoc), offering a specification format, internationalization of log messages, generation of HTML documentation and generation of code.
• A Java library for calling XINS functions, the XINS/Java Client Framework; in xins-client.jar.
• A server-side container for Java-based XINS API implementations, the XINS/Java Server Framework; in xins-server.jar. This is like a servlet container for XINS APIs.
• A Java library with some common functionality, used by both the XINS/Java Client Framework and the XINS/Java Server Framework: the XINS/Java Common Library, in xins-common.jar.

An introductory tutorial called the XINS Primer takes the reader by the hand with easy-to-follow steps to perform, with screenshots.

Since version 1.3.0, the XINS/Java Server Framework supports not only POX-style calls, but also SOAP and XML-RPC. And it supports conversion using XSLT. As of version 2.0, it also supports JSON and JSON-RPC.

XINS is open-source and is distributed under the liberal BSD license.

All XINS specification files are Plain Old XML. Compared to SOAP/WSDL/UDDI/etc. the format is extremely simple. There are specifications for projects, environment lists, APIs, functions, types and error codes.

Below is an example of a XINS project definition.

<project name="MyProject" domain="com.mycompany">
  <api name="MyAPI">
    <impl/>
    <environments/>
  </api>
</project>

Here is an example of a specification of an environment list:

<environments>
  <environment id="netarray" url="http://xins.users.mcs2.netarray.com/myproject/xins/"/>
</environments>

An example of an API specification file:

<api name="MyAPI">
  <description>My first XINS API</description>
  <function name="Hello"/>
</api>

An example of a function definition:

<function name="Hello">
  <description>Greets the indicated person.</description>
  <input>
    <param name="name" required="true">
      <description>The name of the person to be greeted.</description>
    </param>
  </input>
  <output>
    <param name="greeting" required="true">
      <description>The constructed greeting.</description>
    </param>
  </output>
</function>

The XINS Standard Calling Convention is a simple HTTP-based RPC protocol. Input consists of HTTP parameters, while output is an XML document. This approach makes it compatible with plain Web browsers.

Example of a request:

http://somehost/someapi/?_convention=_xins-std&_function=SayHello&firstName=John&lastName=Doe%5B%5D

Example of a successful response:

<result>
   <param name="greeting">Hello John Doe!</param>
</result>

There are no known products that provide an integrated approach to specification-oriented development, similar to XINS. However, there are several frameworks and libraries that provide functionality similar to individual parts of XINS, including:

• JWSDP: Collection of various XML and SOAP technologies for the Java programming language.
• Apache Axis: Java-based framework for SOAP implementations.
• Codehaus XFire: Idem.
• Hessian Web Service Protocol: Binary alternative to the XINS Standard Calling Convention.

• XINS website
• Frequently Asked Questions