Ken, There are a couple of efforts that address loosely coupled transactions: - OASIS Business Transaction Processing (BTP) (see http://www.oasis-open.org/committees/business-transactions/) - OMG Activity Service (see http://cgi.omg.org/cgi-bin/doc?orbos/2000-06-19
There are two JSRs: - JSR 95: J2EE Activity Service for Extended Transactions (see http://www.jcp.org/jsr/detail/95.jsp) - JSR 156: XML Transactioning API for Java (JAXTX) (see http://www.jcp.org/jsr/detail/156.jsp) Regards, Anne Thomas Manes CTO, Systinet > -----Original Message----- > From: Ken Crismon [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 09, 2001 8:39 AM > To: [EMAIL PROTECTED]; Radovan Janecek > 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. > >
