Axis2 is one of the very successful Apache projects in many different ways; however I am not going to discuss the quality of the project of customers who use the project, rather a totally different area of its success.
Axis2 was started with six core members (all from Sri Lanka) and later joined many members to the project. The most interesting and notable thing about Axis2 is all the initial members entered graduated school and four of them have already become PhD holders (Srinath, Jaliya, Chinthaka and Chathura). Not stropping from that second, third, and forth (may be fifth) generations of contributors have entered graduate school and are now in the pipeline to complete their Ph.D.'s in the next few years (at least 12).
Counting all, in the history of Apache software foundation Axis2 will be the first project to produce so many PhD holders. I think this is a huge success of the project, and many credits should go to Sanjiva for motivating all of them to select the correct path.
Tuesday, July 26, 2011
Wednesday, July 13, 2011
Wednesday, February 23, 2011
A new book on Apache Axis2
Happily, we were able to publish the second book on Apache Axis2. I published the first book in 2008 (Quickstart Apache Axis2), and after three years, now the second book is also available (Apache Axis2 Web Services). Our initial plan was to publish the book this time last year, but due to usual reasons it got delayed. We have improved the book a lot and added lot of new and interesting contents.
I really want to thank my co-author Afkham Azeez, who helped me a lot to add new chapters and to make the book ready for building advanced web services with Axis2. We started Axis2 in way back 2004, and needless to say this project will not exists without the initial members and their tremendous contributions: Srinath Perera, Ajith Ranabahu, Eran Chinthaka, Davanum Srinivas, Glen Daniels, Sanjiva Weerawarana, Paul Fremantle, Jaliya Ekanayake, Chathura Herath, Ruchith Fernando, and Chamikara Jayalath. In addition, special thanks goes to our second generation contributors: Thilina Gunarathne, Keith Chapman, Amila Suriyaarachchi, Sanka Samaranayake, Lahiru Sandakith, Nandana , Saminda Abeyruwan and many more. Not least, but last all the members of the Axis2 project who has contributed a lot to make the project a success. Thank you all.
Hope you will learn from this book and enjoy it.
I really want to thank my co-author Afkham Azeez, who helped me a lot to add new chapters and to make the book ready for building advanced web services with Axis2. We started Axis2 in way back 2004, and needless to say this project will not exists without the initial members and their tremendous contributions: Srinath Perera, Ajith Ranabahu, Eran Chinthaka, Davanum Srinivas, Glen Daniels, Sanjiva Weerawarana, Paul Fremantle, Jaliya Ekanayake, Chathura Herath, Ruchith Fernando, and Chamikara Jayalath. In addition, special thanks goes to our second generation contributors: Thilina Gunarathne, Keith Chapman, Amila Suriyaarachchi, Sanka Samaranayake, Lahiru Sandakith, Nandana , Saminda Abeyruwan and many more. Not least, but last all the members of the Axis2 project who has contributed a lot to make the project a success. Thank you all.
Hope you will learn from this book and enjoy it.
Wednesday, February 02, 2011
yum install problem on Fedora
When you use Fedora older version you might get following error and spend hours and hours to solve the problem.
problem:
yum install libcurl-devel
Setting up Install Process
Setting up repositories
And here is the solution:
You need to edit all the files in (end with .repo) /etc/yum.repos.d/, and update the baseURI to following
http://archives.fedoraproject.org/pub/archive/fedora/linux/
problem:
yum install libcurl-devel
Setting up Install Process
Setting up repositories
And here is the solution:
You need to edit all the files in (end with .repo) /etc/yum.repos.d/, and update the baseURI to following
http://archives.fedoraproject.org/pub/archive/fedora/linux/
Thursday, November 18, 2010
Axis2 1.5.3 released
The Apache Axis2 team is pleased to announce the general availability
of the Axis2 1.5.3 release.
1.5.3 is a maintenance release that contains the following improvements:
* Improved support for SSL when using the servlet transport: Axis2 can
now be configured so that generated WSDLs contain https endpoints
(AXIS2-4465).
* Improved compatibility with Rampart (AXIS2-3213 and AXIS2-4870) and
Sandesha2 (potential HTTP connection pool starvation).
* Axiom has been upgraded to 1.2.10. This version contains performance
improvements relevant for Rampart.
* Application (business) faults are no longer logged at level ERROR
(AXIS2-4280).
* Improved conformance to the SAAJ specifications. The 1.5.3 release
contains a set of fixes and improvements for the SAAJ implementation
developed on the trunk and not included in previous releases from the
1.5 branch.
* Axis2 now relies exclusively on dependencies available from the
Maven central repository, and no other Maven repositories are
required. This in particular fixes a build problem that appeared after
the 1.5.2 release.
* The Eclipse and IntelliJ IDEA plugins are again available for
download via the Axis2 Web site (previous 1.5.x versions could only be
downloaded from the Maven repository).
The complete list of JIRA issues fixed in this maintenance release can
be found here:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10611&fixfor=12315367
The new version is available for download at the following location:
http://axis.apache.org/axis2/java/core/
Please report any issues via JIRA: http://issues.apache.org/jira/browse/AXIS2.
As always, we welcome any and all feedback at:
java-dev@axis.apache.org - for developer-related questions/concerns
java-user@axis.apache.org - for general questions, usage, etc.
Thanks for your interest in Apache Axis2!
-- The Apache Axis2 team
Tuesday, October 05, 2010
ConnectException when connecting to Tomcat
If you are experiencing following exception when you try to connect to tomcat either using Java socket, TCP Monitor or any other means, then try the following procedure:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
Go to conf directory in the Tomcat installation directory, and then edit the server.xml as follows:
<Connector port="8080" maxHttpHeaderSize="8192"
address="127.0.0.1"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
By default Tomcat does not come with the address attribute, once you set that to localhost or any address you want, then you will be able to solve the above exception.
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
Go to conf directory in the Tomcat installation directory, and then edit the server.xml as follows:
<Connector port="8080" maxHttpHeaderSize="8192"
address="127.0.0.1"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
By default Tomcat does not come with the address attribute, once you set that to localhost or any address you want, then you will be able to solve the above exception.
Tuesday, August 24, 2010
Web services past, present and future
What is a Web service? There are multiple definitions or understandings about Web services, one can argue Google search as a Web service, meaning a service offered via Web, same way Amazon retailer site can be also considered as a Web service, because it offers a way to buy and sell product over the Web, or application to application communication through open protocol like SOAP can be also considered as Web service. However, here my main focus is SOAP based Web services, meaning application to application communication.
In the distributed system, remote service invocation is not a new thing at all, even in the early papers on operating system design discussed about remote procedure calls or RPC. In fact they have provided sound architecture to implement RPC. Later, people wanted to develop more complex and application aware middleware to have distributed communication, among them CORBA and Java RMI became two commonly used technologies. Nevertheless, due to complexity of CORBA and domain dependency of Java RMI (only within JAVA) people tend to find other alternatives. Introduction of XML into the industry influenced lot on this effort. Then, people realized XML as the future communication media, in fact Bill Gates also believed XML going to be the dominant media for applications communication.
As a results of long collaboration between IBM and Microsoft (and also some other companies), SOAP came into the industry as a way of building application communication middleware. IBM started its implementation of SOAP based web service middleware and later donated that to Apache Software Foundation and which became Apache SOAP, and started Web service community around Apache. Apache SOAP was very simple and assumed to be proof of concepts; people really liked Apache SOAP and started to use it to application integration, then demanded a set of new features, which leads to have an array of Web service standards and specifications. In addition a set of Web service bodies to enforce satisfaction of specifications. At that time there were multiple Web service frameworks out there, Apache had Apache SOAP and Apache Axis, and Microsoft had Indigo (later renamed to .Net), Oracle, Sun, BEA, HP and few other companies had their own implementations.
One of the natures of any application is need of evolving and revolving, same thing happen to Web services, where it started as a simple set of standards, but today there are a number of standards. As a matter of fact Web service has become somewhat complex for average people. Even though there are hundreds of Web service specifications, there is no single Web service framework which implements all the standard, according to my understanding Axis2 is the only open source Web service framework implement highest number of standards, and of course Microsoft is leading in commercial market.
One of the main barrier of Web services is the complexity of WSDL, both WSDL 1 and WSDL 2 are little too complex to understand. In addition other standard like Security, Reliability and Addressing are way too complex for simple usages. That is something, standard bodies need to consider about.
Way back in 2004 when we started Axis2, one of the key goal was to have less than 1 MB size for the distribution, but, due to supported specifications and features it is way too big and complex. I have seen number of concerns on the mailing lists. I think this is true for any product, when they keep adding features, application become complex and size become larger.
Within a short period of time, Web services have made big impact to the industry, where most use Web service as a way of application integration. In addition most applications offer a Web service interface to access the service (e.g., Google, Amazon, Weather), which help to write custom components and application. Above all, with cloud computing, Web service became one of the standard ways to manage and monitor cloud based services. Simply, Web services have won the market today. But what will happen in the future …..
I think, due to complexity of Web service, people tend to find other alternatives or ways to reduce the complexity of Web services, but one thing is obvious that is XML will remain unchanged. In the future regards REST will play a major role, even today some believe REST is better than SOAP, which is in fact true for some scenarios, but when it comes to complex scenarios REST is not there to support them. Simply need additional specifications to handle addressing, security and etc… which will end up being yet another SOAP based Web service framework. As a Web service lover, I still believing in Web services, but I would like it to be simple and easy to use, yet provide what industry need.
In the distributed system, remote service invocation is not a new thing at all, even in the early papers on operating system design discussed about remote procedure calls or RPC. In fact they have provided sound architecture to implement RPC. Later, people wanted to develop more complex and application aware middleware to have distributed communication, among them CORBA and Java RMI became two commonly used technologies. Nevertheless, due to complexity of CORBA and domain dependency of Java RMI (only within JAVA) people tend to find other alternatives. Introduction of XML into the industry influenced lot on this effort. Then, people realized XML as the future communication media, in fact Bill Gates also believed XML going to be the dominant media for applications communication.
As a results of long collaboration between IBM and Microsoft (and also some other companies), SOAP came into the industry as a way of building application communication middleware. IBM started its implementation of SOAP based web service middleware and later donated that to Apache Software Foundation and which became Apache SOAP, and started Web service community around Apache. Apache SOAP was very simple and assumed to be proof of concepts; people really liked Apache SOAP and started to use it to application integration, then demanded a set of new features, which leads to have an array of Web service standards and specifications. In addition a set of Web service bodies to enforce satisfaction of specifications. At that time there were multiple Web service frameworks out there, Apache had Apache SOAP and Apache Axis, and Microsoft had Indigo (later renamed to .Net), Oracle, Sun, BEA, HP and few other companies had their own implementations.
One of the natures of any application is need of evolving and revolving, same thing happen to Web services, where it started as a simple set of standards, but today there are a number of standards. As a matter of fact Web service has become somewhat complex for average people. Even though there are hundreds of Web service specifications, there is no single Web service framework which implements all the standard, according to my understanding Axis2 is the only open source Web service framework implement highest number of standards, and of course Microsoft is leading in commercial market.
One of the main barrier of Web services is the complexity of WSDL, both WSDL 1 and WSDL 2 are little too complex to understand. In addition other standard like Security, Reliability and Addressing are way too complex for simple usages. That is something, standard bodies need to consider about.
Way back in 2004 when we started Axis2, one of the key goal was to have less than 1 MB size for the distribution, but, due to supported specifications and features it is way too big and complex. I have seen number of concerns on the mailing lists. I think this is true for any product, when they keep adding features, application become complex and size become larger.
Within a short period of time, Web services have made big impact to the industry, where most use Web service as a way of application integration. In addition most applications offer a Web service interface to access the service (e.g., Google, Amazon, Weather), which help to write custom components and application. Above all, with cloud computing, Web service became one of the standard ways to manage and monitor cloud based services. Simply, Web services have won the market today. But what will happen in the future …..
I think, due to complexity of Web service, people tend to find other alternatives or ways to reduce the complexity of Web services, but one thing is obvious that is XML will remain unchanged. In the future regards REST will play a major role, even today some believe REST is better than SOAP, which is in fact true for some scenarios, but when it comes to complex scenarios REST is not there to support them. Simply need additional specifications to handle addressing, security and etc… which will end up being yet another SOAP based Web service framework. As a Web service lover, I still believing in Web services, but I would like it to be simple and easy to use, yet provide what industry need.
Subscribe to:
Posts (Atom)