Not over http anyway. Perhaps using smtp or some type of messaging middleware as the transport.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 09, 2001 11:07 AM > To: [EMAIL PROTECTED] > 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. >
