[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Ken: Excellent point!! There are many WS specs to handle this including WS-Eventing, WS-Enumeration, WS-Policy etc. Other SOA's have varying degrees of the concept. The abstract concept represented by all of these is as follows: 1. A mechanism or methodology for creating awareness of a service and it's existence; 2. An extensible framework for declaring the service's description, policies (including security constraints), metadata and terms of invocation, parameters etc. etc.; 3. A mechanism and methodology for tracking a service's availability. Description of the mechanism is probably part of a service description if it is present. Question: I personally view #1 and #2 as essential parts of SOA. # 3 may not be essential to define SOA (RM), yet is likely to be present in many implementations. It probably is conceptually part of the abstract service description. Do you view it as such? Duane Ken Laskey wrote: > Duane, > > Thanks for the reference and I will try to read it before it > disappears into the usual reading stack :-) > > I am hesitant to enable a mechanism that looks like more advertising > spam but I guess it isn't up to me to make such judgments. It would > be interesting to think how this may interact with a notional > infrastructure element that would monitor the SOA for such things as > a service heartbeat. > > More after I've read the WS-Discovery spec. > > Ken > > On Apr 19, 2005, at 11:21 AM, Duane Nickull wrote: > >> Ken: >> >> I wanted to answer this one directly. Please excuse the time gap >> (traveling). >> >> It would not and must not preclude any model for discovery or any >> aspect of it. If there is a need, a service should be able to make >> the details available that allow the discoverer to determine if the >> service matches their needs. >> >> There is an interesting model in WS-Discovery where advertising is >> facilitated by a service or agent (on behalf of) sending out a >> "hello" message, essentially stating "I am here". Subsequently, the >> hello message recipient can query for further details. In that >> model, the information advertised for discovery may not use the same >> model for the entire process. It is a combination of many >> methodologies (Push, Parse, Pull, Parse). >> In other architectures, a model of publish subscribe that directly >> references all business materials facilitates the "need" part of >> discovery. >> >> This is worth a read too: >> http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws- >> discovery.pdf >> >> Cheers >> >> Duane >> >> >> Ken Laskey wrote: >> >>> Does this preclude the case of making the need discoverable and >>> having the service find it? >>> >>> What about the entity/organization that uses advertising outside of >>> SOA to make itself known and expects others will find its services >>> by coming specifically to it? After that point, the SOA >>> mechanisms would come into play. >>> >>> Ken >>> >>> On Apr 12, 2005, at 7: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 >>>> *********** >>>> >>>> >>> ---------------------------------------------------------------------- >>> -- ------------------ >>> Ken Laskey >>> MITRE Corporation, M/S H305 phone: 703-983-7934 >>> 7515 Colshire Drive fax: 703-983-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-983-7934 > 7515 Colshire Drive fax: 703-983-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]