W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

RE: "Reliable" web services for Next Big Thing?

From: <jones@research.att.com>
Date: Thu, 5 Dec 2002 13:21:07 -0500 (EST)
Message-Id: <200212051821.NAA19792@bual.research.att.com>
To: Mike.Champion@softwareag-usa.com, edwink@collaxa.com, walden.mathews@tfn.com, www-ws-arch@w3.org

	From: "Edwin Khodabakchian" <edwink@collaxa.com>
	To: "'Mathews, Walden'" <walden.mathews@tfn.com>,
	        "'Champion, Mike'" <Mike.Champion@softwareag-usa.com>,
	        <www-ws-arch@w3.org>
	Date: Thu, 5 Dec 2002 08:54:18 -0800
	Subject: RE: "Reliable" web services for Next Big Thing?

	+1. Well said.

	We have gone through the same mistakes and learning curve. The
	infrastructure that certainly help by encapsulating disconnected
	interactions and retries but exception and timeout management has to be
	replicated/done at the application level for the reasons highlited by
	Walden. Please note that this is true even in the case where you use
	SOAP over JMS. We run into this problem in every customer deployment.

	Edwin

My hope is that we can sort out those aspects of reliable messaging
that benefit from standardization whether at the transport protocol,
SOAP binding level (reliability feature), the SOAP module level, or
generalized solutions for the application level.  DavidO suggested
some headers that might hit some 80/20 sweet spot, for example.  I can
imagine that there are aspects that are best managed by software at
the application level (although even here one would hope there are
reusable design patterns), but it doesn't seem useful to assume that
every application must entirely reinvent reliability for itself.

--mark

Mark A. Jones
AT&T Labs -- Strategic Standards Division
Shannon Laboratory
Room 2A-02
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
  fax: (973) 236-6453
Received on Thursday, 5 December 2002 13:21:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT