[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
+1 - good point. 811 g is another example. Of course, I making assumptions about what SOA is again ;-) Duane Ruiz, Michael E. (US SSA) wrote: > Joseph > > > > It seems to me that MOM (message oriented middleware) would be > specific to a particular implementation. If one considers Bluetooth > to be a specific implementation of a SOA then one might have to > concede that MOM would not be part of the implementation. > Irrespective the MOM is to concrete for a reference model. The > reference model should not be concerned with the specific > communication pattern but the pattern of interaction between the model > constructs. > > > > /r > > Michael Ruiz > > 703-668-4243 > > 703-785-9503 > > > > ------------------------------------------------------------------------ > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > Sent: Wednesday, March 30, 2005 2:03 PM > To: Schuldt, Ron L; Duane Nickull; Thomas Erl > Cc: soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] Architectural Scope of Reference Model > > > > +1 > > > > I believe a communications specification (or however we term it) is > key. When implemented, this may be a MOM capability/product (for example). > > > > Kind Regards, > > Joseph Chiusano > > Booz Allen Hamilton > > Visit us online@ http://www.boozallen.com <http://www.boozallen.com/> > > > > ------------------------------------------------------------------------ > > From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com] > Sent: Wed 3/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 > <http://www.scit.wlv.ac.uk/%7Ejphb/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 > *********** > -- *********** 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]