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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: [Please Disregard This Duplicate] RE: [soa-rm] Definition of Reference Model (Was RE: [soa-rm] Definition of "Service Consumer")


Please disregard this duplicate message - I had resent it as I was not
certain that it would come through. The previously received version is
the one that should be responded to. Sorry for any inconvenience.

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] 
> Sent: Tuesday, April 12, 2005 7:43 AM
> To: Ken Laskey; Matthew MacKenzie
> Cc: Frank McCabe; Duane Nickull; soa-rm@lists.oasis-open.org; 
> vikas@sonoasystems.com; Andrew Nash
> Subject: [soa-rm] Definition of Reference Model (Was RE: 
> [soa-rm] Definition of "Service Consumer")
> 
> Based on many similar comments that have been sent to our 
> listserv regarding the scope of our reference model, I 
> thought it might be useful to begin a thread on our 
> definition of a reference model. Some comments indicate that 
> our usage of the term "reference model" might be too 
> "constraining" (exclusing notions such as security), while 
> others indicate that it is justifiably so, as it is intended 
> to include only "mandatory" concepts.
> 
> Fundamental Question: Is our scope indeed too narrow? 
> 
> From our charter:
> 
> <Definition>
> Reference Model - A reference model is an abstract framework 
> for understanding significant relationships among the 
> entities of some environment, and for the development of 
> consistent standards or specifications supporting that 
> environment. A reference model is based on a small number of 
> unifying concepts and may be used as a basis for education 
> and explaining standards to a non-specialist. 
> </Definition>
> 
> This definition does not state that only "mandatory" concepts 
> are included, but rather implies it through its reference to 
> "a small number of unifying concepts". I recommend that at 
> this point, since our definition of "reference model" is 
> being used as a filter for everything
> - and so many things are (perhaps justifiably!) being "kicked 
> out" of it
> - we gain consensus on what we believe "reference model" means. 
> 
> I bring this up because I have seen cases where reference 
> models are not as restrictive as the one that we are heading 
> toward (but maybe they should be?). I am also (frankly) 
> concerned that we might be developing something that is - and 
> I don't mean this in a pejorative sense - too "academic" and 
> not implementable in real-world settings. I would like to see 
> us create something that is more inclusive than exclusive, so 
> it can have the maximum utility for developing 
> service-oriented architectures, rather than making folks 
> think about why fundamental aspects - such as security - were 
> left out of it.
> 
> I also wonder if it might be more valuable process-wise to 
> concentrate on concrete architectures, and then determine 
> from among those concrete architectures what concepts are 
> mandatory, what are optional etc. - that is, to build our 
> reference model from outward-in, instead of the opposite 
> which I believe is our current process.
> 
> Thoughts?
> 
> Joe
> 
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>  
> 
> > -----Original Message-----
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: Monday, April 11, 2005 9:02 PM
> > To: Matthew MacKenzie
> > Cc: 'Frank McCabe'; Duane Nickull;
> > soa-rm@lists.oasis-open.org; vikas@sonoasystems.com; 
> Chiusano Joseph; 
> > 'Andrew Nash'
> > Subject: Re: [soa-rm] Definition of "Service Consumer"
> > 
> > Let's leave this as an open issue, if we may.  Except for a very 
> > simple, very closed system, I cannot imagine a viable SOA in a real 
> > environment without security.  I am willing to be educated about 
> > situations where security can legitimately be skipped, but I don't 
> > think it can be left out of a useful RM.
> > 
> > Ken
> > 
> > On Apr 11, 2005, at 3:32 PM, Matthew MacKenzie wrote:
> > 
> > > I don't believe that all SOAs do or will have security.  
> I think we 
> > > should simply not mention it.  This is, after all, an abstract 
> > > reference model.  We can produce the warmNfuzzy that having
> > a security
> > > component adds in our own SOA designs that are identifiable
> > with the
> > > SOA-RM.
> > >
> > > -matt
> > >
> > > On 11-Apr-05, at 12:28 PM, Duane Nickull wrote:
> > >
> > >> Ken:
> > >>
> > >> I am not 100% sure about this.  I would like to research 
> this on a 
> > >> more philosophical basis.  Not all SOA's use explicit security 
> > >> protocols (the internet doesn't).  The fundamental philosophical 
> > >> question may be " does the explicit statement conveying
> > the absence
> > >> of any security still imply a security model"?
> > >>
> > >> The danger in saying "yes" is that it opens the door for more 
> > >> "things" to be part of the RM.
> > >>
> > >> I would like to mull this over and do some research.  I am
> > sure Matt
> > >> has a good answer ;-)
> > >>
> > >> Duane
> > >>
> > >> Ken Laskey wrote:
> > >>
> > >>> Moreover, the question is whether all SOAs SHOULD have
> > security and
> > >>> whether that needs to be captured in the RM.  As noted,
> > secuirty is
> > >>> often just tacked on and that may not be sufficient for
> > *any* SOA to
> > >>> be successful.
> > >>>
> > >>> Ken
> > >>>
> > >>> At 02:27 PM 4/11/2005, Duane Nickull wrote:
> > >>>
> > >>>> The RM does not support security models.  A reference
> > model is used
> > >>>> to guide the design of architecture that may include specific 
> > >>>> security protocols or models. Our requirement must be 
> to ensure 
> > >>>> that nothing we place in the RM makes any specific
> > security model a
> > >>>> requirement (since not all SOA's have security) and to
> > ensure that
> > >>>> we do not preclude a specific type of security model 
> from being 
> > >>>> used.
> > >>>> Duane
> > >>>>
> > >>>> Vikas Deolaliker wrote:
> > >>>>
> > >>>>> I think the question should be how many different types of 
> > >>>>> security models will this RM support?
> > >>>>> Vikas
> > >>>>>
> > >>>>> --
> > >>>>
> > >>>> --
> > >>>> ***********
> > >>>> Senior Standards Strategist - Adobe Systems, Inc. - 
> > >>>> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - 
> > >>>> http://www.unece.org/cefact/ Adobe Enterprise Developer
> > Resources
> > >>>> - http://www.adobe.com/enterprise/developer/main.html
> > >>>> ***********
> > >>>>
> > >>>
> > >>> --       
> > >>> 
> > --------------------------------------------------------------------
> > >>> -
> > >>> ------------
> > >>>   /   Ken Laskey                                          
> >             
> > >>>            \
> > >>>  |    MITRE Corporation, M/S H305    phone:  703-883-7934   |
> > >>>  |    7515 Colshire Drive                    fax:      
> > 703-883-1379   
> > >>>  |
> > >>>   \   McLean VA 22102-7508                                
> >             
> > >>>    /
> > >>>      
> > >>> 
> > --------------------------------------------------------------------
> > >>> -
> > >>> -------------
> > >>>
> > >>>
> > >>
> > >> --
> > >> ***********
> > >> Senior Standards Strategist - Adobe Systems, Inc. - 
> > >> http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - 
> > >> http://www.unece.org/cefact/ Adobe Enterprise Developer
> > Resources  -
> > >> http://www.adobe.com/enterprise/developer/main.html
> > >> ***********
> > >>
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > ------------------
> > Ken Laskey
> > MITRE Corporation, M/S H305     phone:  703-883-7934
> > 7515 Colshire Drive                        fax:        703-883-1379
> > McLean VA 22102-7508
> > 
> > 
> > 
> 


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