[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
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:klaskey@mitre.org] > Sent: Mon 4/11/2005 11:39 AM > To: Chiusano Joseph; Christopher Bashioum; Hamid Ben Malek > Cc: Smith, Martin; soa-rm@lists.oasis-open.org > 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:cbashioum@mitre.org] > Sent: Mon 4/11/2005 11:14 AM > To: 'Ken Laskey'; 'Hamid Ben Malek' > Cc: 'Smith, Martin'; soa-rm@lists.oasis-open.org > 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:klaskey@mitre.org] > > Sent: Sunday, April 10, 2005 4:29 PM > > To: Hamid Ben Malek > > Cc: Smith, Martin; soa-rm@lists.oasis-open.org > > 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:Martin.Smith@DHS.GOV] > > Sent: Monday, April 04, 2005 2:44 PM > > To: Hamid Ben Malek > > Cc: soa-rm@lists.oasis-open.org > > 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:HMalek@us.fujitsu.com] > > Sent: Monday, April 04, 2005 2:58 PM > > To: vikas@sonoasystems.com; 'Duane Nickull'; 'Schuldt, Ron L' > > Cc: 'Thomas Erl'; soa-rm@lists.oasis-open.org > > 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:vikas@sonoasystems.com] > > Sent: Monday, April 04, 2005 11:27 AM > > To: 'Duane Nickull'; 'Schuldt, Ron L' > > Cc: 'Thomas Erl'; soa-rm@lists.oasis-open.org > > 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: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 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 / > > ----------------------------------------------------------------------- > -----------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]