RE: Where do we find software architecture?

I don't think it's reasonable to compare the ws-arch process with the web
arch process.  Roy's thesis was published well after the web was deployed.
By your argument, we can't talk about architectures until they are
deployed - which means extensible architectures like SOAP 1.2 can't be
talked about.  And we can't actually give any guidance to the implementors
of the components in the architecture.

My concern is that you are trying to set the bar too high for newer
specifications like SOAP 1.2.  Given that you don't think there is an
architecture in SOAP or WSDL [1], I understand why you are taking this tact.

I find your quote from Roy baffling.  I think I understand Roy's quote.  In
the editors version of the ws-arch document that I'm working on, I suggested
following the identifiers/formats/protocols style of the TAG doc in our doc.
I *really* want the ws arch document to naturally flow from the TAG document
(my own personal success factor and requirement).  From this, we can define
additional formats and protocols for newer web services standards, like
security.  So I want to talk about data elements and I'm prepared to propose
or talk about them in whatever forum is expeditious and appropriate.  I fail
to find logic in why you quoted Roy's thesis as I do not believe I am
suggesting anything that contradicts it.

Sure, we start with components and connectors, but we need to quickly move
on and define the data elements, among other things, in case you are going
to point to some introductory material on soap/wsdl.

I do observe that Roy published his thesis in the year 2000, by which time
the web, with best and worst practices, were implemented.  Relevent formats
were well established - RFC 1738 was published in Dec '94.  OTOH, our
software products have just had their first iteration of WSDL support and
nobody has full SOAP 1.2 support.  And we have barely started discussing XML
extensions to SOAP/WSDL.

Like I've said before, I would rather focus on writing and talking about web
services architecture documents rather than wrangling over process of
getting to those documents.  I have volunteered to contribute to such
writing efforts.  Perhaps we should terminate this conversation and simply
ask for a vote in the group.

Cheers,
Dave

[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Jul/0204.html


> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, July 24, 2002 9:43 AM
> To: David Orchard
> Cc: www-ws-arch@w3.org
> Subject: Where do we find software architecture?
>
>
> 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 18:51:50 UTC