- From: Mark Baker <distobj@acm.org>
- Date: Wed, 24 Jul 2002 12:43:00 -0400
- To: David Orchard <dorchard@bea.com>
- Cc: www-ws-arch@w3.org
On Wed, Jul 24, 2002 at 08:58:55AM -0700, David Orchard wrote: > I propose that we document the architecture of web services, at least as > expressed by SOAP and WSDL specifications. Not that we document current > practice of SOAP and WSDL. To compare, if I were to document REST as it is > done today, I'd probably ignore HTTP PUT/DELETE and I'd say that GET/POST > can be used interchangeably except for some bookmarking applications where > GET is a little better. And I'd say that CGIs are great. But we all know, > and you've pointed this out frequently as well, that an architecture can be > misused in practice. > > It's important to document the principles of the architectures, not the > practices. Though one hopes that architectures contain "best" practices. The problem with extracting architecture from specs, rather than running code, is that specs often do not say that much about how the technology should be used, and even when they do, some aspects of the system are often missed. As Roy says in his dissertation; "A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture." -- http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm So while the specifications used to build systems clearly influence the architecture of those systems, they do not define it. You have to look at how it's used at runtime. He also says this about the Shaw model, which your definition appears to be similar to (AFAICT); "What is surprising about the Shaw et al. [118] model is that, rather than defining the software's architecture as existing within the software, it is defining a description of the software's architecture as if that were the architecture. In the process, software architecture as a whole is reduced to what is commonly found in most informal architecture diagrams: boxes (components) and lines (connectors). Data elements, along with many of the dynamic aspects of real software architectures, are ignored. Such a model is incapable of adequately describing network-based software architectures, since the nature, location, and movement of data elements within the system is often the single most significant determinant of system behavior." MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com
Received on Wednesday, 24 July 2002 12:30:50 UTC