XINS is a technology used to define, create and invoke remote APIs. XINS is specification-oriented. API specifications written in XML are transformed by XINS into HTML-based documentation and Java code for both the client- and the server-side. The communication is based on HTTP.

XINS competes with the more complex W3C web services technologies (e.g. SOAP, WSDL). Main design goals include simplicity, scalability and testability.

New features in release 1.2.0 include a run target to run the API, API version, custom calling convention, XSLT calling convention, Windows installer and various other improvements as well as bug fixes.

For more information visit the XINS home page, read the user guide and have a look at the demonstration page.

XINS is published under the BSD License.

What do you think? There's been a decent amount of discussion lately about the possibility of revamping SOAP, WSDL, and potentially UDDI into simpler or more flexible mechanisms. Is XINS' model useful when considering possible changes to the way web services are done?

I have taken a quick look into this API and it looks nice. It is clean and simple to use.

The XML is for once very easy to understand and to make.

I think I will make use of it where the Architecture of the Application lets me.

Marc, we would be more than willing to support you. If you have any questions, please use the mailing list.

--
Ernst de Haan
XINS developer

is there support for other languages already? we'd be interested in looking at it if we could use it to link apps on one network written in perl with apps on another network using java.

is there support for other languages already? we'd be interested in looking at it if we could use it to link apps on one network written in perl with apps on another network using java.

You have, with the release, examples on how to call an API using perl, php4, php5 and Javascript/AJAX. Just look in the demo/capis directory.

If you want to implement you API using perl, the format has been kept simple so that it's still easy in perl to parse the URL arguments and return the simple XML result.
At my work, we have several APIs implemented in perl that we call using Java. We even use the generated capi .jar file.

I don't understand all the web service alternatives that only provide security at the ssl layer.

A lot of customers that want web services are big organizations that really need the type of flexibility and integration that ws provides. They also want security-more than just ssl between 2 computers.

You would think more people would be focusing on pki or message level security solutions as opposed to another web service solution with minimal security.

I don't understand all the web service alternatives that only provide security at the ssl layer.

The security is not provided only at the ssl layer.
The main security is done by association of the ACLs with the functions. Then if you want more security HTTPS support has been added.
User Guide: http://xins.sourceforge.net/docs/ar01s14.html

The security is not provided only at the ssl layer.The main security is done by association of the ACLs with the functions. Then if you want more security HTTPS support has been added.User Guide: http://xins.sourceforge.net/docs/ar01s14.html

Yes I saw that and that does help, but Ip's can be spoofed relatively easily. I think it helps to simplify web services, but banks, govt and others want pki and message level security.

I'd like to use XINS but my requirements are for message level security. Maybe I need a different customer ;)