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

[Francis McCabe <frankmccabe@mac.com>]

Ken
  Overall I like it. With a couple of minor quibbles and additions:

1. I think (and have always done so) that the primary goal of SOA is  
to enable safe and effective action across ownership boundaries. I am  
aware that the rest of the committee does not like the term 'safe',  
but 'assurance' seems mealy mouthed to m; still I can live with  
assured. To me, this counts as the overarching requirement.

2. We never discussed the issue of ensuring that legacy systems are  
'unimpacted'. I think that that may be a worthy goal, but I suspect  
that, in practice, there are bound to be impacts on such systems. I  
would prefer more positive language, along the lines of enabling  
legacy systems to be used in new potentially previously unplanned  
applications and situations.

3. Putting messaging up front like this does not seem right. Messaging  
is a requirement for our version of SOA; but is not itself a  
requirement that SOA is intended to address!

4. I would fold the governance and mediation into a single bullet, and  
maybe separate out management.

Frank



On Nov 12, 2007, at 9:55 AM, Ken Laskey wrote:

> Frank, Danny, Rex, and everyone else,
>
> I looked at the email traffic and then went back to the beginning of  
> the RA draft.  In an effort to get to the point quicker and answer  
> the MITRE questions, I'm submitting the attached edits (some  
> wordsmithing and the added section 1.x.) for your consideration.   
> (The Word doc tracks changes; the following paste just shows the net  
> results.)  This would also serve as the response to the MITRE  
> question.
>
> 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
>
> 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.” 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 the use of those resources in such an  
> implementation must not negatively impact those initial purposes;
> 	• 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...
>
>
> Note, the RA we are writing would be relevant to the Navy SOA but  
> the Navy one will likely have more requirements, e.g.  for  
> supporting disconnected ops.  This is an example of the Navy RA  
> being a further specialization of a more general one.
>
> Ken
>
> <this RA.doc>
>
> On Nov 10, 2007, at 5:21 PM, Francis McCabe wrote:
>
>> I think that for any given application there are going to be  
>> elements which are 'infrastructural' in nature, and elements which  
>> are 'to the point'. What disappoints many managers is the ratio of  
>> the two: they would prefer not to invest in any infrastructure at  
>> all; however, professionals realize that the ratio is often 90%  
>> infrastructure to 10% application specific.
>>
>> With that in mind, it would not surprise me at all if there were  
>> large chunks of the Navy's version of SOA that are not really  
>> specific to the Navy at all (although their requirements may well  
>> drive the infrastructure to a v. large extent).
>>
>> Something like this: the Navy requires security and provenance  
>> management (say); for good reasons. But anyone who also has similar  
>> requirements will have to solve similar problems: provenance for  
>> the Navy is not that different to provenance for the Citi group.
>>
>> There will also be elements that are purely Navy (floating servers  
>> anyone?) that are not likely to be important to the Citi group (or  
>> MacDonalds).
>>
>> Frank
>>
>>
>> On Nov 10, 2007, at 9:21 AM, Ken Laskey wrote:
>>
>>> I got the following well-stated email from someone at MITRE and I  
>>> think the answer is something that needs to be at the beginning of  
>>> the RA document but which isn't clearly tackled.  We've bumped  
>>> around this issue before but never put it to bed.  Rather than  
>>> just answering myself, I'd like to see something definitive from  
>>> this group.
>>>
>>> Read on.
>>>
>>> Ken
>>>
>>> Begin forwarded message:
>>>
>>>> Ken, I'm trying to understand what the OASIS Reference  
>>>> Architecture effort is all about.
>>>>
>>>> I understand the OASIS definition of a reference model as:  "A  
>>>> reference model is an abstract framework for understanding  
>>>> significant relationships among the entities of some environment  
>>>> that enables the development of specific reference or concrete  
>>>> architectures using consistent standards or specifications  
>>>> supporting that environment."
>>>>
>>>> We use the OASIS SOA Reference Model as the basis for our  
>>>> development of a reference architecture for the Navy's  
>>>> application of SOA in its afloat environment.  So, to paraphrase  
>>>> the OASIS RM, we are using the RM to enable the development of a  
>>>> specific reference architecture using consistent standards or  
>>>> specifications supporting that environment.
>>>>
>>>> So, the RM goes on to define, "A reference architecture is an  
>>>> architectural design pattern that indicates how an abstract set  
>>>> of mechanisms and relationships realizes a predetermined set of  
>>>> requirements."  It also states: "The concepts and relationships  
>>>> defined by the reference model are intended to be the basis for  
>>>> describing references architectures and patterns that will define  
>>>> more specific categories of SOA designs."
>>>>
>>>> As a result of all this, we understood a reference architecture  
>>>> to be specific to a domain or an environment or a specific  
>>>> category of SOA design.  It is "an architectural design  
>>>> pattern ...[for realizing] a predetermined set of requirements."   
>>>> We have interpreted "Navy application of SOA in its afloat  
>>>> environment" as a "specific category of SOA design" with "a  
>>>> predetermined set of requirements."
>>>>
>>>> By these definitions, how could one build a completely  
>>>> generalized SOA Reference Architecture irrespective of a domain  
>>>> or an environment or a category of SOA design or a predetermined  
>>>> set of requirements?
>>>>
>>>> Thanx in advance for your explanation!
>>>>
>>>
>>> -----------------------------------------------------------------------------
>>> Ken Laskey
>>> MITRE Corporation, M/S H305      phone: 703-983-7934
>>> 7151 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
>