Below is the familiar breakdown of what our reference model needs to
encompass, as per our chosen definition of the term "architecture" and
within the context of an abstract framework:
1. Define elements that comprise the structure of a system.
2. Define external properties of these elements.
3. Define relationships between these elements.
4. Define the overall structure of the system.
(not necessarily in this order)
Looking at items #1 and #4, it seems that in order to determine the scope of
the abstract architecture we are documenting, we need to determine what is
meant by "system". Doing so will assist us in identifying which elements
need to be included.
As we know, one of the major differences between the two position papers
that have been submitted so far is that one includes a service consumer
while the other omits it. Because one of our goals is to deliver an abstract
reference model that defines elements common to all SOA implementations,
this raises the following question: "Does a service-oriented system require
a service consumer?" If we come up with a formal definition for "system" we
should be able to derive the answer.
Our definition of "architecture" was taken from the book "Documenting
Software Architectures: Views and Beyond". This same book provides the
following definition for the term "system":
"A collection of entities (elements, components, modules, and so forth) that
are organized for a common purpose."
This particular definition requires us to further define the "common
purpose" in order to determine our architectural scope. Additional
definitions can be found at:
http://www.google.com/search?hl=en&q=define%3Asystem&meta (or perform a
search on "define:system" at Google.com).
Thomas