[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?
Hi Frank, et al, 1. I prefer reliable to safe. 2. I think the bullet in question about legacy systems refers to not impacting purposes, rather than systems. However, I think the idea of repurposing legacy systems deserves to be considered. 3. An exchange of messages does not necessarily mean messaging. It can certainly imply it, though and I don't mind that enough to agree to eliminating it. I think we need to make sure that our own familiarity with IT doesn't push us into interpreting words only in those familiar terms. 4. Yes. Cheers, Rex At 10:43 AM -0800 11/12/07, Francis McCabe wrote: >Ken > Overall I like it. With a couple of minor quibbles and additions: > >1. I think (and have always done so) that the primary goal of SOA is >to enable safe and effective action across ownership boundaries. I >am aware that the rest of the committee does not like the term >'safe', but 'assurance' seems mealy mouthed to m; still I can live >with assured. To me, this counts as the overarching requirement. > >2. We never discussed the issue of ensuring that legacy systems are >'unimpacted'. I think that that may be a worthy goal, but I suspect >that, in practice, there are bound to be impacts on such systems. I >would prefer more positive language, along the lines of enabling >legacy systems to be used in new potentially previously unplanned >applications and situations. > >3. Putting messaging up front like this does not seem right. >Messaging is a requirement for our version of SOA; but is not itself >a requirement that SOA is intended to address! > >4. I would fold the governance and mediation into a single bullet, >and maybe separate out management. > >Frank > > > >On Nov 12, 2007, at 9:55 AM, Ken Laskey wrote: > >>Frank, Danny, Rex, and everyone else, >> >>I looked at the email traffic and then went back to the beginning >>of the RA draft. In an effort to get to the point quicker and >>answer the MITRE questions, I'm submitting the attached edits (some >>wordsmithing and the added section 1.x.) for your consideration. >>(The Word doc tracks changes; the following paste just shows the >>net results.) This would also serve as the response to the MITRE >>question. >> >>1 Introduction >> >>Service Oriented Architecture is an architectural paradigm that has >>gained significant attention within the information technology (IT) >>and business communities. The OASIS Reference Model for SOA >>provides a common language for understanding the important features >>of SOA but does not address the issues involved in constructing, >>using, or owning a SOA-based system. This document focuses on these >>aspects of SOA. >> >> >> >>1.1 What is a Reference Architecture >> >>A reference architecture models the abstract architectural elements >>in the domain independent of the technologies, protocols, and >>products that are used to implement the domain. It differs from a >>Reference Model in that a Reference Model describes the important >>concepts and relationships in the domain focusing on what >>distinguishes the elements of the domain; a Reference Architecture >>elaborates further on the model to show a more complete picture >>that includes what is involved in realizing the modeled entities. >>While still remaining abstract, a reference architecture is more >>concrete than a Reference Model in that it identifies and provides >>a high level description of architectural components and artifacts. >> >> >> >>1.x What is this Reference Architecture >> >>The SOA Reference Model defines reference architecture as "an >>architectural design pattern that indicates how an abstract set of >>mechanisms and relationships realizes a predetermined set of >>requirements." It is possible to define Reference Architectures at >>many levels of detail or abstraction, and for many different >>purposes. In fact, the reference architecture for one domain may >>represent a further specialization of another reference >>architecture, with additional requirements over those for which the >>more general reference architecture was defined. >> >> >> >>While requirements for this reference architecture are discussed in >>Section 2, an overview of those requirements specifies a SOA for >>which: >> >> >> >> * Resources are distributed across ownership boundaries, e.g. >>there is not a single entity that can exercise control over all >>identified SOA services; >> * Resources have been developed for purposes other than >>inclusion in a particular implementation following this reference >>architecture, and the use of those resources in such an >>implementation must not negatively impact those initial purposes; >> * Infrastructure must be in place to enable communications >>through the exchange of messages and with reliability appropriate >>for the users and purposes for which the SOA implementation is used; >> * Security, governance, and management must be effective but >>consistent with multiple ownership boundaries; >> * Appropriate mediation must be available to enable >>coordinated use of independently developed resources; >> * [other overarching assumptions/requirements?] >> >> >>Below, we talk about such an environment as a SOA ecosystem. >>Informally, our goal in this Reference Architecture is to show how >>Service Oriented Architecture fits into the life of users and >>stakeholders in a SOA ecosystem, how SOA-based systems may be >>realized effectively, and what is involved in owning such a >>SOA-based system. We believe that this approach will serve two >>purposes: ensuring that the true value of a SOA meeting the stated >>requirements can be realized using appropriate technology, and >>permitting the audience to focus on the important issues without >>becoming over-burdened with the details of a particular >>implementation technology. >> >> >> >>1.2 Service Oriented Architecture - An Ecosystems perspective >> >>Many systems cannot be understood by a simple decomposition into >>parts and subsystems. There are... >> >> >>Note, the RA we are writing would be relevant to the Navy SOA but >>the Navy one will likely have more requirements, e.g. for >>supporting disconnected ops. This is an example of the Navy RA >>being a further specialization of a more general one. >> >>Ken >> >><this RA.doc> >> >>On Nov 10, 2007, at 5:21 PM, Francis McCabe wrote: >> >>>I think that for any given application there are going to be >>>elements which are 'infrastructural' in nature, and elements which >>>are 'to the point'. What disappoints many managers is the ratio of >>>the two: they would prefer not to invest in any infrastructure at >>>all; however, professionals realize that the ratio is often 90% >>>infrastructure to 10% application specific. >>> >>>With that in mind, it would not surprise me at all if there were >>>large chunks of the Navy's version of SOA that are not really >>>specific to the Navy at all (although their requirements may well >>>drive the infrastructure to a v. large extent). >>> >>>Something like this: the Navy requires security and provenance >>>management (say); for good reasons. But anyone who also has >>>similar requirements will have to solve similar problems: >>>provenance for the Navy is not that different to provenance for >>>the Citi group. >>> >>>There will also be elements that are purely Navy (floating servers >>>anyone?) that are not likely to be important to the Citi group (or >>>MacDonalds). >>> >>>Frank >>> >>> >>>On Nov 10, 2007, at 9:21 AM, Ken Laskey wrote: >>> >>>>I got the following well-stated email from someone at MITRE and I >>>>think the answer is something that needs to be at the beginning >>>>of the RA document but which isn't clearly tackled. We've bumped >>>>around this issue before but never put it to bed. Rather than >>>>just answering myself, I'd like to see something definitive from >>>>this group. >>>> >>>>Read on. >>>> >>>>Ken >>>> >>>>Begin forwarded message: >>>> >>>>>Ken, I'm trying to understand what the OASIS Reference >>>>>Architecture effort is all about. >>>>> >>>>>I understand the OASIS definition of a reference model as: "A >>>>>reference model is an abstract framework for understanding >>>>>significant relationships among the entities of some environment >>>>>that enables the development of specific reference or concrete >>>>>architectures using consistent standards or specifications >>>>>supporting that environment." >>>>> >>>>>We use the OASIS SOA Reference Model as the basis for our >>>>>development of a reference architecture for the Navy's >>>>>application of SOA in its afloat environment. So, to paraphrase >>>>>the OASIS RM, we are using the RM to enable the development of a >>>>>specific reference architecture using consistent standards or >>>>>specifications supporting that environment. >>>>> >>>>>So, the RM goes on to define, "A reference architecture is an >>>>>architectural design pattern that indicates how an abstract set >>>>>of mechanisms and relationships realizes a predetermined set of >>>>>requirements." It also states: "The concepts and relationships >>>>>defined by the reference model are intended to be the basis for >>>>>describing references architectures and patterns that will >>>>>define more specific categories of SOA designs." >>>>> >>>>>As a result of all this, we understood a reference architecture >>>>>to be specific to a domain or an environment or a specific >>>>>category of SOA design. It is "an architectural design pattern >>>>>...[for realizing] a predetermined set of requirements." >>>>>We have interpreted "Navy application of SOA in its afloat >>>>>environment" as a "specific category of SOA design" with "a >>>>>predetermined set of requirements." >>>>> >>>>>By these definitions, how could one build a completely >>>>>generalized SOA Reference Architecture irrespective of a domain >>>>>or an environment or a category of SOA design or a predetermined >>>>>set of requirements? >>>>> >>>>>Thanx in advance for your explanation! >>>>> >>>> >>>>----------------------------------------------------------------------------- >>>>Ken Laskey >>>>MITRE Corporation, M/S H305 phone: 703-983-7934 >>>>7151 Colshire Drive fax: 703-983-1379 >>>>McLean VA 22102-7508 >>>> >>>> >>>> >>> >> >> >>------------------------------------------------------------------------------------------ >>Ken Laskey >>MITRE Corporation, M/S H305 phone: 703-983-7934 >>7515 Colshire Drive fax: 703-983-1379 >>McLean VA 22102-7508 >> > > >--------------------------------------------------------------------- >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 -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]