RE: Software architecture

Because REST has been done after fact, doesn't mean every architecture
effort is done after the implementation.

Most people do architecture the other way(IMO, the right way), which is
before the system is built.

Hope its misunderstanding on my part, and you are not implying that
architecture should always be done after the implementation.( your word
"running code" was indicating so...)

Regards,
Sateesh

-----Original Message-----
From: Mark Baker
To: Geoff Arnold
Cc: www-ws-arch@w3.org
Sent: 9/19/02 7:47 PM
Subject: Software architecture


Geoff,

On Thu, Sep 19, 2002 at 05:40:13PM -0400, Geoff Arnold wrote:
> Your interpretation of Fielding's (somewhat ambiguous) definition
seems  
> to
> suggest that an architecture is coupled to an implementation.

No, not *an* implementation, just *implementation* in general.  i.e.
running code.  In the case of the Web, that's browsers, servers,
intermediaries, resolvers, etc..

> That is  
> certainly
> not a particular common position (though I'm sure we have all  
> encountered
> post-hoc architectures). A more common usage runs something like this:
> 
>     A software architecture describes the structural properties of  
> software,
>     typically the components and their interrelationships, and
guidelines
>     about their use.

I don't care much for that definition.  It doesn't specify which
structural properties it cares about; design-time? run-time?

> This is taken from  
> http://www.opengroup.org/architecture/adml/background.htm
> which introduces the Open Group's Architecture Description Markup  
> Language,
> part of TOGAF (which evolved from the DOD TAFIM (Technical
Architecture
> Framework for Information Management). The point is that the
components  
> and
> their structural relationships are not necessarily coupled to any  
> particular
> implementation technology. It makes sense to ask whether a particular
> system implementation *conforms* to such an architecture. You seem to
> be saying that that would be a tautology....

No no, I'm just saying that it's the running code that has to be
examined.  Sorry if that wasn't clear.

> (I have to say that I don't like Fielding's definition at all, the
more
> I look at it. Read literally, it means that an architecture can change
> from one "phase of operation" to the next. That's just plain weird,
and
> seems completely incompatible with common usage.)

The architecture doesn't change.  You just have different architectures
at different phases of operation.  Roy talks about this in section 1.1;

"In addition to levels of architecture, a software system will often
have multiple operational phases, such as start-up, initialization,
normal processing, re-initialization, and shutdown. Each operational
phase has its own architecture. For example, a configuration file will
be treated as a data element during the start-up phase, but won't be
considered an architectural element during normal processing, since at
that point the information it contained will have already been
distributed throughout the system. It may, in fact, have defined the
normal processing architecture. An overall description of a system
architecture must be capable of describing not only the operational
behavior of the system's architecture during each phase, but also the
architecture of transitions between phases."

I can understand the need for this distinction, since, for example, you
may need to improve the performance of the startup of a system, and it
would do you little good to study its architecture during normal
operations.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Friday, 20 September 2002 15:14:28 UTC