- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Thu, 9 Jan 2003 09:01:33 -0700
- To: bhaugen <linkage@interaccess.com>, www-ws-arch@w3.org
> -----Original Message----- > From: bhaugen [mailto:linkage@interaccess.com] > Sent: Thursday, January 09, 2003 10:36 AM > To: www-ws-arch@w3.org > Subject: RE: Proposed text on reliability in the web services > architecture > > > (I know people are putting the things directly on the Web > here and there, but it won't last long.) > > My point is that regardless of external communication style, > the legacy ERP app will need adapters and mediators, > but will not need to be redesigned from the ground up. Ahh ... good point. I'm a bit out of my depth here. My guess would be that it is considerably easier to write adapters and mediators that don't change fundamental architectural principles. Maybe I'm missing something myself, but it's *hard* to design systems that use the resource/representation trasfer model, use safe retrieval and idempotent update, etc. if you're used to ordinary OO design. I can much more easily imagine writing an adapter that simply serializes objects as XML, interfaces with an app server to maintain state, etc. than I can imagine writing an adapter that presents a view of the objects as resources with representations that get transferred around. If there was an easy mapping from one to the other, I would have thought that the debates over the last year would be much easier :-) But I could well be wrong ... and as Paul Prescod has noted, there's not a lot of conceptual difference between REST and DBMS programming where records get created, read, updated, and deleted, and where applications can't just blithely assume that everything will be magically taken care of by the infrastructure. I don't want to exaggerate the difficulty, just note in the WSA that a) it's non-trivial; b) not widely understood; and c) not by any means the path of least resistance given todays tools.
Received on Thursday, 9 January 2003 11:02:17 UTC