Just my two cents - my personal experience and opinion. As a newbie to SOAP, and in the stage of investigation of a new interface of our software, I ran into a number of issues that Kurt mentioned, and I can therefore undertand his frustrations quite well. Our application already has very stable, very simple connections with other applications, both as server and client. Some use XML, some use fixed messages, but all over dedicated TCPIP ports. This time though, we were faced with an existing .NET application, so SOAP was the obvious choice for cummunication. It took me a few weeks to get some understanding of the protoctol and facilities, and to get at least something working (.NET on Windows (client) to Axis on VMS (Server)). At the moment, there is a (very basic) service working.
I can fully agree that SOAP is complex; far too complex for a actually rather simple problem: how to interconnect different applications, different styles on different platfoms in a standard way. It will have flaws, there will be some complexity, no doubt, but IMHO the main problems are much, much more basic. The idea for ONE IP port used for interaction of any system with any other system is great. In fact, that's what webservices are all about. The big problem, as I see it, is that the used HTTP protocol was never designed for this kind of interaction, nor is the http server (bacuse of that). HTTP is a protocol for document delivery. Nothing more than that. When Java support was added, that needed a separate handler - in case of Apache, Jakarta (Tomcat); used to be able to create dynamic content, conditional delivery - whatever. Once code could be executed from a web-page, it was possible to pass information the other way as well, and SOAP was developed - as an extension on the Java engine, and AXIS is one implementation of that protocol. Now there is this chain of protocols, that are partly incompatible; None of the protocol has knowlegde of the other. What is worse: there are different implementations of each, so you may face incomptability between implementations... This makes it all too complex - so complex you NEED tools to create interfaces, code, documents etcetera you need to be able to exchange information. I know enough programmers that just rely on their IDE and have no clue how all files interact. They are LOST, if they don't have the IDE at hand. What I think is needed is one, consistant and strictly described protocol to define, create and handle webservices. This protocol should be completely platform-independent (platform to be read as "operating system", "development environment", "executing environment" - all the same). That IS possible, I worked with something similar 10, 12 years ago. Another important issue that I read in Kurt's complaints, is the incompatibility of different Java versions. I've seen it quite a number of times, that an application, written in some version of Java, simply didn't work with a higher one. It's for that reason that some applications come with the runtime of the java version it was built in. I have seen the same issue with a number of open source applications, where upgrading to a new version requires a redo of the configuration - a complete different format sometimes, different terminology sometimes. Documenation is another thing. If it exists (and alone that is already a problem) it should be clear and consistent. It often isn't: It's full of jargon, too much omissiopn of knowledge, therefore hard to understand for newcomers, and asking the community is not always a help: it takes too much time to filter what's usable and what's not, and to give things a try and find out why it doesn't work; It's a good way of asking more specific things, not the basic ones. But you NEED to if documenation is simply missing. New developments are often said to be "new technology" and are often marketed as "the answer of all problems". They are used and brought into production before it is well understood, designed, written, tested and dcoumented, and becomes a 'de facto' standard - with all the omissions, false premisses, flaws and bugs that could have been prevented otherwise. But they are seldom "new", just new modernized implementations of scarcely known existing algorithms and theories; and marketing uses today's issues stating it's advantage, but who is willing and able to look beyond do understand these arguments are non-issues and bogus. And the marketed product seldom is "the right answer"; in most cases "One of many answers". I do not want to predict whether the application will be web-serviced using SOAP. We might use another, much simpler interface. SOAP is tempting just because of the challenge. But I do fully agree that where misison critical communication is involved, SOAP might surely be a BAD solution - because of the issues described. It might be a good reason to abandon SOAP all together and develop our interface. Just MY opinions. I can only hope others share them. Willem Grooters OpenVMS developer & system Manager -----Oorspronkelijk bericht----- Van: Davanum Srinivas [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 28 oktober 2005 5:07 Aan: [email protected] CC: [email protected] Onderwerp: Re: I give up Kurt, Looking at your postings, i don't see much from you in terms of engaging the user or developer community to ask for help. http://marc.theaimsgroup.com/?l=axis-dev&w=2&r=1&s=olsen&q=b http://marc.theaimsgroup.com/?l=axis-user&w=2&r=1&s=olsen&q=b Your specific email to Tom (http://marc.theaimsgroup.com/?l=axis-dev&m=112801670512125&w=2)...i have no clue how to help. i did reply back to a prev mail on that thread (http://marc.theaimsgroup.com/?l=axis-dev&m=112692662128194&w=2) If you have a problem with Macromedia or eBay folks, We can't really help. If you have a problem with latest releases of Axis, we can help if you add JIRA bugs (and chase us!) on the axis-dev@ list. If you need production/development support, there are avenues for that as well. Am sorry you had a bad experience, thanks for the feedback. -- dims On 10/27/05, Kurt Olsen <[EMAIL PROTECTED]> wrote: > > > > Folks, I hate to say it but I had to ditch axis. Way too difficult. And we > won't be using it in the future. > > > > Our application has approx 30 vendors we communicate with using SOAP. > > Approx 25 of them are implemented by simply creating strings and firing them > off, then parsing out the reply. > > Primitive but fairly easy to do. > > > > The other 5 used axis. At the moment we're using the ColdFusion server. When > we upgraded to java 5 and coldfusion mx7 our axis based connectors broke. > > It took approximately 2 weeks to diagnose and 'solve' the problem. Axis used > commons-logging, and commons-logging broke. That required fairly > > major surgery to the coldfusion classpath. Pieces of commons-logging we're > coming in off of different classloaders. > > > > So technically speaking, commons-logging broke - not axis but…..since axis > brought the flaw to life, and has given us grief (probably the CF > integration) in the past, it is axis that got the bad reputation due to the > fact that it was at the top of the food chain. The two weeks solving this > problem wasn't totally wasted because it exposed a fairly large flaw in the > overall architecture. > > > > After getting the existing connectors to work again, I had to turn my > attention to the next connector in the pipeline – eBay via Soap…. > > Only one problem – eBay's sdk is written against java 1.4 and axis 1.1 – > while we upgraded to java 5 and axis 1.2 > > After another week of trying various 'workarounds' etc I was forced to give > up and will have to communicate with eBay using the "create strings" > technique. > > > > Bottom line is that the overall cost of the 'SOAP' system and it's co-horts > in crime is un-managable given our quarterly release cycle. > > I'm disappointed that after all that effor to modernize – the goal really > wasn't accomplished. > > > > I fully understand the various issues involved, most of which aren't really > axis's fault but – any way I slice it this entire exercise felt exactly like > trying to use the J2EE 1.3/1.4 ejb specifications. Big, confusing, hard to > use etc…..And I predict will eventually be abandoned (or at least buried > beneath a convienence API). > > > > This is just one co's experience of course but I submit to you that as you > continue your development you might want to consider the overall 'cost' that > SOAP and it's tools are exacting on the community. This simply has to get > easier because as it stands both the other developers (who watched over my > shoulder so to speak) and myself have simply given up on an 'easy' tool fix. > Our experience is that SOAP is a diaster and costing virtually everyone in > corporate programming a lot of money and lost sleep…. > > > > Thanks for listening, and please remember that I'm taking the time to write > this not to complain (well, maybe a little) but to provide feedback from the > field. > > > > Respectfully, > > Kurt Olsen > > > > > > -- Davanum Srinivas : http://wso2.com/blogs/ Disclaimer: The information contained in this E-mail and its attachments is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance of the contents of this E-mail and any attachments is strictly prohibited and may be unlawful. The CIP or ISC is neither liable for the proper and complete transmission of the information contained in this E-mail and any attachments nor for any delay in its receipt. If received in error, please contact The CIP or ISC on +31(0)522 722222 quoting the name of the sender and the addressee and then delete it from your system. Please note that the The CIP or ISC does not accept any responsibility for viruses and it is your responsibility to scan the E-mail and attachments (if any). No contracts may be concluded on behalf of The CIP or ISC by means of E-mail communications.
