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: Adding Architectural Implications to Sections


I've been looking at the differences between the newly added
Architectural Implications and the architectural mechanisms in other
subsections of 4 and 5.  Subsection 4.1, Service Description, and
Subsection 5.1, Governance Model, describe Architectural Implications in
a style closely related to requirements listings but do not model the
relationships of the architectural mechanisms.  Subsection 4.2, Service
Visibility Model, and subsection 4.4, Policies and Contracts Models,
model the relationship of architectural mechanisms but do not list
architectural implications in requirements fashion.  
 
To make all 4.x and 5.x sections consistent, architectural mechanisms
and their relationships could be modeled and architectural implications
could be a list of high level requirements or something similar to high
level requirements.  A note about modeling architectural mechanisms is
that they will tend to be example mechanisms since mechanisms can be
realized in different ways in different implementations.
 
The most common flow for the subsections in 4 and 5 is

   Introduction/Concepts/Principles/High Level Models (Above the
Architectectural Mechanisms Models)

   Architectural Mechanisms/Implications

The actual flow for the subsections is

   4.1 Service Description Model

      Service Description artifacts and their relationships (Models)

      Could have architectural mechanism models

      Architectural Implications/Mechanisms of Service Description (No
Models)

   4.2 Service Visibility Model

      Visibility Processes (Models)

      Mechanisms for Visibility (Models)

      Could have Architectural Implications

   4.3 Interaction with Services 

      Message Exchange (Models)

      Service Composition (Models)

      Service Business Processes (Models)

      Service Business Collaborations (Models)

      Could have Architectural Implications

   4.4 Policies and Contracts Models

      Mechanisms for Policies and Contracts (Models) 

      Policy and Contract Principles (No Models)

      Could have an Architectural Implications

   5.1 Governance Model

      High Level Governance (Models)

      Governance to SOA (No Models)

      Architectural Implications of SOA Governance (No Models)

   5.2 Security Model

      Security Concepts/Principles (No Models)

      Threat Model (No Models)

      Mitigation Model (Some Models)

      Could have Architectural Implications of SOA Governace section  

   5.3 Services as Managed Entities Model

      Work in progress

Danny 



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