Axis2 is an effort to re-design and totally re-implement Axis/Java, moving away from RPC towards a more document-oriented, asychronous WS tool. v0.9 is a major release bringing the project a lot closer to that goal, by adding the following features:
- Posted by: Floyd Marinescu
- Posted on: July 06 2005 13:50 EDT
This Axis2 0.9 release has the following features:
* AXIOM, a SOAP specific streaming XML infoset model for SOAP 1.1/1.2 Messages
* Support for One-Way Messaging and Request Response Messaging
* Modules, mechanism to extend the SOAP Processing Model
* Archives based deployment Model
* WSDL Code Generation Tool for Stub and skeltons based on WSDL 1.1
* XML Beans based data binding support
* Support for WS-Addressing, both the Submission and Final versions
* Client API
* REST Web Service Support
* HTTP transport Support
* SMTP transport Support
* TCP transport Support
* MTOM/SWA attachments support
* SAAJ implementation
The Axis group also have put out a request to contribute to the project, at axis-dev at ws dot apache dot org. Any contribution in the form of coding, testing, submitting improvements to the documentation, and reporting bugs is always welcome.
Downloads are available at:
- Apache Axis2 v0.9 Released by murali kosaraju on July 06 2005 16:05 EDT
- And it'll still be a bad idea 90% of the time by Dan Tanner on July 06 2005 23:04 EDT
Are there any performance metrics available for comparison between Axis 1.2 and Axis2?
It would be interesting to see the throughput under heavy loads for doc literal vs rpc encoded on, say Tomcat 5.x. for Axis2.
First EJB, now SOAP...I think bloated and mostly useless technologies are the abusive (boy|girl)friends of the java community. ("No - really - I promise my next release won't make you spend weeks dealing with stupid plumbing issues when you could be adding business value...I can change...just one more rev.")
REST support? Does anyone else find that funny?
These old delusions are funny too, unless you still have dozens of services based on it that you're forced to interact with.
First EJB, now SOAP...I think bloated and mostly useless technologies are the abusive (boy|girl)friends of the java community. ("No - really - I promise my next release won't make you spend weeks dealing with stupid plumbing issues when you could be adding business value...
What Java people who reject Web Services (and many other XML based technologies) need to understand is that the whole business of making systems work across organisational and technological boundaries, is itself the mother of all stupid plumbing issues. And the business value lies exactly in dealing with these stupid plumbing issues.
These stupid plumbing issues, that I will call integration issues from now on, have always been dealt with by sending blobs of text or even binary data back and forth. And IT people on both sides were very very busy with negotiating the rules concerning that data, the various exchange procedures, security, transactions, etc. Now this whole Web Services stack gives us a way of making these agreements more efficient and reliable. CORBA tried to do the same thing, but it failed because it caused too close coupling.
Keep in mind that Web Services are not there to replace internal API calls (local or remote). They are there to replace various forms of external data exchange and process integration.
What is your thoughts on exchanging XML documents over HTTP as a means of integration? What is wrong with vanilla REST?