[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Francis: I am not comfortable with that term either. I can establish a service without advertising it. Establishment is a metric or state of existentialism IMO. The concepts are (sort of): - announce (not suitable as a word since this implies a push method) - make known the existence of. ( this is the real intent) - to make discoverable - make visible to all consumers on a fabric. Does this summarize the concepts? Anyone have a word that summarizes those? Anyone care to try and make that into one or two sentences? Duane Francis McCabe wrote: > Perhaps the word that you are looking for is *establishment*. When > something is established, it becomes *real* and, perhaps, useable. > Frank > > On Apr 12, 2005, at 4: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 >> *********** >> > -- *********** 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]