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