Discussions

News: XINS 1.1 released - Web Services Simplified

Bookmark and Share Get thread feed

  1. XINS 1.1 released - Web Services Simplified (7 messages)

    XINS is a technology used to define, create and invoke remote APIs. XINS is highly specification-oriented. API specifications (written in XML), are transformed by XINS into HTML-based documentation and Java code for both the client- and the server-side. The communication is based on HTTP.

    XINS competes with the overcomplex Microsoft web services technologies (e.g. SOAP, WSDL). Main design goals include simplicity, scalability and testability.

    New features include support for floating point and binary types, structured input, XML based request and various other improvements as well as bug fixes.

    For more information visit the XINS home page, read the user guide and have a look at the demonstration page.

    XINS is published under the BSD License.
    Reply to this

    Threaded Messages (7)

  2. Web Services (SOAP) Alternatives..[ Go to top ]

    So, I have to say two things here... one is, this doesn't look bad at all. Looks well thought out, very functional.. and simplicity/performance oriented. So thats good.

    The other side though.. unless its being pushed as a W3 standard and is supported by major vendors, I'm not sure what the attraction is here. We have XML-RPC, REST, ICE (ZeroC), and Burlap. We have binary transports like RMI and CORBA.. and we have emerging hybrids, like the SOAP/XML Binary Encoding stuff being tossed around. All of these are technically very good.. all provide great features.. but if you are outside of a controlled environment, aren't you basically going to be using SOAP at this point?

    I don't want this to be taken that I'm a huge fan of SOAP.. I think its been getting more and more complex.. especially with competing standards around security and the like. Its starting to look more like XML CORBA to me in some ways.. but being realistic, where would these alternate transports gain a foothold? SOAP is the lowest common demoninator.. not the best.. but works over HTTP and is out there. Others may work over HTTP, may tunnel through HTTP, or may be totally different. But, how are people using them? Internal system development? (And if so, why not use a binary encoding and save the XML overhead?)

    I'm curious.. It would be interesting to take some of these remoting protocols and build out a matrix of "real-world" deployments and such as a comparison..
    Reply to this Reply to original

  3. Is there room for improvement?[ Go to top ]

    So, I have to say two things here... one is, this doesn't look bad at all. Looks well thought out, very functional.. and simplicity/performance oriented. So thats good.
    Indeed. We have spent more than 2 years developing XINS into what it is today. In production, the technology has proven to be reliable, scalable and very well manageable (operationally).
    The other side though.. unless its being pushed as a W3 standard and is supported by major vendors, I'm not sure what the attraction is here.
    The attraction is in the simplicity. This technology just makes your life easier, whether you are in the role of a Developer, a Specification Author, an Operations Manager or a Support Manager.As a Developer, for example, you get generated classes to call your API. All input parameters are converted to the most specific Java types.As an Operations Manager, I can define the URLs to connect to without restarting the application. I can use an overview of all possible log messages to determine what to look for in the logfiles. I can change time-out values on-the-fly, etc.Still, XINS offers enough power to be attractive in more complex scenarios as well.
    We have XML-RPC, REST, ICE (ZeroC), and Burlap. We have binary transports like RMI and CORBA.. and we have emerging hybrids, like the SOAP/XML Binary Encoding stuff being tossed around. All of these are technically very good.. all provide great features.. but if you are outside of a controlled environment, aren't you basically going to be using SOAP at this point?
    That's not what we see happening in practice. Most people seem to accept the fact that SOAP is the dominating standard in the web services landscape. However, most avoid it because it is just way too complex. Instead, custom XML or URL-based remoting applications are built.
    This is where XINS comes in. It allows one to write an XML- or URL-based in just a few minutes. Write the specs, generate the WAR file and then modify the editable generated source file (there is also non-editable generated code involved).
    I don't want this to be taken that I'm a huge fan of SOAP.. I think its been getting more and more complex.. especially with competing standards around security and the like. Its starting to look more like XML CORBA to me in some ways..
    This is exactly the point. If SOAP was sufficiently simple and powerful, XINS would never have been developed in the first place. Give XINS a try and see for yourself. We would be really interested in your comparison of SOAP and XINS!
    It would be interesting to take some of these remoting protocols and build out a matrix of "real-world" deployments and such as a comparison..
    Good idea. We intend to put such a matrix on the XINS web site. However, an independant comparison would be even more useful.
    Reply to this Reply to original

  4. XML CORBA[ Go to top ]

    Hi Paul,

    I could not agree with your more, as far as these web service tools becoming more and more like CORBA. I even read an article (i think it was TSS) about how to use certain patterns in SOAP to account for context-necessary provisions that you normally get in CORBA!

    When it comes right down to it though, in a way i think that SOAP is a more verbose, less context sensitive, tool for doing what much of CORBA does in the first place. Like you say, SOAP is just the lowest common denominator. I think conceptually, an XML CORBA is what a lot of people want, but when the reality of performance starts to rear its ugly head, these other specs start to spring up (Binary XML Package spec released yesterday from w3c).

    I would like to see the same sort of comparison. In addition i would like to see more domain specific areas where the lines between SOAP and XML CORBA are starting to be blurred, and from there a specification for appropriate tool application could be built.

    Can anybody provide some experience where they have seen this blurring? In my own experience i have found that webservices that support large result sets have pushed for binary tools, and where i think most people would agree: SECURITY.over-soap() == XML-CORBA.INSTANCE

    Thanks!
    ~tim
    Reply to this Reply to original

  5. Web Services (SOAP) Alternatives..[ Go to top ]

    (And if so, why not use a binary encoding and save the XML overhead?)I'm curious.. It would be interesting to take some of these remoting protocols and build out a matrix of "real-world" deployments and such as a comparison..
    Indeed why?
    It is time to say NO to the nonsense and FUD from network people and simply require CORBA IIOP port was open on firewalls. That is it.

    As for comparison: look for a very simple one on my site, some day I will add XINS there http://kgionline.com/articles/protocol_compare/doc/index.jsp
    Reply to this Reply to original

  6. Simplicity[ Go to top ]

    I'm always very drawn to simplicity and maintainability.

    So that is why is use Apache Axis to enable public accessible SOAP methods; all I need to do is write a JWS file containing the SOAP interface (and nothing more than the interface), the rest is generated.

    Or Hessian for application internal (read: applet, JWS) communication; I only need to specify an interface and the actual communication is binary (fast). Ports exists for CPP, C#, PHP, Flash, so using the occasional different technology is not really a problem.

    I'm already happy. No configuration hassle, no XML specifications to write. :-)
    Reply to this Reply to original

  7. XINS 1.1 Raining on Parade[ Go to top ]


    This thing is "highly specification-oriented", and if you read the docs, the thing that just makes me cringe is the fact that you have to modify generated code. Read the Implementing the Method section and follow the process, read down to "implementing your function" and notice how after you've generated MyFunctionImpl.java you have to edit it manually.



    Instead of focusing on web services, XINS gets into load balancing, CVS integration, log files, etc. So, you end up writing all of your services to XINS specific APIs. (all your base will belong to XINS) Instead of XINS, I'd recommend Spring Framework, with something like Spring, your services remain independent of any specific services framework and you just end up decorating an existing service with a number of different adapters - Axis, Hessian, Burlap, RMI.
    Reply to this Reply to original

  8. Re: XINS 1.1 Raining on Parade[ Go to top ]

    This thing is "highly specification-oriented", and if you read the docs, the thing that just makes me cringe is the fact that you have to modify generated code. Read the Implementing the Method section and follow the process, read down to "implementing your function" and notice how after you've generated MyFunctionImpl.java you have to edit it manually.

    This is optional. You could also write the code yourself. XINS just aids you in this. Note that XINS offers a combination of active and passive code generation. All the passively generated code (which is what you are referring to) runs within a kind of sandbox imposed by the XINS/Java Server Framework and the actively generated code, specific to the API.
    Reply to this Reply to original