RSS

Category Archives: xins

Judging XINS: The Good, the Bad and the Ugly

Looking Back

Back in 2002 or 2003, while working at an internet service provider (Wanadoo Netherlands, now called Online), we were constantly integrating frontend applications created by one team with backend applications created by another. To improve integration, our development team created a technology that would evolve into the contract-first development tool now known as XINS. It worked like a charm for the people involved (architects, developers, IT opeations, management and testers), getting nothing but praise.

But that is a while ago, and the landscape has changed; so how does XINS fare after about 8 years? Looking back, what is arguably good, bad and ugly about it?

The Good

  • The contract first approach really pays off in terms of quality and productivity. Once the contract is agreed upon by the involved developers and/or development teams, there’s suddenly a lot less room for discussion. And it’s fail fast; the contract is validated at both sides (client and server). This approach makes XINS unique and a real productivity monster. Developers are able to focus on the actual implementation code and hardly have to deal with after-the-implementation-discussions on integration issues;
  • Strong operational excellence (like failover, load balancing, error handling, logging, etc.) increases productivity and improves overall quality of these aspects. Part of the functionality is built into the framework, the rest is generated from the specifications.
  • From specifications, test forms can be generated. This is not only great for developers testing their own stuff, but also for other development teams, for testers and operations. It’s easy to peek at XINS-based applications.
  • Performance has always been very good, with automated performance tests in place to detect regressions. The overhead of the XINS runtime is typically less than a millisecond.
  • As long as it goes over HTTP, XINS supports various transport protocols, like JSON, XML-RPC, SOAP and the default: a simple browser-friendly protocol (HTTP GET/POST in, XML out).

The Bad

  • XINS still uses DTDs for validation of the specification files, instead of using the much more powerful XML Schema standard (or even RelaxNG).
  • The XML-based specification files use custom file name extensions, like .fnc, for function definitions, .typ for types, etc. This typically confuses editors and disables syntax highlighting.
  • Unit testing of function implementation classes is hard, they they require generated code (their superclasses). Nowadays, such classes would normally be POJOs.
  • The default protocol has some quirks: e.g. it requires XML support in the browser (which Safari does not offer), it is impossible to send empty strings (because these are interpreted as nulls) and errors are returned using the 200 OK status, which is not in accordance with the HTML spec, etc.
  • XINS 2.3 still uses various non-standard data type classes; this will be fixed in XINS 3.0. Examples of such data types include the PropertyReader (will become Map<String,String> in XINS 3) and the Element class (XINS 3 will use the W3C DOM API instead).

The Ugly

  • XINS tries to be too much at once; it not only generates stuff (code, documentation and test forms), but it also compiles compiles Java code, generates Javadoc, produces a WAR file, enforces an approach to application configurations, etc.
  • As a tool, XINS does not fit in well in the current ecosystem of (Java) build tools and IDEs. It has its own source directory structure, it has its own build system, it does not integrate directly with Maven, etc.
  • All transport protocols are supported, as long as it is HTTP. Local calls are supported, but then everything needs to be wrapped in HttpServletRequest and HttpServletResponse objects. Especially for binary data, this introduces a lot of overhead: binary data is converted to an inefficient format (Base64 or hex), transported in the inefficient format (overhead!) and then converted back to the binary format. Note that this involves storing the data in memory (more than) twice on the server side!
  • XINS hardly evolves: the community is minimal and development is slow.

Crowning the Successor

Overall, XINS is a productivity monster that addresses a topic no other tool appears to cover as good. But it has its share of issues; and integration with other processes and tools makes it less developer-friendly.

There is definitely room for an improved contract-first technology, especially if it would offer the following properties and features:

  1. Strong generation of code, documentation and browser-accessible test forms, similar to XINS.
  2. A runtime environment (client- and server-side) that provides strong operational excellence, similar to XINS.
  3. No attempt to be a one-size-fits-all; instead, make it easy to integrate this technology in existing contexts (tools, processes and technologies).
  4. Easy to pick up for current Java developers; this requires easy integration with modern build tools and IDEs.
  5. Transport-independence, supporting local calls, HTTP (including browser compatibility and efficient binary data handling), as well as other transports, with solid data type conversion.
  6. Strong integration with an existing component technology, such as Jigsaw or OSGi.
  7. Reusing an existing specification technology, such as WebIDL.

Conclusion

There is plenty of room for improving XINS, especially when it comes to adaptation to the current Java ecosystem. Still, in its current form, XINS is a mature technology that really shines when it comes to productivity and operational excellence.

Advertisements
 

XINS Lacking IPv6 Support

If you get the following error while running a XINS-based application:

org.xins.common.text.ParseException: The string "0:0:0:0:0:0:0:1%0" is not a valid IP address.

then you found out the hard way that XINS lacks IPv6 support. This applies to all current versions of XINS: 2.2, 2.3-beta1 and 3.0-beta1.

To work around this, set the system property java.net.preferIPv4Stack to true.

 
Leave a comment

Posted by on 30 April 2010 in ip6, ipv6, xins

 

XINS 3.0 Beta1 Released

Just now I tagged 3.0-beta1 of my experimental XINS fork (which is not so experimental from the perspective that it has been running in production-sites since 2007).

Source and related stuff available from GitHub:

For a complete download, get this ZIP package:

Recent changes include:

  • Ant 1.8.0 is now properly supported
  • Logdoc definitions are now validated using XSDs (Logdoc 0.3 included)
  • Default runtime config file reload interval is now 5 instead of 60 seconds.
  • Not initializing logging subsystem (Log4J) if system property org.xins.server.logging.init is set to false.
  • Not setting context IDs (in Log4J terminology: NDC.push() calls) if property org.xins.server.contextID.push is set to false (system, bootstrap or runtime property).
 
Leave a comment

Posted by on 28 April 2010 in ant, apache ant, github, logdoc, xins, xins3

 

XINS 2.x and my Experimental XINS 3.0-Fork

>After some investigations by myself and a constructive discussion with Anthony Goubard
(maintainer of the official XINS project) we have decided to backport features from my XINS 3-fork upstream instead of the other way around. Features will be discussed and ported one by one. This is the safest approach, leaving the baseline stable and only introducing changes gradually.

Expect some changes to go into the upcoming XINS 2.3 release, while most will come into the picture only after that.

Stay tuned for updates.

 
Leave a comment

Posted by on 11 February 2010 in xins, xins3

 

XINS 3.0 Alpha3 and Logdoc 0.2

>I’ve just released the 3.0-alpha3 version of my XINS fork, which includes the also just released Logdoc 0.2. See:

Compared to version 0.1, Logdoc 0.2 is cleaned up: the internal logging output is now sent via Ant, meaning that the Ant options -verbose and -debug are needed to see all output. This improves usability.

XINS 3.0-alpha3 introduces lots of small changes, mostly cleanup and minor corrections. A functional change is the introduction of client-side transaction logging via the log messages 2300 and 2301. The former includes the input/output parameters, while the latter does not.

Note that my XINS 3.0 fork is based off XINS 2.2-alpha2. Porting the changes from the 2.x branch to my 3.0-fork is one of my next challenges. Help in this area would be much appreciated! If you are keen and precise and know a bit about Java coding, let me know via ernst [at] ernstdehaan com.

 
Leave a comment

Posted by on 23 January 2010 in logdoc, xins

 

XINS 3.0 Alpha2 and Logdoc 0.1

>Just now I’ve released the 3.0-alpha2 version of my XINS branch, at:

Main feature is that Logdoc has been factored out into its own project, of which I’ve released version 0.1:

Logdoc is used to specify log mesages separate from code, generating both Log4J code and web documentation.

Possibly Logdoc can be extended to support code generation to other environments, including Apache Commons Logging, Log4PHP, Log4C, etc.

Another change made to XINS is that all source code is now under src/java making it much easier to work on XINS from an IDE.

So most of the previously presented random ideas have been implemented already…

 
Leave a comment

Posted by on 11 January 2010 in logdoc, xins

 

Random Ideas for XINS and Logdoc

>Here’s a random list of possible enhancements to XINS.

First, a couple of changes that would make it much easier to configure an IDE (such as Eclipse or NetBeans) to work with XINS:

  • Move all Java source code to src/java/; currently it is spread out over src/java-common, src/java-client-framework and src/java-server-framework. Still, the JAR files can remain the same.
  • Put the generated Java source files also under src/java/, such as the Log and TranslationBundle classes.
  • Put all generated class files under build/classes/.
  • Make the Library classes detect the XINS version at runtime, instead of using a text replacement technique to modify the source code before compiling it.
Then some ideas on Logdoc:
  • Split out Logdoc from XINS. It’s not needed inside XINS, all it needs is a JAR file and some Ant tasks for generating some stuff (like the Java source files and the documentation).
  • Make it easy to plug in a different logging library. Currently, Logdoc generates Log4J code, but it should be fairly simple to make it generate code for other logging libraries. It doesn’t mean Logdoc should actually implement this, but it would at least facilitate it.
To be continued.
 
1 Comment

Posted by on 30 December 2009 in java, logdoc, xins, xins3