OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-ra] what is a generalized SOA RA?


Frank,

Let me go back to what I proposed 11/12/2007 but modify for Jeff and Danny's comment and some of your initial ones:

1 Introduction

Service Oriented Architecture is an architectural paradigm that has gained significant attention within the information technology (IT) and business communities. The OASIS Reference Model for SOA provides a common language for understanding the important features of SOA but does not address the issues involved in constructing, using, or owning a SOA-based system. This document focuses on these aspects of SOA.

 

1.1 What is a Reference Architecture

A reference architecture models the abstract architectural elements in the domain independent of the technologies, protocols, and products that are used to implement the domain. It differs from a Reference Model in that a Reference Model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a Reference Architecture elaborates further on the model to show a more complete picture that includes what is involved in realizing the modeled entities. While still remaining abstract, a reference architecture is more concrete than a Reference Model in that it identifies and provides a high level description of architectural components and artifacts.

 

1.x What is this Reference Architecture

It is possible to define Reference Architectures at many levels of detail or abstraction, and for many different purposes. In fact, the reference architecture for one domain may represent a further specialization of another reference architecture, with additional requirements over those for which the more general reference architecture was defined.

 

While requirements for this reference architecture are discussed in Section 2, an overview of those requirements specifies a SOA for which:

 
  • Resources are distributed across ownership boundaries, e.g. there is not a single entity that can exercise control over all identified SOA services;
  • Resources have been developed for purposes other than inclusion in a particular implementation following this reference architecture, and those resources should continue to support those initial purposes as well as the expanded access via SOA;
  • Infrastructure must be in place to enable communications through the exchange of messages and with reliability appropriate for the users and purposes for which the SOA implementation is used;
  • Security, governance, and management must be effective but consistent with multiple ownership boundaries;
  • Appropriate mediation must be available to enable coordinated use of independently developed resources;
  • [other overarching assumptions/requirements?]
 

Below, we talk about such an environment as a SOA ecosystem. Informally, our goal in this Reference Architecture is to show how Service Oriented Architecture fits into the life of users and stakeholders in a SOA ecosystem, how SOA-based systems may be realized effectively, and what is involved in owning such a SOA-based system. We believe that this approach will serve two purposes: ensuring that the true value of a SOA meeting the stated requirements can be realized using appropriate technology, and permitting the audience to focus on the important issues without becoming over-burdened with the details of a particular implementation technology.

 

1.2 Service Oriented Architecture – An Ecosystems perspective

Many systems cannot be understood by a simple decomposition into parts and subsystems. There are...


OK, at the time we discussed this I see some comments but other than the mixing of architecture and design, there was no major heartburn.  Does this work in satisfying my stated goal?  Does the goal itself not serve a useful purpose for this document?

Ken

On Dec 21, 2007, at 3:29 PM, Francis McCabe wrote:

Ken:
 Except that the wording you proposed would have directly replicated existing wording and made for redundancy.

 Personally, I think we need to move on.
Frank


On Dec 21, 2007, at 12:22 PM, Ken Laskey wrote:

Danny,

Following Jeff's point, we need to see where the proposed words fit in the Intro.  When I originated the draft, I intended for it to be part of a new section 1.x entitled "What is This RA" that sat between 1.1 and 1.2.  I didn't intend to alter (modulo other comments) the section 1.1 words on reference architecture.

In the previous email thread with Jeff, I realized the RM wording was unintentionally sloppy and suggested the TOGAF reference as a way to "clarify" the RM definition.  Jeff responded that he only supplied that for an example, and thought 1.1 was sufficient.  I'm willing to go with that being my intent was not the redefinition of reference architecture but a statement about the problem being solved by our RA.  So I am more interested in 1.x and not in rewriting 1.1.

This thread began 11/10/2007 and isn't very long, so a quick review might help all.

Ken

On Dec 21, 2007, at 3:11 PM, Danny Thornton wrote:

Jeff,

Didn't you propose the TOGAF reference?

All,

I think Jeff and I are both opposed to stating a
Reference Archicture is a design pattern because we
both see the use of design pattern in this context as
an incorrect statement.

Here are the proposed starts for the Reference
Architecture section:

Existing 0.2 draft version:
A reference architecture models the abstract
architectural elements in the domain independent of
the technologies, protocols, and products that are
used to implement the domain.  It differs from a
Reference Model in that a Reference Model describes
the important concepts and relationships in the domain
focusing on what distinguishes the elements of the
domain; a Rreference Architecture elaborates further
on the model to show a more complete picture that
includes showing what is involved in realizing the
modeled entities.

Frank's revised definition based on several RA
comittee emails and conversations:
The SOA Reference Model defines reference architecture
as “an  architectural design pattern that indicates
how an abstract set of mechanisms and relationships
realizes a predetermined set of requirements.” More
precisely, a reference architecture can be described
as an architectural pattern that provides a set of
predefined subsystems, specifies their
responsibilities, and includes rules and guidelines
for organizing the relationships between them [TOGAF
v8.1].

An explanation of an RA from Jeff but not intended to
be the definition in the RA document (Subject Re:
[soa-rm-ra] what is a generalized SOA RA?, Mon, 12 Nov
2007):
In a nutshell, a reference architecture is a reusable
asset whose purpose is to form a starting point for
architectural development.  It can take many forms,
including architectural patterns (note I did not use
the term 'architectural design' pattern),
architectural best practices, architectural
principles, architectural frameworks, etc., and,
unlike our SOA-RA effort, reference architectures are
typically proven in use.

Some suggestins from Duane:
A reference architecture is a generalized view of an
purposeful architecture that may be specialized for
one or more domains of application.  As such, a RA
often specifies the major components of a system or
systems, their externally visible properties and the
relationships amongst them in a manner abstract of
domain, technologies or specifics that would
constraint the RA from being applicable to the widest
possible scope of use.


--- "Jeffrey A. Estefan"

Frank,

As I stated before, I object strongly to this new
wordy addition.  And what
section?  Are you talking about section 1.1?

What was wrong with our opening paragraph of section
1.1?  I thought
everybody agreed it was a reasonable defn of a
reference architecture (in
the general sense) and its relationship to a
reference model.

By all means, please DROP "design" from
"architectural design pattern."
There are architectural patterns and design
patterns; not architectural
design patterns.  But again, I don't see the value
here.

I'd like to see any proposed addition or new
subsection in context with the
rest of Section 1  (Introduction) before passing any
final judgments.  It's
not clear to me what is being dropped and what is
being added.

Could you send the latest draft of the proposed
completed Section 1?

Thanks...

 - Jeff E.





---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave
the OASIS TC that
generates this mail.  You may a link to this group
and all your TCs in OASIS
at:







      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:



------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508




------------------------------------------------------------------------------------------

Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508


smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]