Discussions

News: XINS 1.4.0, web services framework, released

  1. After 5 months of development, tuning and testing, XINS 1.4.0 has been released. XINS is an open-source Web Services framework. It offers a simple tool for the development of distributed applications.

    One of the key features that differentiate XINS from other technologies is the definition-driven approach. Write simple XML definitions and XINS will generate for you:
    • Documentation of the specifications and implementations
    • Test forms, for testing your applications with a browser
    • Client-side code, supporting load-balancing, fail-over and time-out handling
    • Web application, compatible with Java servlet containers
    • WSDL, for SOAP-interoperability
    • Unit test code, based on JUnit
    • Stubs, typically used for testing
    Another key feature is protocol independence. XINS supports several communication protocols, including SOAP, XML-RPC and POX-RPC. For each incoming request XINS automatically determines which protocol to use. With XSLT the results can be transformed to HTML or other content types. Custom protocols can be added.

    XINS 1.4 offers various new features over release 1.3, as well as some bug fixes. The main new features are:
    • Automatic communication protocol detection.
    • Asynchronous requests
    • Generation of documentation in OpenDocument format, for use by OpenOffice.org and other text processors.
    • Support for including files (e.g. HTML) in the WAR file
    • Extensive Pet Store demo
    Additionally, both the compile-time performance and the runtime performance of XINS have been tuned further.

    XINS is used in production systems since the end of 2002. As a stable release, XINS 1.4.0 is backwards compatible with all previous stable releases. It has been tested extensively on various platforms, including Solaris, Linux and Windows.

    Download XINS 1.4.0, either as a Windows installer or as a platform-independent TAR GZ file:Resources:
  2. Could XINS be a near drop in replacement for Axis?
    - on server?
    - on client?
  3. Could XINS be a near drop in replacement for Axis?- on server?- on client?

    On the server side, yes.
    On the client side, it also generates the classes to call your service but it's not using SOAP to communicate. The protocol used (POX-RPC) is a URL with parameters as request and simple XML as response.
    Note that the server accepts POX-RPC, SOAP and XML-RPC at the same time.

    Another difference is that with XINS the specifications are leading. Hopefully it's in simple XML and the WSDL is generated from it.
  4. Looks good[ Go to top ]

    I must say the XINS project looks pretty good from a quick readup in the intro and users guide. What I couldn't find directly is whether or not XINS allows for the use of JMS as Soap protocol. Can you say something about that?
  5. Looks good[ Go to top ]

    I must say the XINS project looks pretty good from a quick readup in the intro and users guide. What I couldn't find directly is whether or not XINS allows for the use of JMS as Soap protocol. Can you say something about that?

    I do not understand what you mean by "use JMS as SOAP protocol".

    XINS is a framework that goes very far in definition-driven development, generating lots of useful things from some simple definitions.

    One of those things is a big part of your server-side application. This application is protocol-independent, meaning you can use any HTTP-based protocol to call your functions. Some of those protocols are included (XML-RPC, SOAP Basic Profile, POX-RPC, XSLT, etc.) and if you want another one, then you can add your own.

    Does this answer the question? If not, please rephrase it.
  6. XINS and JMS[ Go to top ]

    After talking to a colleague, I must admit the question wasn't entirely correctly phrased, but your answer and the PowerPoint presentation do provide a clear answer. To clarify what I meant:

    Soap allows the use of other transport protocols besides http. At a client we use JMS as a transport mechanism for our Fire and Forget messages. JMS (and MQ) in our case guarantees the delivery of these messages. I completely understand the absence of this technique in XINS, but it would have been convenient in case we ever want to make the switch.

    Thanks for replying.
  7. Congratulations on your new release.

    One question: could you give a bit more detail into what POX-RPC involves. I couldn't find any information on the website.

    At first sight it appears to be a bit of a contradiction. If there is a procedure-calling protocol, presumably it can't be "plain old XML", unless the procedure in question is a URL parameter or HTTP verb, in which case we're talking about REST.

    Thanks
    Regards
    Kit
  8. Kit,
    Congratulations on your new release.

    Thanks :-)
    One question: could you give a bit more detail into what POX-RPC involves. I couldn't find any information on the website.

    A good example for it is a test forms, such as this one:
    http://xins.sf.net/demo/specdocs/myproject/MyFunction-testform.html

    Thing is, we kept changing the name of the protocol. Some of the names we used:
    - XINS Standard Calling Convention (descriptive name)
    - _xins-std (technical name)
    - REST-RPC (deprecated)
    - POX-RPC (new name)

    Now, POX-RPC has been chosen as the definite name. We are considering splitting POX-RPC out of XINS somewhere this year.

    Here are some documents that describe it:
    http://xins.sf.net/docs/protocol/
    http://xins.sf.net/docs/ar01s22.html#N10CC3
    http://xins.sf.net/restrpc.html
    At first sight it appears to be a bit of a contradiction. If there is a procedure-calling protocol, presumably it can't be "plain old XML", unless the procedure in question is a URL parameter or HTTP verb, in which case we're talking about REST.

    Not really. REST is resource-oriented, so this is not RESTful:

    http://localhost/?_function=GetCart&id=12

    Instead, with REST you would do something like this:

    http://localhost/carts/12/

    That's why POX-RPC is not RESTful. But in practice, it comes very close.


    Ernst