[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Agreed. I have forwarded the email from Duane to ebSOA members with this opener: FYI - ebSOA group - This is an update on the voluminous discussions happening at the SOA-Reference Model group level. I felt that this email summarized the overall direction for SOA-RM, with references to example work from OSI and others. I am forwarding it for the persons not subscribed to SOA-RM. My apologies to those who have seen this already. John ~~~~~~~~~ john c hardin CIO - crossconnections.ws 313.279.1377 new *VONAGE* number 313.930.5323 cell mailto:john@crossconnections.ws "The new electronic interdependence recreates the world in the image of a global village." Marshall McLuhan, "Gutenberg Galaxy", 1962 Rex Brooks wrote: > I understand better now, Duane, > > Thanks for the further reference materials. > > One question though: Shouldn't we start from the concrete now in a > bottom-up approach since structural elements such as messaging > protocols and the manifold other concerns recently expressed, exist at a > very mature stage now? I don't think we are in the position of driving > research and development for protocols to be constructed out of our > models. Correct me if I'm wrong, but I think we are in the position of > needing to take full recognition of the existing protocols and abstract > our models from these concrete architectural elements as they exist now. > > Then, maybe we can look at how we can enable a more advantageous > approach to combining these manifold technologies together in the manner > our Reference Model can realistically provide. > > Ciao, > Rex > > At 6:45 AM -0800 3/30/05, Duane Nickull wrote: > >> 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]