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: Re: [soa-rm] Sub Comittee and/or User guide


Duane,

This is exactly how I see things going, having sub committees formed to 
work on reference architectures. One thing I *do* want to be careful 
of, however, is commissioning any of these committees before the 
reference model is at least a committee specification.  I do not want 
to split the TC's attention this early in the process, and I want to 
make sure that the subcommittees are towing the SOA-RM "party 
line"...which is impossible when the party platform is still in 
incubation.

Thanks,
Matt


On 18-Apr-05, at 5:23 PM, Duane Nickull wrote:

> All:
>
> I have read through the last batch of email.  There are a couple of 
> things I would like to propose for comments. Please read this entire 
> email before replying.
>
> 1. I will concede that many members of the public will likely have the 
> same kinds of trouble interpreting a reference model vs. a reference 
> architecture vs a specific architecture as seems to be pervasive on 
> this list.  If we have the problem in our context, it is likely to be 
> present outside of this list.
>
> 2. We cannot redefine what a "reference model" is or what it includes. 
>  If we tried to change the industry definition of reference model to 
> one that has concrete items in it or things that are not part of SOA 
> (which is tricky since it is still undefined), it will not be a true 
> reference model and hence not accepted by industry.
> 3. Service provider and service consumer are not part of a reference 
> model.  They are roles visible only in a runtime or infrastructure 
> views of a specific architecture.  To prove this point, please look 
> once again at the OSI reference model.  It is a communications stack 
> RM yet does not contain notions of a message sender and message 
> receiver.
> 4. We cannot mix abstract concepts and "things people can chew on" 
> (implying concrete items) in our work.  Such does run adverse to 
> accepted architectural conventions.
>
> SOLUTION:
>
> One way forward is to probably create a sub committee to work on a 
> reference architecture for SOA.  A Reference Architecture could be 
> developed in parallel to the reference model and is fair game to 
> illustrate things like security, consumers, providers, agents etc.  It 
> is within our charter to do such.
>
> After reading through some older emails, I would assert that such a 
> thing is probably essential along with some  sort of white paper or 
> user guide that explains the relationships between the RM, the RA and 
> other architecture.
>
> Reference Model
> (is a guide for developing a)
> [ Reference Architecture || * Architecture ]
>
> There are several people on this list who also have stated specific 
> needs for what they see in SOA.  Perhaps this may be a good Sub 
> Committee (SC) consideration also.
> Government Service Oriented Reference Architecture???
> etc.
>
> I can already see there are many of you who could lead such an effort 
> as a sub committee.
> Comments?
>
> Duane
>
> -- 
> ***********
> 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
> ***********
>



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