In certain branches of philosophy, they talk about a "signalling
system" -- a system of normative conventions by which listeners can
infer the public commitments of agents.
Is that abstract enough :)
Frank
On Apr 11, 2005, at 9:05 AM, Chiusano Joseph wrote:
> <Quote>
> Pick a name and let's keep adding to its description until we agree on
> what this black box does.
> </Quote>
>
> Okey dokey - given that "Fred" is probably not descriptive enough,
> I'll recommend "infrastructure communications component".
>
>
> Kind Regards,
>
> Joseph Chiusano
>
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
>
> From: Ken Laskey [mailto:]
> Sent: Mon 4/11/2005 11:39 AM
> To: Chiusano Joseph; Christopher Bashioum; Hamid Ben Malek
> Cc: Smith, Martin;
> Subject: RE: [soa-rm] Architectural Scope of Reference Model
>
> Chris and Joe,
>
> You are both nicely pointing out capabilities of the "whatever"
> through which a given service hooks into the community. Pick a name
> and let's keep adding to its description until we agree on what this
> black box does.
>
> Ken
>
> At 11:26 AM 4/11/2005, Chiusano Joseph wrote:
>
> Since such a component does not have to even be a bus configuration
> (there are other possible configurations, such as a star), I think
> "infrastructure communications component" (or similar) may be more
> abstract than using the term "bus".
> Joe
>
>
> Kind Regards,<?xml:namespace prefix = o ns =
> "urn:schemas-microsoft-com:office:office" />
>
> Joseph Chiusano
>
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
>
> From: Christopher Bashioum [ mailto:]
> Sent: Mon 4/11/2005 11:14 AM
> To: 'Ken Laskey'; 'Hamid Ben Malek'
> Cc: 'Smith, Martin';
> Subject: RE: [soa-rm] Architectural Scope of Reference Model
>
> Ken,
>
> i don't have any problem staying away from the term ESB. However, in
> light of one of your other messages (which I agree with very much)
> that we capture the idea and then figure out what to call that idea
> later, I would suggest that the idea of some kind of a communications
> "bus" is inherent in an SOA. In other words, services should plug
> into something to be a service in an SOA. The bus defines the
> boundaries of the SOA. If you are on the bus, you are "in", if you
> are not on the bus, you are "out". This may be crossing into the
> concrete too much, but I think the RM should probably reference
> something that is an abstract of a bus.
>
>
> From: Ken Laskey [ mailto:]
>
> Sent: Sunday, April 10, 2005 4:29 PM
>
> To: Hamid Ben Malek
>
> Cc: Smith, Martin;
>
> Subject: Re: [soa-rm] Architectural Scope of Reference Model
>
>
> 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
>
> --
>
> -----------------------------------------------------------------------
> ----------
> / Ken
> Laskey
> \
> | MITRE Corporation, M/S H305 phone: 703-883-7934 |
> | 7515 Colshire Drive fax: 703-883-1379 |
> \ McLean VA
> 22102-7508 /
>
> -----------------------------------------------------------------------
> -----------
