Web services and transactions

[Allan Ebdrup]

I'm using dotNet 2.0 and VS2005, I would like to have some code call several
webservices that I have written that insert data into a DB (MSSQL 2000)
inside a transaction. So that I can rollback if something goes wrong. Can I
support transactions across webservices on different frontend servers? And
if so how?
I've tried to google for it but haven't found anything yet.

Kind Regards,
Allan Ebdrup

[Allan Ebdrup]

found this article:
http://www.codeproject.com/soap/TransactionASPNET.asp
that states:
---
XML Web service methods can only participate in a transaction as the root of
a new transaction. XML Web service methods that call other XML Web service
methods participate in different transactions, as transactions do not flow
across XML Web service methods.
---

I guess I'm out of luck.

[Michael Nemtsev]

Hello Allan,

look at WS-Coordination and WS-Transaction
http://www.xml.com/pub/a/ws/2003/04/...ns.html?page=2
AEfound this article:
AEhttp://www.codeproject.com/soap/TransactionASPNET.asp
AEthat states:
AE---
AEXML Web service methods can only participate in a transaction as the
AEroot of
AEa new transaction. XML Web service methods that call other XML Web
AEservice
AEmethods participate in different transactions, as transactions do
AEnot flow
AEacross XML Web service methods.
AE---
AEI guess I'm out of luck.
AE>
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Steven Cheng[MSFT]]

Hello Allan,

Yes, as you've found in the article, XML Webservice naturally does not
support distributed transaction processing. This is due to the loose-couple
between webservice client and server(quite different from other distributed
components such as .net remoting, COM+....).

For your scenario, would you provide us some further background information
of your application(client and server...) and what's the current difficulty
and concerns in the application?

If what you want do is group several webmethod calls into a single
transaction, I think you may consider move the transaction processing from
distributed layer to server-side layer. Here are two possible approaches:

1. Encapsulate all the webmethods into a single webmethod. Thus, we can use
the .net framework's transaction support(System.Transaction namespace in
..net framework 2.0) in that single webmethod to perform transaction
processing in server-side code.

2. Still use separate webmethods to contribute the single transaction
operation, however, instead let the webmethod become a direct unit of the
transaction, we make them a proxy method which will add a record into a
certain transaction queue(defined by ourself). After all those webmethods
has been successfully called, we perform the real transaction process
through another internal method(not expsed as webmethod) to execute all the
transaction operations.

How do you think of the above options? Please feel free to post here if you
have any other ideas or any other information you wonder.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Allan Ebdrup]

"Steven Cheng[MSFT]" <st*****@online.microsoft.comwrote in message
news:nP**************@TK2MSFTNGXA01.phx.gbl...

Hello Allan,
For your scenario, would you provide us some further background
information
of your application(client and server...) and what's the current
difficulty
and concerns in the application?

I'm writing a broker that imports some data into our system and the broker
keeps track of what id's the newly inserted elements get in our system and
then saves these id's whit the externat id of the imported data, I don't
want to introduce foreign id's in my main system everything not directly
related to my system is handled by the broker that has it's own DB.

If what you want do is group several webmethod calls into a single
transaction, I think you may consider move the transaction processing from
distributed layer to server-side layer. Here are two possible approaches:

1. Encapsulate all the webmethods into a single webmethod. Thus, we can
use
the .net framework's transaction support(System.Transaction namespace in
net framework 2.0) in that single webmethod to perform transaction
processing in server-side code.

I've grouped all the inserting done into one webservice, but I still have to
save the id's of the newly inserted stuff with the externat id of the
imported data in the broker, my concern is that this fails for some reason
so that I have some data inserted in my system where I don't know what
external id this correlates to in the broker. I really want to avoid this.

2. Still use separate webmethods to contribute the single transaction
operation, however, instead let the webmethod become a direct unit of the
transaction, we make them a proxy method which will add a record into a
certain transaction queue(defined by ourself). After all those webmethods
has been successfully called, we perform the real transaction process
through another internal method(not expsed as webmethod) to execute all
the
transaction operations.

You mean something like using a global TransactionScope stored in some kind
of static variable or something like that? Shouldn't calls to a webservice
be stateless?

How do you think of the above options? Please feel free to post here if
you
have any other ideas or any other information you wonder.

What about the WS-Coordination and WS-Transaction is there support for this
in dotNet 2.0? And if so where can I find a tutorial on how to use them?

Kind Regards,
Allan Ebdrup

[Steven Cheng[MSFT]]

Thanks for your reply,

For your comments in the last message:

You mean something like using a global TransactionScope stored in some kind
of static variable or something like that? Shouldn't calls to a webservice
be stateless?
========================================
Yes, XML Webservice is not designed for complex Transaction based
processing and should be stateless for across multiple webmethods calls.
However, for your scenario, the particular scenario require us to maintain
some state and session identity information, we do not completely exclude
the use of any stateful data storage, such as a global dictionary which
maintain some data associated with a certain sessionID(to identify one of
our Transaction). Of course, we need to add additional code to maintain
such session identity table.


What about the WS-Coordination and WS-Transaction is there support for
this
in dotNet 2.0? And if so where can I find a tutorial on how to use them?
========================================
Though the "WS-Coordination" and "WS-Transaction" specification has been
defined, the current implementation of .net webservice components(ASP.NET
webservice or WSE add-on) hasn't provided implementation of them. As far
as I know, the Windows Communication Foundation in .net framework
3.0(WINFX) has provided many new generation features for interop with
webservice(such as Transactional exchange....). If your application is also
planned to migrate onto the new WINFX framework, you can keep an eye on
this.

#Windows Communication Foundation
http://msdn.microsoft.com/winfx/tech...n/default.aspx
For your current scenario, I think it would be better to use some stateful
data on the server-side to record those associated webmethod calls and
group all the transactional operations together and executed in a global
TransactionScope at server-side.

Just some of my understanding. Please feel free to let me know if there is
anything else we can help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.