[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Architectural Scope of Reference Model
[Vikas]: However the point that is lost in
this discussion is the one the original email author made i.e. we need to have
an architectural element which discusses the “communication
infrastructure” in a SOA-RM. [Hamid] Viaks, I agree with your last
sentence above. What you call “communication infrastructure” in
your above sentence, I call it ESB. Some people misunderstand the term ESB when
they look at it literally: the word “bus” suggests to them many
connotations that does not necessary exist in an ESB. The term ESB should be
understood in an abstract way. It is a technical term that should not be
analyzed through the words that makes it. Martin, ESB is not exactly legacy adapter. It is
true that most implementations of an ESB incorporate data transformations and
ESBs are used mostly for EAI. However, this is only the current implementation
of the concept of ESB. Independently of the way an ESB may be implemented, the
fact still remains that there are profound concepts in the term ESB. Concerning
the peer-to-peer topology, that could be possible with an ESB, but to assume
that every transaction or call is peer-to-peer would be a very restrictive
design of what SOA is about. For example, a client application that is
connected to an ESB should be possible to invoke a service that it does not
even know about. The ESB finds the right service, based on various criteria
(that could also include the fees to pay for invoking such a service), and the
bus (ESB) makes the call on behalf of the application. Or sometimes, the service
invocation itself may involve multiple invocations among a group of other
services, orchestrated by some important components within the ESB. Hamid. From: Smith, Martin
[mailto:Martin.Smith@DHS.GOV] Hamid - - OK, this brings me out of my cave . . . What I hear people call an ESB seems to be
a “legacy adapter” (EAI - - protocol and data transform) plus
various other functions I would model as independent components, including BPM,
reliable messaging, and services location. I think it’s essential to separate
out the “legacy adapter” functionality from the rest. And I
would prefer to model the separate functions as separate entities/whatevers in
our RM. The fact that the functions are marketed in various combinations
should not overly influence our analytical decisions. I’m very concerned that the use of
the term ESB suggests that every transaction in the system (meaning the
relevant collection of services and consumers) passes through the
“bus.” This seems very wrong to me. The unifying element in an SOA environment
is the services catalog, which allows any consumer or service to find and bind
to others. After that, it’s peer-to-peer unless
“helper” or QOS services are needed. Whew - - I feel better. Martin -----Original Message----- 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]