Category Archives: web services

>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


>XINS 3.0 (updated x3)

>Note (added Jan 8, 2008): This article is outdated, please read “XINS: Splitting out Logdoc?

XINS is a powerful technology for writing web applications and web services. While the current 2.1 version already sports a lot of functionality and flexibility, here’s my wishlist for a 3.0 version:
  1. Support for Java 5 generics. If this will make the framework Java 5+ only, so be it.
  2. Support for XML-type parameters, both in and out.
  3. A XINS service caller engine; a separation between the XINSServiceCaller and the actual protocol used, possibly with a (static, non-final) inner class Engine.
  4. Provide an alternative front-end calling convention that sports clear URLs, path-based instead of parameter-based.
  5. Combine multiple function invocations in one call, avoiding the network overhead of multiple calls.
  6. Multi-implementations: Allow a single API implementation to implement multiple API interfaces.
  7. Allow API inheritance, so that one API can inherit the functions defined in another.
  8. After some thorough analysis, apply some secure defaults. E.g. only allow metafunctions to be called from localhost.
  9. An SMTP caller that supports load-balancing and fail-over (see RFE 1859843).
  10. A similar SMS caller (see RFE 1864472) that allows the sending of SMSes via different gateways.

See also:

Updated December 20, 2007: Added #5, #6 and #7.
Updated December 24, 2007: Added #8.
Updated January 5, 2008: Added #9 and #10.


>Combining XINS and SWF?

>While listening to a Java Posse podcast episode 91, Spring Web Flow (SWF) was mentioned. SWF apparently integrates not only with Spring MVC, but also with Struts, JSF and Portlets. Makes me wonder whether I can use it in combination with XINS as well.

I like XINS a lot, but the support for web applications (the so called XINS Front-end Framework) lacks some features I will want to see, such as:

To be investigated…

Leave a comment

Posted by on 2 December 2006 in java, spring, swf, web services, xins


>XINS 1.5.0 released

>Last week, XINS 1.5.0 was released. Since, some bugs have been discovered. All found bugs have been resolved as well. The bugfixes will be released as part of the upcoming XINS 1.5.1, which is currently under development. Expected release date is January, 2007.
At the same time, work on XINS 2.0 is starting. First committed changes is the removal of some deprecated class members. Surprisingly, some deprecated members have been unmarked, so as of XINS 2.0.0 they are no longer considered deprecated.

Leave a comment

Posted by on 28 November 2006 in java, web services, xins