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