RSS

Category Archives: xins3

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 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

 

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

 

XINS 3.0 Alpha1 Tagged (Fork at Github)

>Just now I’ve created a tag for XINS 3.0-alpha1 in my XINS-fork at GitHub:

From a runtime-stability point of view, I expect this release just works, even if it is tagged as an alpha-release. At least for me this branch has been running in production for a couple of years now.
However, do note that from a development perspective, a lot of things may change before this goes into (or becomes) an official XINS 3 release. This requires agreement with other involved parties, especially Anthony Goubard (official XINS maintainer) and Online (copyright owner of most of the code).
Some of the things still high on my TODO-list:
  • get rid of all deprecation warnings by either resolving or suppressing them, depending on what is more appropriate
  • further change the code to use type-safe collections where possible, using generics
  • merge with official XINS 2.x changes
 
Leave a comment

Posted by on 28 December 2009 in xins, xins3

 

XINS 3.0 Fork at Github

>Just recently, I’ve made our internal XINS fork available via:

The version is currently set at 3.0-alpha1-dev. This may become the official XINS 3.0 release at some point, or (some or all) changes may go into an official XINS release.

The most important changes in compared to mainstream XINS are:

  • Java 5-features, such as generics and foreach-loops (hence Java 5+ is required)
  • lots of utility functions are added, to simplify programming with XINS
  • various libraries are updated, such as Saxon (from 8 to 9) , JUnit (from 3 to 4), Xerces, etc.
  • a couple of previously deprecated members and classes are removed, most notably FastStringBuffer and FastStringWriter
  • deprecated various classes and members, such as the ElementBuilder class
  • upgraded from XSLT 1.0 to 2.0
  • the Element class now supports mixed content (PCDATA and child elements), an add(String) method has been added

This branch of XINS has been used in production for almost 3 years now, but you are not advised to use this code in production, as it has not gone through all the testing that is typically done for an official XINS release, across various platforms and Java versions.
Also note that not all of the changes in XINS 2.2/2.3 have been incorporated (yet).

The following things are still on my list of things to be done:

  1. clean the code up further
  2. get rid of all deprecation warnings by either resolving or suppressing them (whatever is more appropriate)
  3. further changing the code to use type-safe collections where possible, using generics
  4. possibly adding Commons Lang as a dependency, so that various utility methods, like TextUtils.isEmpty(String) can be deprecated (and later removed)
  5. change HttpClient (which is deprecated) based code with HttpComponents HttpClient based code
  6. get rid of Jakarta ORO, just use the J2SE regular expression-support that is available since J2SE 1.4

If you have any changes you would like to incorporate into (this branch of) XINS, fork the project at github. Using git, it is quite easy to merge different forks.

To be continued.

 
Leave a comment

Posted by on 1 October 2009 in xins, xins3

 

>XINS: Splitting out Logdoc?

>Talking to Anthony Goubard yesterday (of JLearnIt and AntCommander fame), I realized that adding features like SMTP– and SMS-support to a Web Services framework like XINS can hardly be considered good separation of concerns. So I definitely need to revise my XINS 3.0 wishlist.

Instead, it may be a much better idea to make XINS focus more on the Web Services functionality and split some technologies out. The main candidates seem to be Logdoc and the ServiceCaller framework:
In the picture the arrows indicate dependencies. So XINS would depend on Logdoc and the ServiceCaller framework and the latter would also depend on Logdoc.

Logdoc: What is it?
In this post I will focus on Logdoc.

So what is Logdoc and why would we want to separate that out from XINS? Is it useful for other projects as well?

IMHO the answer is “yes”. Logdoc is a logging system based on the infamous Apache Log4J library that offers some features over Log4J:

  • registered logging categories: there is an explicit list of all logging categories, with documentation;
  • unique log messages: each log message is in a specific category and gets a specific number; this allows system administrators to enable or disable individual messages;
  • multi-locale: it is straight-forward to add a new language for log messages;
  • separation of concerns: the code does not bother with log levels, translations and categories, instead it just deals with a single log message (identified by ID) and it’s parameters.

Logdoc code example
Here is an example of a piece of Java code that uses Logdoc, from the HTTPServiceCaller class (javadoc/source):

// Unknown host
if (exception instanceof UnknownHostException) {
Log.log_1102(url, params, duration);

Notice that there is no category, no creation of objects and no language-specific stuff.

Logdoc definitions
The key to the Logdoc system is the definition of categories and entries in XML. Every entry is within a single category. Translations can be specified in separate files, one per language/locale. So for example, for the XINS/Java Server Framework, the following files define all logdoc entries and their translations:

  • src/logdoc/server/log.xml – defines all categories and contained entries; each entry has a unique number, it specified a log level and optionally some parameters;
  • src/logdoc/server/translation-bundle-en_US.xml – defines all U.S. English translations for the log messages defined in the log.xml file;
  • src/logdoc/server/translation-bundle-fr_FR.xml – defines all French (France) translations;

Adding a new set of translations is as easy as adding one line to the log.xml and one translation-bundle-xx_XX.xml file, where xx is the ISO language code and XX is the ISO country code.

Now from these specifications, both code and documentation is automatically generated, XINS-style. Here is an example of generated Logdoc documentation:

Notice that there are 2 ways to find log entries: by category and by ID (see the Logdoc entry list link at the top).

More information
For more information on Logdoc, check out the section titled “Managing logs” in the XINS User Guide.

 
Leave a comment

Posted by on 8 January 2008 in log, logdoc, logging, servicecaller, web services, xins, xins3