We need to stay away from anything that is as concrete as ESB.
Duane
Ken Laskey wrote:
> I would strongly suggest we stay away from the term ESB. It has become
> an ill-defined product offering from many vendors and it is not at all
> clear what needs to be present in such a component. An ESB (or some
> vendor's notion of an ESB) could be an implementation mechanism but
> such a conglomeration is show be the output of design, not the
> conceptual reference.
>
> Ken
>
> On Apr 4, 2005, at 7:03 PM, Hamid Ben Malek wrote:
>
> [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:]
> Sent: Monday, April 04, 2005 2:44 PM
> To: Hamid Ben Malek
> Cc:
> Subject: RE: [soa-rm] Architectural Scope of Reference Model
>
>
>
> 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-----
> From: Hamid Ben Malek [mailto:]
> Sent: Monday, April 04, 2005 2:58 PM
> To: ; 'Duane Nickull'; 'Schuldt, Ron L'
> Cc: 'Thomas Erl';
> 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-----
> From: Vikas Deolaliker [mailto:]
> Sent: Monday, April 04, 2005 11:27 AM
> To: 'Duane Nickull'; 'Schuldt, Ron L'
> Cc: 'Thomas Erl';
> Subject: RE: [soa-rm] Architectural Scope of Reference Model
>
>
>
>
>
> 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
>
> ***********
>
>
>
> ------------------------------------------------------------------------------------------
>
> Ken Laskey
> MITRE Corporation, M/S H305 phone: 703-883-7934
> 7515 Colshire Drive fax: 703-883-1379
> McLean VA 22102-7508
>
--
***********
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
***********
