> 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:]
> Sent: Wednesday, March 30, 2005 10:19 AM
> To: Duane Nickull; Thomas Erl
> Cc:
> 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:]
> Sent: Wednesday, March 30, 2005 7:45 AM
> To: Thomas Erl
> Cc:
> 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
> ***********
>
>
