Re: [Axis2] axis2 impressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys, Let me give simple inputs for this discussion, but I'm not gonna intervene. ;-) Let me thank all of you, who were very contructive and enthusiastic to improve axis2, the project of all of us. I agree there is still some room for improvements in Axis2, especially in client api and documentations. To tell you the truth, we have allocated next couple of weeks to improve major documentations and client api. During ApacheCon hackathon we did some internal refactorings, as a first step towards this. Documentation : As I always say, this project does not belong only to the developers. As users we want your support as well. I personally thank iksrazal for coming forward and providing us with good documentation whenever required. As Jim mentioned, we developers are not good tech writers (at least me). So if possible, please help us in that. If you can look at axis2 and provide us with feedback, and come up with some good documentation, we really appreciate it. And I personally take the responsibility to publish them, if they are of good quality. Please remember that our aim is to provide what users want with users support. I agree that we can not achieve 100% satisfaction, but we need to satisfy at least a majority of them. Most of the develepors we have in Axis2 have experience in writing more than 4-5 soap stacks. So we believe in their experiences as well. So please help us in improving docs, providing docs in un covered areas, etc., Client API : Todd, if you feel like our client api is not good enough, please come up with a good proposal. We are more than happy to discuss that. Client api is what most users will be working with and these days couple of our guys are working hard to improve it. Here also, please tell us what you want. Regarding XFire and SOAP stacks : Each and every soap stack has its pros and cons. I accept that we need to compete, but we axis2 people are trying our level best to provide the most useful features. We do not have the mind set of providing features, simply XFire or other stack has it. We prioritise the features implementations depending on the user feed back and from our expert's experiences. So in this process, some features which majority of the users feel critical may not be critical for some users, which is unavoidable. So please bear with us. Rememeber one of the motivations behind Axis2 is to implement new technologies related to web services. If some thing is getting delayed, please feel free to come and help us. Let me remind you one last important thing. Personally I feel really comfortable with the features Axis2 provides and Axis2 is not inferior in any means compared to Indigo or any other SOAP stack. So I don't think any one has problems with Axis2 architecture and its features. Criticize us, comment and appreciate us. Whatever it is we appreciate it. Thanks again for all the comments. - -- Chinthaka Jim Azeltine wrote: 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 find 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
Re: axis2 impressions
I also have not found the experience of working with web services and apache axis a pleasurable one. I'm glad my project has been put on hold because the learning curve is so steep. Here's a few issues I have had: 1. Initially I started out using the Sun reference implementation and installed the extensions to my Sun ONE instance. This had performance and memory implications on the server. I switched to Apache Axis instead. 2. The whole arena of web services is compliated because of so many changes over so little time. I found a few tutorials on the net but if they were in 2002 you never knew if it was the right way to do things now. 3. 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. 4. The touted tool support is a double-edged sword because you need to know what they are doing to enable debugging but you don't have enough knowledge at a low level. For instance, when i tried the upgrade from 1.2--1.3 by replacing the axis jar, my ant tasks failed (wsdl2java/java2wsdl) . I had no idea where to begin to solve this. 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). Implementation A 1. code a servlet to transfer xml. 2. Use something like JDOM to create/read/update the xml. 3. Use web container functionality such as session timeout, user management and ssl. Done it before many times Implementation B 1. Learn Apache Axis and add to your app. 2. Work out how to use and intergrate the tools into your build process. 3. Learn the myriad ways to do everything such as security and transfer modes and rpc and filters and exceptions etcetcetc(and then watch them change). A is easier when you have to get the job done. Perhaps I'm missing the point. 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. Sorry for the rant but i thought I should give some feedback. Rakesh Srinath Perera wrote: Hi Todd; Are referring to Call/MEPClient API or Generated Stubs. We do not force you to use the OM* API unless you need XML level support. You can use the generated Stubs and Client s and work with out seen a OMElement at all. Q) are you happy with Axis1.x API? what you had there and missing at Axis2 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. Tell us 1) Exactly in detail what are the problems? 2) What your expected scenarios .. with example may be 3) Suggestions to how to fix current API If you do, we can discuss and improve Axis2, if you arguments are reasonable we love to make the fixes. On the other hand if the Xfire serve you better please go for it. If you comment please be constructive ..random opinions do not help anybody!! Thanks Srinath On 12/15/05, Todd Orr [EMAIL PROTECTED] wrote: The more I learn about Axis2, the less appealing it is. It seems to be giant leap backwards. Why is coding using OMElement (and the other OM... objects) a better approach than deploying a POJO? This is a huge pain. Not to mention the deployment issues that I've already run into. Based on the documentation I feel as though Axis2 is a step forward architecturally, but extremely weak in user friendliness. For this reason I've been finding myself more interested in XFire. It has many features of Axis2, yet is extremely easy to create Web services with. Why would the Axis2 team go in this anti-productivity direction?
Re: axis2 impressions
We build with maven and have a simple goal that iterates through the project'sdependencies and copies them all into the lib folder of the axis2 webapp. Another goal removes them. This is pretty easy to do and frees you fromhaving to worry about modifying the axis2 war file.We use JBoss4 and Ant. In our environment, we would still have to alter the deployed war unless we either built axis2 each time, or un/re-packaged the war each time. This situation is less than ideal. Even if this is a headache for my release engineer and therefore is mitigated to one resource, it still pales in comparison the to developer productivity drawbacks stated. On 12/15/05, Alex Artigues [EMAIL PROTECTED] wrote: 5This new approach is incompatible with my company's build scripts. Automating the build seems to be a hassle. I do not even see a nice way to do this - explode the war, build and deploy my aar files to the exploded war, then repackage? Ugh.We build with maven and have a simple goal that iterates through the project'sdependencies and copies them all into the lib folder of the axis2 webapp.Another goal removes them.This is pretty easy to do and frees you from having to worry about modifying the axis2 war file.--Alex
Re: axis2 impressions
As someone who has worked alot with axis 1.x and axis2, allow me to put my 2 cents in... Em Quinta 15 Dezembro 2005 13:49, o Todd Orr escreveu: You're right. Random comments are not helpful. In general, however, Axis1 was far easier to get a working app up with. 1.I was mainly taken by surprise by the OMElement approach that is explained in the user guide's own implementation ( http://ws.apache.org/axis2/userguide.html#Web_Services_Using_Axis2). If this is a special case, then it shouldn't be the only one in the user guide. I didn't find anywhere that I could just deploy a POJO (with minimal metadata in the wsdd) as I can with Axis1. Its open-source, feel free to document it. I personally needed a WSDL2Java ant task with axis2, and once I figured it out how to do it I was invited to document it, which I did. I personally found the OMElement approach easy enough to undersatand to get started without wsdl. Digging deeper you'll find the Call interface still there. WSDD is IMHO far inferior to the services.xml / aar / hot deployment approach, and one of the reasons I moved to axis2. 1.1 Perhaps number 1 is completely wrong. If so, the documentation needs to point this out. If my experience thus far is unfair it is because the documentation is incomplete (expected early in the project) at a minimum, and from my personal experience it is misleading (unacceptable). 2. I feel as though the need to work with WSDLs directly is a failing of the implementation (whichever implementation). Ideally the situation should be that there are times in unusual circumstances that you might need to work with the WSDL directly. The majority of Web service deployments should be as simple as providing metadata via XML or annotations that handle the type of things that you would need to alter the WSDL for. It seems that Axis2 is no further away from this than Axis1 ever was. If anything it further perpetuates this anti-productive vein of thought. The documentation is rife with references and how-tos relating to WSDL2Java. This is backwards thinking and it permeates both Axis1 and 2 users/developers. I work with objects. We all, as Java developers, work with objects. Java developers are most productive when working with objects, in general. I'm not trying to start a flame war on this subject, but whenever I hear, oh you need to edit the WSDL to do this or that I cringe. It's not that I can't. It's that I shouldn't have to. If you think I'm wrong, look at ejb2 vs ejb3 in regards to the various xml files. Same story, different project. Even then, I contend that ejb deployment descriptors are easier to work with than WSDLs. WSDL is a major fact in web services development - I don't see it as a being unusual circumstances at all. The OMElement stuff allows you to avoid wsdl just like Call.invoke() can. WSDL has a lot of power behind it. It may be difficult now, but with a little effort learning it soon it won't be. If you want to work with objects, then Complex Types and WSDL should be a natural fit. Once I learned how to use java.util.List with wsdl to represent my data, along with my customs types, there was no turning back. I've actually even used EJB with WSDL together - alot. There are a lot of files to touch, buts its only hard for a few days and then its easy. Then again, wsdl is not mandatory. I actually spent my first 2 years doing web services without wsdl. When it became a requirement I cringed. After a few weeks I started to like it. 3. JRS-181 is awesome. After using XFire's implementation, I do not know if I will be able to go back to a non-annotated world. Then use XFire and be happy. I haven't got to JRS-181 - all in due time. 4. Poor out of the box support for other frameworks (eg Spring). I would like to be able to manage my Web services like any other bean in a webapp. I'm sure if I hack away I can manage to put something specific to my project together, but then there will be hundreds of homegrown implementations that no one body has knowledge of or is responsible for. Axis2 does not live in a vacuum. There's a lot of frameworks out there. It'd be nice if the project recognized and supported this idea. There is support for spring - I'm a dedicated, happy user of spring. http://marc.theaimsgroup.com/?l=axis-devm=112866697704950w=2 I personally use the ObjectFactory approach as we have an existing app. I'd like to see Spring documented but not too many people have been asking for it. 5. Weird deployment model. I guess that having a JEEish packaging scheme is a good thing. However, I've lost all the benefits of creating a war of my own for my services. I can no longer specify my own url-mappings without editing the axis2.war, which is not in my source control (and shouldn't be). This new approach is incompatible with my company's build scripts. Automating the build seems to be a hassle. I do not even see a nice way to do this
Re: axis2 impressions
Em Quinta 15 Dezembro 2005 14:11, o Todd Orr escreveu: We build with maven and have a simple goal that iterates through the project's dependencies and copies them all into the lib folder of the axis2 webapp. Another goal removes them. This is pretty easy to do and frees you from having to worry about modifying the axis2 war file. We use JBoss4 and Ant. In our environment, we would still have to alter the deployed war unless we either built axis2 each time, or un/re-packaged the war each time. This situation is less than ideal. Even if this is a headache for my release engineer and therefore is mitigated to one resource, it still pales in comparison the to developer productivity drawbacks stated. I don't get it. Got your own war? in your war ant task put another dir under WEB-INF called services. Build a jar with an aar extension and plop it in. Move the axis2.xml file into your WEB-INF. What's so hard about that? Took me an hour or so with a bigger than average project and a 1000 line build.xml . As stated - call me strange but I feel more productive with axis2. Being constructive, I'd give some hints with your build.xml if you need it. Also as stated, its just new to you. Soon it won't be if you spend a little effort. I personally feel I've gained from axis2. Give it a shot and then decide. iksrazal On 12/15/05, Alex Artigues [EMAIL PROTECTED] wrote: 5This new approach is incompatible with my company's build scripts. Automating the build seems to be a hassle. I do not even see a nice way to do this - explode the war, build and deploy my aar files to the exploded war, then repackage? Ugh. We build with maven and have a simple goal that iterates through the project's dependencies and copies them all into the lib folder of the axis2 webapp. Another goal removes them. This is pretty easy to do and frees you from having to worry about modifying the axis2 war file. --Alex
Re: axis2 impressions
Em Quinta 15 Dezembro 2005 15:14, o Nathaniel Auvil escreveu: Can you email me with how you got axis2 to work from wsdl? I have two open Jira items on this as it blows up on my wsdl. The first problem is due to schema imports. So i eliminated the schema imports and now i get a schema exception from XMLBeans. This schema works fine with Axis 1.2.1 and is valid XML according to XMLSpy. quote Its open-source, feel free to document it. I personally needed a WSDL2Java ant task with axis2, and once I figured it out how to do it I was invited to document it, which I did. I personally found the OMElement approach easy enough to undersatand to get started without wsdl. /quote We're going to need a little more info then it 'blows up' to help ;-) . First, its got to be more than just valid xml, its got to be a valid wsdl. Google for the 'free as in beer' soa editor from cape clear. The XMLBean issue I think you have is documented here: http://ws.apache.org/axis2/CodegenToolReference.html There's also a sample wsdl and code. The sample is a little rough - I've been making a transition from 'rpc encoded' to doc / lit . Nevertheless, it is a fully working sample. HTH, iksrazal
Re: axis2 impressions
Dear Todd, Thank you for the feedback we do appreciate it so pls keep it comming. I have included some comments regarding some things with significance that you have pointed out 1) The reason for having the OMElement instead of the POJO is axis2 engine is based on the StaX API. At least for me OM looks nicer than meddling with the StAX events. So OMElement has very good advantages (very much beyond simple easyness) than you might comprehend. Problem with POJO is that it cannot be serialisable directly to the stax and we don't have a such typemapping mechanism now. There are ways to fix this if you can write a Serialiser that push stax events. 1.1) Bad documentation!!! Well it isn't the best but it gives an understanding for many. Help with documentation is always warmly welcomed. 2) Well Java2WSDL tool is on the way. Understand this we haven't reach the Version 1.0 mark yet. So we are not calling this a finish product and there are things to finish. 3)I personally would like to get the annotations but there are other prorities in the SOAP processing model that we need to fill up. The expectations of the different users of Axis2 is different, but we try to prioratise the most general user requirement. Thanks Chathura P.S. Btw, I am (as a an Axis2 developper) not interested in promisses that you are going to keep in a hypothedical opensource product that you are gonna release. On 12/15/05, Todd Orr [EMAIL PROTECTED] wrote: Its open-source, feel free to document it. I've been having trouble even being able to come up with an implementation to prove that it can be done. I cannot sell my boss on RD to hack through the internals to figure out exactly what is happening. I've only been allocated time to compare and contrast alternative implementations. All frameworks should understand that their end users (me) are not always in the position to do the research and documentation for them. If I had that kind of time, I'd start my own open source projects. I've got lots of things I want to do for the community too. I just have a demanding job. I know that the Axis team also have jobs too. The difference is that I am not open sourcing a project for general consumption. It's a much appreciated effort - don't get me wrong. Its open-source, feel free to document it. I personally needed a WSDL2Java ant task with axis2, and once I figured it out how to do it I was invited to document it, which I did. I personally found the OMElement approach easy enough to undersatand to get started without wsdl. Digging deeper you'll find the Call interface still there. The call interface is not really what I'm talking about. I prefer writing a POJO that has no knowledge that it is a Web service endpoint. I have done this with Axis1. WSDD is IMHO far inferior to the services.xml / aar / hot deployment approach, and one of the reasons I moved to axis2. Agreed. ...I actually spent my first 2 years doing web services without wsdl. When it became a requirement I cringed. After a few weeks I started to like it. I have nothing against WSDL. I work with them now in Axis1. The problem is not one of expertise or developer knowledge. It is an issue of necessity and developer ramp up. There is very little (any?) information in a WSDL that couldn't be maintained in a more straight forward metadata language (annotations, service.xml?). The best Web service implementation should alleviate this headache. It's not a matter of how hard or easy it is. It just shouldn't be there if the framework went the extra mile for the developer. Then use XFire and be happy. I haven't got to JRS-181 - all in due time. Understandable. http://marc.theaimsgroup.com/?l=axis-devm=112866697704950w=2 I've already attempted to use this. Besides the fact that it doesn't address my issue with homegrown implementations, it doesn't work. I've deployed it to my axis2 installation via the Web interface and in is faulty. I would say novel and clever instead of weird. I might say divergent from known standards and applications. I never used AdminClient anyhow. I dropped the axis jars into my webapp, configured my web.xml and was off and running. All the while my company's build scripts worked flawlessly. That's expected, standards based behavior. You could start by documenting alternatives to OMElement - my guess is that if its good it'll get accepted. Just file a jira when you're ready. Honestly, I want to help out. In an ideal world I wouldn't have to go to work all day and participate in my family at night. It's just not feasible. If my company ever releases a software product for general consumption, I will work to ensure that the complaints I have risen here do not happen in regards to my product. That's a promise I can keep. On 12/15/05, iksrazal [EMAIL PROTECTED] wrote: As someone who has worked alot with axis 1.x and axis2, allow me to put my 2 cents in... Em
axis2 impressions
The more I learn about Axis2, the less appealing it is. It seems to be giant leap backwards. Why is coding using OMElement (and the other OM... objects) a better approach than deploying a POJO? This is a huge pain. Not to mention the deployment issues that I've already run into. Based on the documentation I feel as though Axis2 is a step forward architecturally, but extremely weak in user friendliness. For this reason I've been finding myself more interested in XFire. It has many features of Axis2, yet is extremely easy to create Web services with. Why would the Axis2 team go in this anti-productivity direction?
