[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Architectural Scope of Reference Model
> However, is any SOA possible if there are no communications? Agree with Ron - to apply Duane's car analogy in a different way here: A car does not have be driven on a road in order to be considered a car, *but* A car does have to have the necessary components to *enable* it to be driven on a road (we know what those are - no need to list). Kind Regards, Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com] > Sent: Wednesday, March 30, 2005 10:19 AM > To: Duane Nickull; Thomas Erl > Cc: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Architectural Scope of Reference Model > > Team, > > I agree in principle with Thomas and Duane. For the reference > model, I agree that we should not be defining messages. > Message design is clearly an implementation architecture artifact. > > However, is any SOA possible if there are no communications? > I can't think of any example and I'm not saying one doesn't > exist. If no example exists, then don't we need a > communications element in the reference model? If so, then > there would be a need for an artifact called a communications > specification - although the reference model would not define > the content of a communications specification. > > Ron > > > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Wednesday, March 30, 2005 7:45 AM > To: Thomas Erl > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Architectural Scope of Reference Model > > > Thomas: > > Thank you for this very elegant summary! > > I think the answer may be in the definition of a "reference > model" vs. > "architecture". I think case studies will help clear up this > confusion. A reference model will normally not contain > "messages" as a component. > > 1. Please look at the OSI Reference model. This is a > communication stack yet it does not contain messages: > http://www.scit.wlv.ac.uk/~jphb/comms/std.7layer.html > > This does not contain any "message" although messages will > occur in implementations using the reference model > > 2. The ITA Reference Model likewise does not have "messages": > http://www.ewita.com/earlywork/itarefr.htm > > 3. RCS Reference Model > http://www.isd.mel.nist.gov/documents/messina/euro_cast.pdf > > Again - no messages even though there is an element marked > "Communications" in figure one. > > The reference Model should not contain "messages" as a > component. That belongs in architecture or implementations > based on the reference model. I have never encountered one > reference model with concrete terms in it. If it had such, > it would not be abstract. > > We must think abstract, not concrete. > > Duane Nickull > > > > > > Thomas Erl wrote: > > > Some thoughts regarding the on-going discussion of whether > a message > > element should be part of our reference model: > > > > As per our chosen definition of architecture, in order to describe > > service-oriented architecture we need to: > > 1. Define elements that comprise the structure of a system. > > 2. Define external properties of these elements. > > 3. Define relationships between these elements. > > 4. Define the overall structure of the system. > > (not necessarily in this order) > > > > Starting with the first point, different element > collections have been > > proposed in the two position papers submitted so far. As has been > > discussed, the MacKenzie/Nickull paper does not identify a message > > element, whereas Kohring's does. > > > > A related difference I noticed when reviewing these papers is that > > Kohring's establishes a broader range of SOA elements. > Specifically, > > both service provider and requestor (consumer) roles are separately > > identified and described. As mentioned in item #3 above, we are > > required to define the relationship between the elements we define. > > Therefore, it makes sense that this paper includes a > separate element > > (message) that can be used to help describe the > relationship between a > > service and its requestor. > > > > The elements identified in the MacKenzie/Nickull paper are: > > - Service > > - Service Description > > - A form of advertisement to facilitate discoverability. > > - Service Contract > > - Data Model > > These elements form a narrower architectural scope, leading to a > > proposed architecture that revolves primarily around the > service (or a > > service assuming the provider role). Because a service requestor is > > not explicitly identified as a separate element, it makes > sense that > > an element representing some unit of communication (message or > > otherwise) is also not identified. Within this model's scope, the > > definition of a relationship between a service and its requestor > > (beyond details implied by description, contract, data model, and > > advertisement elements) is not a requirement. > > > > I believe that in order to address the issue of whether a > message is a > > legitimate element within the reference model, we should begin by > > clearly defining the scope of our abstract architecture. > Given that we > > are establishing core elements that are expected to be > present in all > > forms of SOA, this raises the question: Does an > architecture require > > the presence of both a service provider and a service > requestor (the > > coffee shop and the patron) in order to be classified > > "service-oriented"? If yes, we must define this relationship. To > > properly do so, we very well may need to further identify > and define a > > separate element to represent an abstract unit of > communication passed > > between them. > > > > Thomas > > > > > > > -- > *********** > 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]