[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
What about "invitation to treat" ;-) from the legal domain. /anders 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 >>>> / >>>> >>>> >>>> >>> >> ----------------------------------------------------------------------- >> >> >>>> ----------- >>>> >>>> >>>> >>> >> >> >> > -- Best Regards /Anders //////////////////////////// / Anders W. Tell / / Financial Toolsmiths AB / / <anderst@toolsmiths.se> / //////////////////////////// ----------------------------------------------------------------------- CONFIDENTIALITY AND DISCLAIMER NOTICE This e-mail in its entirety, including any associated files, are confidential and intended only for the addressee named above. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use of the information contained within this email or attachments is strictly prohibited. The contents should not be disclosed to any other person nor copies taken. Any views or opinions presented are solely those of the sender and do not necessarily represent those of Toolsmiths unless otherwise specifically stated. As internet communications are not secure we do not accept legal responsibility for the contents of this message nor responsibility for any change made to this message after it was sent by the original sender. We advise you to carry out your own virus check before opening any attachment as we cannot accept liability for any indirect or consequential damages sustained as a result of any software viruses. If you have received this email in error, or if you are concerned with the content of this email please notify Toolsmiths by sending e-mail to us at: info@toolsmiths.se. -----------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]