[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
If your SOA is silly enough to use reverse engineering as a preferred method of advertisement (via discovery), then more power to you. Don't expect much career wise though :-) -matt Francis McCabe wrote: > 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]