[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Duane, Thanks for the reference and I will try to read it before it disappears into the usual reading stack :-) I am hesitant to enable a mechanism that looks like more advertising spam but I guess it isn't up to me to make such judgments. It would be interesting to think how this may interact with a notional infrastructure element that would monitor the SOA for such things as a service heartbeat. More after I've read the WS-Discovery spec. Ken On Apr 19, 2005, at 11:21 AM, Duane Nickull wrote: > Ken: > > I wanted to answer this one directly. Please excuse the time gap > (traveling). > > It would not and must not preclude any model for discovery or any > aspect of it. If there is a need, a service should be able to make > the details available that allow the discoverer to determine if the > service matches their needs. > > There is an interesting model in WS-Discovery where advertising is > facilitated by a service or agent (on behalf of) sending out a "hello" > message, essentially stating "I am here". Subsequently, the hello > message recipient can query for further details. In that model, the > information advertised for discovery may not use the same model for > the entire process. It is a combination of many methodologies (Push, > Parse, Pull, Parse). > In other architectures, a model of publish subscribe that directly > references all business materials facilitates the "need" part of > discovery. > > This is worth a read too: > http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws- > discovery.pdf > > Cheers > > Duane > > > Ken Laskey wrote: > >> Does this preclude the case of making the need discoverable and >> having the service find it? >> >> What about the entity/organization that uses advertising outside of >> SOA to make itself known and expects others will find its services >> by coming specifically to it? After that point, the SOA mechanisms >> would come into play. >> >> Ken >> >> On Apr 12, 2005, at 7:54 PM, Duane Nickull wrote: >> >>> I think to me, the definition of advertising is "to make >>> discoverable". Does this make sense? I am still not sure if it is >>> the right word to use. >>> >>> Duane >>> >>> Metz Rebekah wrote: >>> >>>> Taking Frank's statement one step further: >>>> Discovery presumes that the service did nothing to announce to a >>>> consumer/agent/entity etc of its existence. That was done >>>> independently >>>> by that entity in some way (and potentially unbeknownst to the >>>> service). >>>> >>>> >>>> If discovery is via a registry, we start bleeding over into the >>>> realm of >>>> advertising. The registry is just a middleman, a broker if you >>>> will. >>>> That registry serves as targeted advertising. Broadening the reach >>>> of >>>> advertising, the service could just broadcast its availability (or >>>> existence) and assume that broadcast will reach the targeted service >>>> consumers. Taking a page from cable television advertising, the >>>> advertising could select the appropriate channels; methods; etc to >>>> increase its chances of hitting the desired target audience, but it >>>> really comes down to announcing itself independently of any >>>> knowledge of >>>> who it is announcing itself to. >>>> >>>> What is common to both of these is the concept of a service and a >>>> consumer locating one another. >>>> >>>> Rebekah >>>> >>>> Rebekah Metz >>>> Associate >>>> Booz Allen Hamilton >>>> Voice: (703) 377-1471 >>>> Fax: (703) 902-3457 >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Francis McCabe [mailto:fgm@fla.fujitsu.com] >>>>> Sent: Monday, April 11, 2005 3: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 >>>>>> / >>>>>> >>>>>> >>>>>> >>>> -------------------------------------------------------------------- >>>> -- - >>>> >>>>>> ----------- >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> -- >>> *********** >>> 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-983-7934 >> 7515 Colshire Drive fax: 703-983-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-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]