[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] RE: [soa-rm] [soa-rm-ra] Architectural Principles (DRAFT)
Danny: At the moment, I would say that the arch principles reads more like solutions than questions. However, you are right, some of them could be worked in as specific requirements. (Not sure I would sign up to them all though) I wanted the requirements to be as clear as possible on the question side of the border: I.e., what are we building and how will we be measured for success? Frank On Mar 6, 2006, at 8:54 AM, Danny Thornton wrote: > We should be able to map the architectural principles > to one of the boxes in Figure 1, "How the Reference > Model relates to other work." The Goals are currently > defined as Critical Success Factors on the Wiki. > > Goals > http://wiki.oasis-open.org/soa-rm/ > Goals,_Critical_Success_Factors_and_Requirements > > Architectural Principles > http://wiki.oasis-open.org/soa-rm/Architectural_Principles > > The architectural principles could be worked into > requirements. > > Other opinions about where Architectural Principles > fit into Figure 1 of the RM? > > Danny > > --- Chiusano Joseph <chiusano_joseph@bah.com> wrote: > >> I've examined these architectural principles >> further, and have the >> following comments and a recommendation: >> > >> - Some of them seem too detailed for our purposes >> (at least for our >> starting purposes) - e.g. principle #2 >> - They seem divorced from our SOA-RM spec >> >> My recommendation would be for us to start from the >> top of the SOA-RM >> spec and work our way through it, deriving >> principles that are either >> explicit in the text, or implicit, and recording the >> following: >> >> - Page/line # >> - Principle >> - Explicit/implicit >> - If implicit, how we arrived at the principle >> >> Thanks, >> Joe >> >> Joseph Chiusano >> Associate >> Booz Allen Hamilton >> >> 700 13th St. NW, Suite 1100 >> Washington, DC 20005 >> O: 202-508-6514 >> C: 202-251-0731 >> Visit us online@ http://www.boozallen.com >> <blocked::http://www.boozallen.com/> >> >> >> ________________________________ >> >> From: Jeffrey A Estefan >> [mailto:Jeffrey.A.Estefan@jpl.nasa.gov] >> Sent: Tuesday, February 28, 2006 3:53 PM >> To: soa-rm@lists.oasis-open.org >> Subject: [soa-rm] [soa-rm-ra] Architectural >> Principles (DRAFT) >> >> >> Colleagues, >> >> My original message didn't get through the >> subcommittee subscriber list >> so I'm sending this note to the SOA-RM list because >> I need to get this >> material out before tomorrow's SC meeting. I've >> submitted a request to >> be added to the SOA-RM-RA SC e-mail list server. >> >> Regards... >> >> - J.A.E. >> >> ----- Original Message ----- >> From: Jeffrey A Estefan >> <mailto:Jeffrey.A.Estefan@jpl.nasa.gov> >> To: soa-rm-ra@lists.oasis-open.org >> Sent: Tuesday, February 28, 2006 11:57 AM >> Subject: [soa-rm-ra] Architectural Principles >> (DRAFT) >> >> SOA-RM-RA SC Members, >> >> I am a Wiki novice so I'm sending this response to >> my action item to >> provide Architectural Principles via this e-mail >> note. Hopefully, >> somebody can provide me with some quick guidance on >> posting this in a >> special collection on our Wiki. >> >> Text in bold face within the description of the >> principles are >> defined/referenced in the SOA-RM specification. >> There are two candidate >> sets of principles with a great deal of overlap >> between the two and some >> minor wordsmithing between them. I will need to >> refactor these later >> into the industry best practice of capturing >> principles in terms of >> Name, Statement, Rationale, and Implications. For >> now, these principles >> are presented for the SC members to provide feedback >> before I go through >> the trouble of characterizing the principles in such >> a recommended >> format. >> >> Regards... >> >> - Jeff Estefan, Jet Propulsion Laboratory >> >> >> SOA-RM-RA Architecture Principles (Version 1; 4 >> Principles): >> >> 1. Systems are composed of a loosely coupled >> collection of well-defined >> and interoperable network services and tools. >> >> "Network services" implies that the capability is >> available across the >> network via an industry standard protocol and that >> the service's >> capabilities and interface are publicly defined and >> reachable via an >> industry standard method. "Interoperable" implies >> similar tools and >> services expose the same or a subset of the agreed >> upon versioned >> interfaces, i.e., plug-and-play. >> >> 2. Information is defined externally to any given >> service or tool and is >> readily available to all authorized users. >> >> "Defined externally" means that there are one or >> more information models >> (ontologies) that clearly represent the information >> and concepts that >> are believed to be needed to be exchanged and that >> all systems >> understand and communicate via the relevant portion >> of the ontology. By >> "readily available" it is meant that information is >> held by the system >> as a whole and is reachable by any authorized user >> or system. >> >> 3. The reference architecture shall be characterized >> as a distributed >> system architecture that is both tiered and layered >> to support a >> separation of concerns. >> >> Architectural tiers and architectural layers both >> describe a logical >> separation of functions such that each tier or layer >> has a specific set >> of roles and responsibilities. By "tiered" it is >> meant that the >> boundaries between tiers are chosen/designed to >> support distribution, >> scalability, and reuse. Logical tiers can be mapped >> to any number of >> different physical computer network topologies. By >> "layered" it is >> meant that there is a need to logically separate >> common infrastructure >> capabilities (for example, communication) from >> general services (for >> example, authorization) from business logic. >> >> NOTE: The above principle could arguably be a >> formal architectural >> requirement versus an architectural principle. >> Let's discuss this! >> Further, this requirement (or principle) will need >> to be referenced from >> an excellent external white paper by Mike Rosen & >> John Parodi of IONA >> Technologies. >> >> 4. Client interfaces and displays are decoupled from >> their underlying >> processing and data management functions. >> >> "Decoupled" implies that the functions can be >> severally, i.e., one could >> chose to use the processing capability, but choose >> to use an alternative >> display interface. The intent is to allow for >> mission or technology >> specific interfaces to the same underlying >> processing and data >> management capabilities. >> >> SOA-RM-RA Architecture Principles (Version 2; 3 >> Principles): >> >> 1. Systems are composed of a loosely coupled >> collection of well-defined >> and interoperable network services and tools. >> >> By "network service," it is meant that the >> capability is available >> across the network via an industry standard protocol >> and that the >> service's capabilities and interface are publicly >> defined and reachable >> via an industry standard method. By "interoperable" >> it is meant that >> similar tools and services expose the same or subset >> of > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]