[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
I chose "advertising" very carefully in recognizance that finding a service is not always an explicit operation on the part of a consumer. I do feel that we need to explain advertisement carefully so that readers understand that discovery, surprisingly, is covered by advertisement. -Matt Breininger, Kathryn R wrote: >I also wonder about the term "advertising", especially given the >audience we are targeting for the high level document. "Advertising" >has an implied meaning to the average audience, whereas "Discovery" >implies I have found something through some means, often a search or >browsing or serendipity or even word of mouth (using the big picture >here that agents include humans). Does "advertising" limit the ways in >which I (or an agent) become aware of and use a service? > > >Kathryn Breininger >Boeing Library Services >425-965-0182 phone > > > > > >-----Original Message----- >From: Francis McCabe [mailto:fgm@fla.fujitsu.com] >Sent: Monday, April 11, 2005 12:54 PM >To: Ken Laskey >Cc: Duane Nickull; Chiusano Joseph; scott@justiceintegration.com; >soa-rm@lists.oasis-open.org >Subject: Re: [soa-rm] Architectural Scope of Reference Model > > >Is discovery of the essence or advertising? If I discover how to use >your service by some kind of reverse engineering -- you did not >advertise it but I discovered it -- and can therefore use it! Frank > >On Apr 11, 2005, at 12:00 PM, Ken Laskey wrote: > > > >>Quick, write that down some place we won't lose it. :-) >> >>Ken >> >>At 02:42 PM 4/11/2005, Duane Nickull wrote: >> >> >>>Ken: >>> >>>"Advertising" is an abstract concept. I would define it as "a >>>methodology to convey awareness of (the existence of) a service(s) to >>> >>> > > > >>>all consumers on a fabric". Does this sound like a good place holder >>> >>> > > > >>>for the glossary? >>> >>>Discovery is an aspect facilitated by advertising. A consumer >>>"discovers" a service because the service's existence was advertised >>> >>> > > > >>>to the consumer or the service description was inspected by the >>>consumer. >>>Discovery does not automatically imply a right to use the service. >>> >>>There are multiple ways to implement a mechanism for discovery. 811g >>>uses a radio signal broadcast, web services uses UDDI, ebXML uses >>>CPP's accessed via an ebXML registry-repository, CORBA uses an ORB, >>>J2EE uses RMI Registry, Windows uses a registry..... >>> >>>Duane >>> >>> >>>Ken Laskey wrote: >>> >>> >>> >>>>How a capability is provided is a design issue but that a capability >>>>exists is certainly in the purview of the RM. While I might for RM >>>>sake indicate a vaguely defined box that needs more definition to >>>>ever see software, that vaguely defined box must be in the RM or we >>>> >>>> > > > >>>>lose that aspect and have an incomplete description. I can give you >>>> >>>> > > > >>>>a half dozen ways to do discovery, but is a discovery box that can >>>>notionally support all of these an elementary necessity for the RM? >>>> >>>>Ken >>>> >>>>P.S. I'm still struggling over discovery vs. advertising, so please >>>>read the above with whichever one makes most sense to you. >>>> >>>>On Mar 31, 2005, at 7:32 AM, Chiusano Joseph wrote: >>>> >>>> <Quote> >>>> I suspect when we get to specifying what gives a service unique >>>> identity, >>>> </Quote> >>>> >>>> Will we ever reach that point? That is, is the question of >>>>whether >>>> or not a service has a unique identity within the scope of a RM? >>>> My take is no - it's a design issue, and potentially an >>>> architecture issue depending on how such a unique identity needs >>>> to be generated/maintained (i.e. may have an "identity engine" >>>> component in an architecture - not to be confused with identity >>>> management for security). >>>> >>>> Kind Regards, >>>> Joseph Chiusano >>>> Booz Allen Hamilton >>>> Visit us online@ http://www.boozallen.com >>>> >>>> >>>> >>>> From: Scott Came [mailto:scott@justiceintegration.com] >>>> Sent: Wednesday, March 30, 2005 12:44 PM >>>> To: soa-rm@lists.oasis-open.org >>>> Subject: Re: [soa-rm] Architectural Scope of Reference Model >>>> >>>> Hello everyone, I've been lurking so far, but let me jump in on >>>> this one... >>>> >>>> Thomas' key question, as I read his post, was not whether >>>>messages >>>> should be part of the RM, but whether service requestors should >>>> >>>> > > > >>>>be. >>>> >>>> In my view, having services without service requestors doesn't >>>> make a lot of sense. So I would like to suggest that service >>>> requestors are a proper element in the RM. >>>> >>>> If you grant that, then the relationship between a service >>>> requestor and a service implies the exchange of some information >>>> (in the general case). We might not call that a "message", but >>>> >>>> >it > > >>>> does exist. Is there another, more appropriately abstract, name >>>> for the elements of the service's interface that specify the >>>> structure of information exchange that occurs between requestor >>>> and service? >>>> >>>> Looking at it another way (and forgive me if this is getting >>>>ahead >>>> of where we should be)...I suspect when we get to specifying >>>> >>>> >what > > >>>> gives a service unique identity, it may well be a (perhaps >>>> qualified) name plus a set of interface elements >>>> (operations/behaviors, if you will, and the "signature" of those >>>> operations). If so, then we'll need a name for the elements that >>>> represent the input and output parameters (again, forgive the >>>> "concrete" terminology) of each operation. >>>> >>>> Regards... >>>> --Scott >>>> >>>> Scott Came >>>> President and Principal Consultant >>>> Justice Integration Solutions, Inc. >>>> Olympia, Washington >>>> scott@justiceintegration.com >>>> http://www.justiceintegration.com >>>> >>>> > 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 >>>*********** >>> >>> >>> >>-- >> >> >> >> >----------------------------------------------------------------------- > > >>---------- >> / 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]