This is my third attempt at diving into the use of an open source product, and on the whole it has been good. I am always impressed that these individuals will put all the time into these projects, even though nobody will ever pay them anything for their work. One thing that I have learned is that it is NOT a good idea to try to implement a newly released project. I have been paying attention to the "direction of the breeze" when it comes to Axis 2, but I would not even consider trying to implement it in a production environment. It is still too "green" for me.
On to the constructive criticism! 8) (not version specific)
Rakesh Patel <[EMAIL PROTECTED]> wrote:
>> I also have not found the experience of working with web services and >> apache axis a pleasurable one.
Aside from the frustration factor that is usually present with the use of open source projects, I f ind most of the experience pleasurable. The main source of frustration seems to be related to the state of the project (how long it has been since release), and the state of the documentation.
Rakesh Patel <[EMAIL PROTECTED]> wrote:
>> The Apache axis docs were pretty bad. Its not geared towards learning >> the way to use axis, more a reference. I had no idea how to add axis to
>> an existing application. I did it in the end becasue some helpful guy
>> had made available a minimal app that you could use to start from on his
>> blog (why doesn't the main site provide this?). The 1.3 download has
>> docs for 1.2.
In most cases, an excellent software developer does not make an excellent documentation writer. I could not agree more with the statement about the docs not being geared for learning. I would guess that most of us who are on the hook to deliver a working project have uttered quite a few "oaths" while trying to solve a problem using the Axis docs. I find that most of the time, I end up doing some "creative" googling to try to find an example of something that works. Trying to figure it out by looking through the Axis docs is fine some of the time, but not always. For me, if you give me a working example (not just a disconnected snippet), I can morph it into what I need.
I once was responsible for writing some training documentation many years ago, and I was told to "write it so that an 18 year old girl who just got out of high school will understand it". I was puzzled by this and questioned my boss, because we had no 18 year old girls in the organization. He said "But we could, and that is what you have to shoot for. Don't make any assumptions about what people know. If they do already know about something, they will skim right over it!". That has stuck with me all these years, and I always keep it in mind.<
/DIV>
>> libraries would have been easier to use and easier to understand. I feel
>> that Apache Axis and maybe even web services in general is
>> over-engineered and more compilcated than the alternative implementation
>> (dealing with servlets and xml).
The main reason I was told to use Axis in the first place was because of the tools, and that it was supposed to be easy to create and deploy web services. On the surface, and at the beginning, this appears to be true, but then you start having difficulties when you get further down the road. Then you start digging into the docs to figure things out...
>> much more advanced that it pays back the approach. However, if it can't
>> satisfy simple requirements then i think its a failure becuase no-one is
>> going to jump into the complicated stuff when they are first starting out.
This is so true! That is why Axis appears to be a good choice in the beginning. But the problem is that unless you are willing to spend the time to get a really good understanding of SOA, SOAP, and web services technology, it is almost guaranteed the you will have a difficult time.
There are definately NOT enough examples, and they should be closely linked (both literally and figuratively) to the docs. Pointing people to the Architecture Guide does almost no good at all. It is WAY too high level. The User Guide should be geared towards someone who knows nothing about Axis, and lead them through from start to finish on each of the major concepts that need to be understood in order to effectively use Axis. This needs to include links to ready to run functional examples that stand by themselves.
Rakesh Patel <[EMAIL PROTECTED]> wrote:
>> Overall I'd say that dealing with the underlying servlet code and xml >> libraries would have been easier to use and easier to understand. I feel
>> that Apache Axis and maybe even web services in general is
>> over-engineered and more compilcated than the alternative implementation
>> (dealing with servlets and xml).
The main reason I was told to use Axis in the first place was because of the tools, and that it was supposed to be easy to create and deploy web services. On the surface, and at the beginning, this appears to be true, but then you start having difficulties when you get further down the road. Then you start digging into the docs to figure things out...
If you are prepared for a long ramp-up before you get to stability (for your own Axis based project), then you will do ok. If you are not, then it is probably best to buy something, so you can (hopefully) get support, and resolve your issues. Even paid support is not perfect. In some cases, open source list support is better than paid support, if someone knows about or has dealt with a problem, and you get lucky in that they read and reply before your deadline looms. 8)
Rakesh Patel <[EMAIL PROTECTED]> wrote:
>> Perhaps I'm missing the poin
t. Its
when the functionality you need is >> much more advanced that it pays back the approach. However, if it can't
>> satisfy simple requirements then i think its a failure becuase no-one is
>> going to jump into the complicated stuff when they are first starting out.
This is so true! That is why Axis appears to be a good choice in the beginning. But the problem is that unless you are willing to spend the time to get a really good understanding of SOA, SOAP, and web services technology, it is almost guaranteed the you will have a difficult time.
Srinath Perera wrote:
>> If it is good architecturally .. we can fix the client API If only
>> you can provide constructive comments. Remember lot of developers has
>> different opinions about it .. some quite opposite.
>> If you comment please be constructive ..random opinions do not help anybody!!
One of the reason why there are problems getting thin gs fixed in a support group like this is because people are looking for help, and may be needing it fast! I recently saw a case where someone posted an issue in the evening, and said they needed to have it fixed by morning! This is a stretch. If the right individual just happens to check, an has the time to come up with a good response, you are very lucky. In most cases you MUST assume it will take several days for the solution to get seen by someone and responded to. This leads to people getting upset, prbably because they need to get the damn thing working! Under these conditions, it is sometimes difficult to be civil and constructive.
>> If it is good architecturally .. we can fix the client API If only
>> you can provide constructive comments. Remember lot of developers has
>> different opinions about it .. some quite opposite.
>> If you comment please be constructive ..random opinions do not help anybody!!
One of the reason why there are problems getting thin gs fixed in a support group like this is because people are looking for help, and may be needing it fast! I recently saw a case where someone posted an issue in the evening, and said they needed to have it fixed by morning! This is a stretch. If the right individual just happens to check, an has the time to come up with a good response, you are very lucky. In most cases you MUST assume it will take several days for the solution to get seen by someone and responded to. This leads to people getting upset, prbably because they need to get the damn thing working! Under these conditions, it is sometimes difficult to be civil and constructive.
Jim Azeltine
Sr. Software Engineer
SAIC
- Re: axis2 impressions Jim Azeltine
- Re: [Axis2] axis2 impressions Eran Chinthaka
- Re: axis2 impressions Todd Orr
- Re: axis2 impressions Chathura Herath
