You are almost right. But, don't forget that you are rather describing current implementations of SOAP stacks. SOAP itself is transport independent and good runtime should give you an API for selecting transport you want. So, this is not a matter of connection timeouts. Why not to send an email back to the client?
Moreover, callbacks should not be a matter of transport only. There is nice SOAP-RP that should fit with your callback wishes. It is drawback of current SOAP http binding that is not well designed for callbacks. On the other hand, nothing prevents you to use other transport (smtp, jms, tcp) or define your own binding to http that will be more callbacks friendly. Radovan Radovan Janecek VP, Engineering, Systinet (formerly Idoox) http://www.systinet.com ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 09, 2001 6:07 PM Subject: RE: SOAP Performance and when SOAP should be used > 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. >
