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