[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
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: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 > -- *********** 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 ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]