[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Architectural Scope of Reference Model
Hi all, I have not been following the discussion on this mailing list as I have
not read all the messages yet (or should I say I have read only two or three
emails). But it just happened that I have read this one, and I felt compelled
to give my input to it. What Duane is calling “binding mechanism” (namely
the component(s) responsible for receiving/sending and handling of messages) is
actually part of a system called “Enterprise Service Bus”. SOA
Reference Model should try to define the general principles of an ESB in a way
that is independent of any specific implementation of the ESB. The question
whether a given service by itself is an SOA service, does not make lot of
sense. Any service could become an SOA service if it is hooked up to an ESB. The
real questions are how to define an ESB in an abstract way, and how to define
the adapters that can hook up a given service to an ESB? The best analogy would
be to compare the ESB to the internet, a service to a computer, and the
adapters to the network cable and its accessories that allow a given computer
to hookup to the internet (to get connected). In regards to the feasibility of
defining a “ping” specification to SOA-test a service, I think that
is possible, but it will be defined within the specification of an ESB. Hamid. -----Original Message----- 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:dnickull@adobe.com] Sent: Wednesday, March 30, 2005 4:21 PM To: Schuldt, Ron L Cc: Thomas Erl; soa-rm@lists.oasis-open.org 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 http://www.adobe.com/enterprise/developer/main.html *********** |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]