RE: Transactional Web Services ? (was: a very long subject with w eirdspaces inside)

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

I agree that the problem is scalability, but it's the same problem whether
you're using web service or not (e.g. using CORBA or EJB). The utopian dream
in which business find each other through UDDI, learn each other languages
through WSDL and talk to each other through SOAP is all well, but I'm not
going to even begin to think about business implications if there is no
transactional capabilities behind.

Speaking or resource locking, we have encoutered interesting problems
developing contextual web services. In contextual web services, a context is
created on the server side in which all request from the same client will be
performed (a context is a session). This is useful for example in our
Exchange web service interface : we don't want to create a CDO session for
each request sent by a client, so we create a server-side context containing
the CDO session on the first request, and reuse it again and again until we
receive a "close" request.

The problem is that since HTTP is a stateless protocol, we are not notified
when then client fails, so there are possibilities that some resources are
never freed. So we implemented support for resource leasing in our SOAP-like
protocol, just like in RMI or Jini, to work around this problem. This way,
unused resources are automatically freed avec a timeout period.

I'm not sure that contextual web services are a good idea to generalize, but
the point is that we needed them for a set of projects. Does anyone else
implement/use such web services ?

Regards,
Nicolas

>-----Message d'origine-----
>De : David Orchard [mailto:orchard@pacificspirit.com]
>Envoye : jeudi 23 aout 2001 01:19
>A : Nicolas LEHUEN
>Cc : ''xml-dev' '
>Objet : RE: Transactional Web Services ? (was: a very long subject with
>weird spaces inside)
>
>
>Hi Nicolas,
>
>The problem with 2pc over the web isn't whether it can be done or not. 
> That's easy.  The problem is whether it can scale.  One of the huge 
>advantages that the web has over every distributed object 
>protocol is that 
>a client doesn't lock resources on the server.
>
>If you offer web services where a client can lock resources, you can't 
>scale the same way that the web currently does.
>
>Database connections are one example.  It most web systems, 
>you multiplex 
>many incoming client request through database connections.  A typical 
>scenario might be 30 database connections serving potentially 
>hundreds of 
>web server threads.  But you can never scale the database 
>connections as 
>fast as your web server threads.  And you almost always have 
>to restart 
>your db connection when something goes wrong with the 
>connections, as the 
>database has a really tough time reclaiming "lost" connections.
>
>The same applies to web services, in that 2pc locks resources for a 
>potentially long time and you don't know when a client goes away.
>
>Cheers,
>Dave
>
>On Wednesday, August 22, 2001 3:57 PM, Nicolas LEHUEN 
>[SMTP:nicolas.lehuen@ubicco.com] wrote:
>> Thanks for the pointer, I'll have a look at it.
>>
>> I once implemented a custom version of RMI that included a 
>2PC protocol
>> (which a transaction coordinator and all). The wire protocol 
>was just a
>> one-way, peer-to-peer message sending system. Messages were 
>serialized 
>Java
>> objects. I did all this in order to better understand CORBA, RMI and
>> distributed transactions.
>>
>> I based all the transactional parts on my reading of two 
>books, one being 
>a
>> french book, the other being "Concurrent Programming in Java, 2nd 
>Edition"
>> from Doug Lea (Addison Wesley), chapter 3.6. From those 
>books I learned 
>that
>> transactions and 2PC are not voodoo. In fact the methods and 
>requirements 
>to
>> build a transactional system are not complicated (though they can be
>> expensive to put in practice).
>>
>> Anyway, the conclusion is that you can implement a distributed 
>transaction
>> system with 2PC on a one-way, peer-to-peer messaging protocol.
>>
>> The current web services infrastructure is of course not 
>ready for this, 
>but
>> it'll have to tackle with the problem and solve it.
>>
>> Regards,
>> Nicolas
>>
>> -----Message d'origine-----
>> De: David Orchard
>> A: 'xml-dev'
>> Date: 22/08/01 22:45
>> Objet: RE: "Uh, what do I need this for" (was RE: XML.COM:  
>How I Learne
>> d t o Love daBomb)
>>
>> <mondo snip/>
>>
>> You presume that transactions between web services is a good and
>> possible
>> thing.  Most people think of 2 phase commit when they think
>> transactions,
>> and I have serious doubts about that.  Satish Thatte wrote a good
>> position
>> paper referencing this, http://www.w3.org/2001/03/WSWS-popa/paper39.
>> One
>> summary would be that 2PC doesn't for web services.
>>
>> If you mean long-running or compensating transactions, then 
>I agree that
>>
>> transaction support will be required.
>>
>> Cheers,
>> Dave
>>
>> >
>> > Note that we have a bigger problem which is the non-support of
>> transactions
>> > by the current web services protocols. We use a kind of 
>architectural
>> > workaround for now (based on the fact that we "only" implement an
>> > aggregation and presentation layers), but there is no doubt
>> transaction
>> > support will be required one day.
>> >
>> > That's the reason why I am kind of skeptical about a 
>transactional B2B
>>
>> use
>> > of web services with the current technologies. But as a distributed
>> > transaction relies basically on the propagation of the couple
>> {transaction
>> > monitor ID,unique transaction ID} accross processes, I don't think
>> this
>> is
>> > something that can't be done with SOAP.
>> >
>> > Regards,
>> > Nicolas
>> >
>> > -----------------------------------------------------------------
>> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> > initiative of OASIS <http://www.oasis-open.org>
>> >
>> > The list archives are at http://lists.xml.org/archives/xml-dev/
>> >
>> > To subscribe or unsubscribe from this elist use the subscription
>> > manager: <http://lists.xml.org/ob/adm.pl>
>>
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>>
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>> To subscribe or unsubscribe from this elist use the subscription
>> manager: <http://lists.xml.org/ob/adm.pl>
>