Hi Radovan, I also had a question regarding callbacks. I don't see how callbacks can be used currently with SOAP. If a client makes a SOAP request to the server and the process takes one hour, I can't hold the connection for that long and thus will send the request asynchronously. When the job finishes on the server, how then is my client called back and notified? I see this as a current drawback to SOAP due to the fact it isn't designed to handle these kind of requests. Am I missing something?
Thanks again, Chuck -----Original Message----- From: Ken.Crismon Sent: Friday, November 09, 2001 10:39 AM To: soap-user; janecek Cc: Ken.Crismon Subject: RE: SOAP Performance and when SOAP should be used Radovan, I very interested in the notion of Transaction as you mentioned them below. What exactly are you referring to??? Is there a group working on transaction semantics for web services and workflow??? Thanks in advance for the information. Ken Crismon RioLabs, Inc. -----Original Message----- From: Radovan Janecek [mailto:[EMAIL PROTECTED]] Sent: Friday, November 09, 2001 3:18 AM To: [EMAIL PROTECTED] Subject: Re: SOAP Performance and when SOAP should be used It is difficult to say what the performance of SOAP exactly is since all the soap stacks rely on HTTP (or other) transport. HTTP is not fast and actually it means remarkable overhead in processing SOAP messages. So, I can tell you that WASP does 500 messages per second, but this applies only to WASP's embedded HTTP server. Tomcat is much more slower, other may be faster... You probably have your own web server you want to use as a hosting environment for a SOAP stack... As for the session management, it is not a part of the SOAP spec, but reasonable SOAP stack should offer this feature and still keep transport independency. I see no problem with callbacks to clients. I agree that XML message size is a real issue. I think that the advantages are great enough to use SOAP. Moreover, SOAP is not alone. There is WSDL, UDDI, SOAP digital signatures, XKMS, ebXML (adopting SOAP), there will be workflow for web services, transactions, and many other stuff. So, I would choose SOAP because I see the future in it. The only exception (imho) is an application that really need brutal performance. Radovan Radovan Janecek VP, Engineering, Systinet (formerly Idoox) http://www.systinet.com ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 08, 2001 4:47 PM Subject: SOAP Performance and when SOAP should be used > Hi all, > > > Can anyone point me to data comparing SOAP performance vs. RMI vs. > CORBA? SOAP seems to be relatively speedy when dealing with short > synchronous requests w/very little to medium size data parameters. > I'm trying to determine given a certain architecture when SOAP would > be the proper mechanism. What I believe SOAP has going for is that > it's an open standard (as opposed to CORBA implementations varying > depending on the vendor),self describing format (XML), low runtime > overhead (I don't have to do ORB/rmiregistry monitoring), language > independence (CORBA has, RMI does not), and allows for very thin > clients (SOAP XML parsing is all that is needed). With all that in > mind there are disadvantages: At least on top of HTTP it follows a > request/reply protocol. It might not be appropriate when doing > asynchronous requests that require callbacks to the client. SOAP has > no session management ability (although we could build that > ourselves), and the usual disadvantages of XML (overhead required for > parsing, and increase in message size due to XML meta data). > > With all that in mind, I'm trying to compare the overhead performance > cost of using SOAP. Given its advantages, are the great enough to > outweigh the potential performance issues? > > Thanks in advance, > > Chuck King > > > > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
