After 2 years of development, there is now a BSD-licensed web services technology that competes with the allegedly overcomplex Microsoft SOAP technology: XINS. XINS is heavily based on Java and XML. Main design goals include simplicity, scalability and testability. Features include transaction logging, log documentation, and automatic generation of HTML docs, test forms, client-side and server-side code. A comprehensive user guide is available.
XINS 1.0.0 released
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
Not a standard… forget it!
And we already have XML/RPC for simple tasks.
While Microsoft did have a lot of influence in the design of the protocol, it is by no means their technology.
Didn’t Sun have a lot to do with it as well?
If you want a simple implementaion of SOAP use Perls SOAP::Lite
We had CGI AGES-ago for simple tasks. Hell, i’d wager its quite usable for not-so simple tasks too. I see no reason to overcomplicate things with SOAP or xml-rpc. Although XML-rpc is far better, comparatively.
Insert obligatory REST wiki and Roy Fielding’s flaming SOAP links here. To think I just chastized someone yesterday for being too lazy to link.
SOAP falls into the category of a technology – that appear useful on paper – but isn’t so great in use.
About the only practical thing that SOAP has over XML-RPC is custom data-types. But really, how often does the standard web app need anything other than strings, ints, etc?
I truely think that SOAP falls victim to ‘design by committee’ syndrome, where it winds up so over-engineered (ie Java’s obtuse API’s come to mind), that developers cringe slightly at using it.
TraxTech wrote:
> Not a standard… forget it!
XINS is not an official standard. However, it is developed in a way that it is sufficiently generic to become one. It has been thought over very well.
> And we already have XML/RPC for simple tasks.
Indeed XML/RPC was a nice standard (?) at the time. However, it has some serious flaws. For example, it only supports a very limited set of data types.
One half of XINS can be compared to XML/RPC. And that’s the specification part. There are big differences here, though. XML/RPC does not have an external format specification and it encodes the datatypes (metadata) in the request and response.
XINS does not do that, metadata is not included in the call. The metadata is in the specification, which is used to generate client- and server-side code from, along with HTML documentation and test-forms. Then when a request is received, the server-side generated code validates it, based on the specification. Vice versa, the client-side generated code validates the received output.
— Ernst de Haan (XINS developer)
> SOAP falls into the category of a technology – that
> appear useful on paper – but isn’t so great in use.
Everybody that I met that used SOAP in practice on real-world project told me the very same thing. And even if one would ‘only’ read the specifications (SOAP, WSDL, UDDI, Basic Profile, etc.) it becomes obvious that this technology is very complex.
And in my opinion, things should not have to be like that. Web services should be really easy and straight-forward to design, develop, document and deploy.
> About the only practical thing that SOAP has over
> XML-RPC is custom data-types. But really, how often does
> the standard web app need anything other than strings,
> ints, etc?
In my experience, quite often. If you have any type of API (e.g. to a billing system, to LDAP, to a single-signon system, etc.) you normally want to check that what is in the request is legitimate. It should have a fair chance of being accepted by the back-end.
> I truely think that SOAP falls victim to ‘design by
> committee’ syndrome, where it winds up so
> over-engineered (ie Java’s obtuse API’s come to mind),
> that developers cringe slightly at using it.
Let me know whether you think the same thing applies to XINS. In my opinion and experience it does not, since it is designed to be as simple as it gets. If you find any room for improvement, let us know.
“Perfection is not in adding features until there is nothing left to add, but in removing until there is nothing left to remove.”
— Ernst de Haan (XINS developer)
> If you want a simple implementaion of SOAP use Perls
> SOAP::Lite
The problem that remains is that the technology itself is flawed in terms of complexity. I’m not looking for a simple implementation of SOAP, I was looking for a simple technology to develop web services with. And since it did not exist, we created it.
Note that if you want to find something that comes close to what XINS is, it’s not SOAP, but XML/RPC. Although XML/RPC is functionally flawed (it lacks some important features) it was the right direction, in my opinion. When they developed SOAP, Microsoft just took XML/RPC and created a bloated monster from it.
— Ernst de Haan (XINS developer)
Any plans to port it to…let’s say PHP?
I’m all for someone taking another stab at fixing the bloated monster that is “web services”. For those who claim XINS is not a standard, standards are only as good as the [inverse proportion] of the trouble it takes to implement and use them. For most developers, existing SOAP standards are too much trouble to even bother with.
But, I find it kind of ironic that a Java-based technology would have a BSD license, considering what a pain it is to get Java working on *BSD systems. (Not, I might add, through any fault in BSDs, but because Sun has not treated BSD as well as it’s protege Linux)
Of course, if the protocol proves useful in any way, it will be quickly ported to PHP, Python, Perl, etc…
huh? worked fine here.
Sun loves BSD, some of their founders helped form BSD Unix. They are just kept up in competition with linux nowadays. A Large portion of solaris is under the bsd license.
-peace
Can anyone more experienced that me explain why and when you’d choose SOAP/XML-RPC/XINS over simple REST?
> Any plans to port it to…let’s say PHP?
XINS is both a specification technology and an application framework. In fact we have implemented some APIs with PHP. So in such cases, we use XINS only as a specification technology.
Also, we are currently planning the development of a Perl-based XINS API.
The advantage of using Java is that you get a lot of features for free, like a build framework, transaction logging, diagnostic context IDs, automatic example (passive) code generation, automatic validation (active) code generation, automatically reloaded runtime properties, etc.
— Ernst de Haan (XINS developer)
> But, I find it kind of ironic that a Java-based technology would
> have a BSD license, considering what a pain it is to get Java
> working on *BSD systems. (Not, I might add, through any fault in
> BSDs, but because Sun has not treated BSD as well as it’s protege
> Linux)
That was true 2 years ago, but a lot of work has been done since, and Java is in my opinion currently working fine, at least on FreeBSD. Led by Greg Lewis, the Java porting team has really lived up to its promise. Also, Herve Quiroz, myself and some others have IMHO greatly improved the Java ports system on FreeBSD.
— Ernst de Haan (XINS developer and FreeBSD committer)
> Of course, if the protocol proves useful in any way, it will be
> quickly ported to PHP, Python, Perl, etc…
For the client-side we are indeed considering porting to C, Perl and PHP.
In fact, a call to a XINS API is just an HTTP GET or POST request. However, the XINS/Java Client Framework has additional features, like load-balancing, fail-over, automatic sending of diagnostic context identifiers, etc.
Then additionally -on top of the client framework- code generation is implemented for Java. The generated code has a one-to-one relationship with the specification. For an example see this specification:
http://xins.sourceforge.net/demo/specdocs/
and then here the Javadoc for the generated client-side code:
http://xins.sourceforge.net/demo/javadoc-capi/myproject/
So a ‘port’ to another language can be done in these stages:
Stage 1) Send an HTTP GET/POST request and interpret the XML manually in the custom code;
Stage 2) Support diagnostic context identifiers, load-balancing and fail-over;
Stage 3) Support active code generation.
Or is this, for the moment, a pure Java based technology?
Indeed XINS web services can be made with PHP. And we have indeed done this. But then XINS is used only as a specification technology. Specifications are written in XML and then only HTML docs, test forms and client-side Java code is generated. No server-side code.
The PHP application will just need to accept the parameters as specified in the API specification (per function) and then return an XML document as described in that same specification.
I developped a code generator (private project) that takes XML on its input (comparable to an oversimplified WSDL) and it generates client and server side C++ SOAP code (thanks to a forked easysoap) + API doc (in Pdf, thanks to FOP) + WSDL.
With this solution, everyone is happy : less code, interoperable, always up-to-date meta doc. And i could use a subset of the XML metadescription to generate XML/RPC (using ulxmlrpcpp for example), it’s technically easy
The good way, i think, is a good metadescription XML, and generator for almost any web services (SOAP, XML/RPC, custom RPC over XMPP…XINS ;-)).
TraxTech wrote:
> The good way, i think, is a good metadescription XML, and
> generator for almost any web services (SOAP, XML/RPC,
> custom RPC over XMPP…XINS ;-)).
For XINS 1.2, compatibility with SOAP and XML/RPC is planned. In fact, we plan to support any kind of input/output, combined with any kind of validation technology, e.g. XML Schemas, RelaxNG, DTD validation, etc. See:
http://xins.sourceforge.net/roadmap.html
And for more detail:
http://xins.sourceforge.net/todos.html
We intend to implement this using XSLT.
TraxTech: Since you have experience in this field, a review of the XINS specification format and the code generation would be highly appreciated!
SOAP could be complex, but it’s not Microsoft, it’s W3C technology…
> SOAP could be complex, but it’s not Microsoft, it’s W3C
> technology…
SOAP has been developed by Microsoft and then submitted to the W3C for approval. From that point on W3C took over.
That was true 2 years ago, but a lot of work has been done since, and Java is in my opinion currently working fine, at least on FreeBSD. Led by Greg Lewis, the Java porting team has really lived up to its promise. Also, Herve Quiroz, myself and some others have IMHO greatly improved the Java ports system on FreeBSD.
I understand, and I appreciate the contributions (as a dedicated FreeBSD user). I have Java working just fine on my FreeBSD system. Unfortunately, as I understand it, one still cannot simply install a binary package for the latest Java, as one can with Linux. And, one still cannot simply go to /usr/ports/java/jdk14 and just type “make install”. Thus, to install Java is a mind-numbing afternoon of deciphering Sun’s cryptic Java download links hoping one downloaded the right version of the Java source, first installing the Linux version, bootstrapping to make the FreeBSD version from source (and don’t forget the latest FreeBSD patchset). When I first did this, it took me 3 tries, and in fact in FreeBSD 4.9, I never could get it to work, because the compile process would freeze at a certain point, with 99% processor load into infinity. (I left it for a whole weekend doing that just to make sure). Managed it with 5.x, but it still took a whole day of compiling.
Or have things changed since last time I did this? (believe me, I would be overjoyed) And again, I am not placing any jabs at the FreeBSD developer community, who do an outstanding job, but just frustrated at the politics of the whole thing.
And @Tim Hawkins, yes, I understand that BSD has a place in history right alongside Sun, etc… but then why on Earth and the solar system isn’t there a nice FreeBSD package download for the JDK at java.sun.com, right alongside the Windows and Linux versions? Just asking…
You are right. There is still a lot of hassle involved in installing Java on FreeBSD. Indeed you need to manually download the Sun JDK 1.4 for Linux in order to install the native JDK 1.4. However, 2 years ago the native JDK was quite unstable and performance was just plain sad. The stability has greatly improved and the performance has also improved slightly.
Personally I have given up on Java on FreeBSD. It’s not performing well and the stability is not as good as Linux. I’m now using Gentoo Linux at the office workstation. And it’s much more efficient and performant. I think the performance improvement was around 100%.
So although I like the architecture of FreeBSD much more than I like the architecture of Linux, still Linux is the more practical alternative…
But perhaps things will change when FreeBSD 5.x becomes stable, I don’t know.