The binding mechanism is transport related and IMHO would not completely
specify the communication mechanisms need for SOA-RM. We would still need to
have some "Hello Packets or Ping" type specification which allows us to
answer the question "Is that service SOA?"
Vikas
-----Original Message-----
From: Duane Nickull [mailto:]
Sent: Wednesday, March 30, 2005 4:21 PM
To: Schuldt, Ron L
Cc: Thomas Erl;
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:]
>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
***********
