[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Ron: I will attempt to answer your question. If designing a service oriented architecture for an infratructure, yes - probably none would exist without messaging or messages. If you use SOA principles to design a single component (for example - some sort of specialized services server), it, by itself, may not have any "messages" or mesage generation software, only a component of the service that recevies messages from other components (which I have been calling a "binding mechanism"). So if one were to ask the question " is that services server SOA?", the answer would be yes if it had all the elements (which we have not yet defined) of SOA. I hope this makes some sense? Duane Schuldt, Ron L wrote: >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]