[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)
I prefer version 2, but in the 3rd principle I think you may have used "vice" when intending, "versus" where it reads: By "common" it is meant that the capabilities (services, components, designs) can be reused by multiple systems, that new capabilities are realized by interconnecting sets of network accessible services, and that new components and services are developed only when absolutely necessary, i.e., re-use vice re-creation I suspect you meant: "... i.e., re-use versus re-creation True? Cheers, Rex At 8:54 AM -0800 3/6/06, 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 -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]