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