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?


I like most of the culmination of updates that have
been proposed for the RA so far, but I would agree
with Jeff that we shouldn't propagate the
"architecture is a design pattern" statement in the RM
even if we are trying to justify it.

I also agree with Jeff about architectural principles
versus requirements for the RA.  I am open to seeing
how the requirements section works out, however. Frank
can work wonders in this regard.

Danny
  
--- Ken Laskey <klaskey@mitre.org> wrote:

> Jeff,
> 
> Hold on my friend!  I do not think I mean what you
> think I mean, or  
> something like that.
> 
> To begin, I think you have a much tighter meaning
> for "architectural  
> design pattern" than I interpret -- I'm not even
> sure who originally  
> introduced that phrase.  I agree "a reference
> architecture is a  
> reusable asset whose purpose is to form a starting
> point for  
> architectural development."  I also have no vested
> interest in the  
> form it takes -- we've been experimenting on form
> since the  
> beginning.  As far as proven in use, we are dealing
> with a chicken  
> and egg cycle but if we don't eventually get to that
> point, we've  
> wasted a lot of time on the phone.
> 
> So what do you mean by architectural design pattern?
> 
> Now a lot of the words I proposed (including parts
> of the added 1.x)  
> are copied from v0.2 section 1.1.  My question has
> been how we can  
> best up front state what more specific problem(s)
> our RA is  
> addressing.  A SOA that demonstrates working across
> ownership  
> boundaries (rather than within a division of one
> company) seems an  
> important point.  I proposed others too.  If these
> are best termed  
> architectural principles, so be it.  If you can
> derive more than one  
> RA from a set of RM concepts and relationships, I
> want to state  
> unambiguously and up front for what architectural
> developments is our  
> reusable asset the starting point.
> 
> Peace.
> 
> Ken
> 
> 
> On Nov 12, 2007, at 3:53 PM, Jeffrey A. Estefan
> wrote:
> 
> > Ken,
> >
> > I strongly object to your suggested changes.  I
> never liked the  
> > RM's definition of a reference architecture as
> being an  
> > "architectural design pattern" because it's
> misleading and  
> > incomplete.  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.
> >
> > Historically, reference architectures have been
> used by service- 
> > based consultancies (not in the SOA-sense) as part
> of their  
> > intellectual capital reusable asset base.  In this
> way, reference  
> > architectures are, again, typically proven in use,
> which, is not  
> > the case for our domain-specific paradigm
> reference architecture  
> > for SOA.  We used to use reference architectures
> all the time when  
> > I worked for IBM and so did my colleagues over at
> Anderson  
> > Consulting (now Accenture).  More recently,
> analysts organizations  
> > like the Burton Group offer reference
> architectures for  
> > specifically targeted problem domains, e.g.,
> application platform  
> > strategies, identity and privacy strategies. 
> Burton happens to  
> > structure their reference architectures based on
> "principles,"  
> > "technical positions," and "templates."
> >
> > The bottom line is that people can choose to use
> reference  
> > architectures or not.  We certainly cannot require
> people to use  
> > the SOA-RA anymore than we can require people to
> use the SOA-RM.   
> > That is because these efforts are aimed at
> modeling a domain- 
> > specific paradigm as opposed to a specific
> technology.  If we, for  
> > example, were writing technology specs and
> standards like our W3C  
> > WSDL or OASIS SAML friends, then things like
> interoperability  
> > requirements would drive people to adopt certain
> technology specs  
> > and standards and, of course, specific versions of
> those technology  
> > specs and standards.  This is arguably why we've
> had limited play  
> > from the vendor community in our efforts because
> the vendors' focus  
> > is primarily technology-oriented.  Of course their
> professional  
> > services business should they choose to be
> technology agnostic (an  
> > similarly the analysts and consultancies
> businesses) could and  
> > arguably should make use of the SOA-RM and
> forthcoming SOA-RA, but  
> > then that's a judgment call based on their
> business model.   
> > Nevertheless, I digress.  My apologies.
> >
> > Let me just say that I prefer the language we had
> captured in  
> > Working Draft v0.2 of the RA.  I believe it does
> an excellent job  
> > of distinguishing a reference architecture from a
> reference model.
> >
> > Incidentally, you also characterized a set of
> requirements, which  
> > read more like architectural principles than
> requirements.  Once  
> > again, I stress as I have since the beginning of
> this effort that  
> > we need to articulate a core set of architectural
> principles as  
> > part of the SOA-RA and these could be a reasonable
> start.  If we  
> > want to publicly articulate the requirements we
> have levied upon  
> > ourselves and to the SOA-RA, that's debatable, but
> we should still  
> > specify a core set of architectural principles;
> otherwise, we're no  
> > longer talking about architecture anymore, are we?
> >
> > Bye for now...
> >
> > - 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:
> >
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
>
------------------------------------------------------------------------
> 
> ------------------
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:     
>   703-983-1379
> McLean VA 22102-7508
> 
> 



      ____________________________________________________________________________________
Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs 


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