[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
I tend to think of things in terms of their metadata and the diagram in the document I submitted has service metadata as a central concept. I would be interested to see how you would modify it or do you have a very different idea? Ken On Apr 14, 2005, at 4:21 AM, Gregory A. Kohring wrote: > I am not sure about the inclusion of "Service Descriptions". If by > this you mean "describes what the service does", then this is just > one facet of a larger set of metadata associated with a service. > In this large set I would include quality guarantees, policy > statements, "contract" (in the sense used in the > "programming by contract" communities) and "contract" (in the sense > used by the legal community). > > Perhaps "Service Metadata" would be a better choice for encompassing > these more general concepts... > > -- Greg > > Duane Nickull wrote: >> I would like to use the term "advertising" for now as a placeholder, >> knowing full well we may all agree another term may be substituted >> later. I think that we all conceptually agree that the premise is >> "to make the existence of a service known to all consumers on a >> fabric" or some variation and that "advertising" may or may not be >> the best term to represent the abstract concept. >> To recap, it seems that this concept is one of the pillars of SOA. >> It's implementation may take many forms {(pull, push) >> (publish/subscribe) (multi-cast, unicast, broadcast, point >> cast)(...)}. >> That means that we have reached consensus (correct me if I am >> mistaken) that the SOA RM contains the following elements: >> 1. Services >> 2. Service Descriptions >> 3. Advertising/whateverwecallit - the ability to make the existence >> of a service and/or details thereof available to consumers on a >> fabric >> 4. Datamodel/whateverwecallit (includes the abstract notion of a set >> of logical instances of data a.k.a. an abstract concept of a message, >> possibly includes the concept of semantics) >> We have not all agreed to the following things, but have no >> substantial disagreement they are not in the SOA RM: >> 5. Contract - is it really a policy? Is it a core part of the >> reference model. If it is a policy, does it imply the abstract >> functionality represented in the security component of a concrete >> architecture? >> The next set if items are likely not included in the core RM, yet may >> be mentioned to illustrate functionality. >> 6. Service consumer >> I am very impressed by the progress to date (assuming I have not >> jumped too far to conclusions). >> Duane >> Smith, Martin wrote: >>> Ken - - >>> >>> Register? (implies some official or at least "well known" place >>> where things are registered.) >>> Publish? (more general term without the commercial/spam connotation) >>> >>> To me, "advertise" implies "push"; register/discover and >>> publish/subscribe are "pull." Advertise also implies use of a >>> variety of communications methods, including registration (e.g., in >>> the Yellow Pages) but also product placement, spam, etc. that might >>> be considered dysfunctional. >>> However, I have no problem putting aside this issue until (much) >>> later. >>> >>> Martin >>> >>> ________________________________ >>> >>> From: Ken Laskey [mailto:klaskey@mitre.org] >>> Sent: Mon 4/11/2005 9:28 PM >>> To: Breininger, Kathryn R >>> Cc: Duane Nickull; Chiusano Joseph; soa-rm@lists.oasis-open.org; >>> scott@justiceintegration.com; Francis McCabe >>> Subject: Re: [soa-rm] Architectural Scope of Reference Model >>> >>> >>> >>> I am of two minds as I compose this email. The first is could we >>> replace "advertise" with something like "communicate the service >>> description"? The second is let's call it advertise for now, see >>> what it actually means, and then rename it if desirable later. >>> >>> Take your pick :-) >>> >>> Ken >>> >>> On Apr 11, 2005, at 4:06 PM, Breininger, Kathryn R wrote: >>> >>> >>>> 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 >>>>> / >>>>> >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> --- >>>> >>>>> ----------- >>>>> >>>>> >>>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> --- >>> ------------------ >>> Ken Laskey >>> MITRE Corporation, M/S H305 phone: 703-883-7934 >>> 7515 Colshire Drive fax: 703-883-1379 >>> McLean VA 22102-7508 >>> >>> >>> >>> >>> > > > -- > ====================================================================== > G.A. Kohring > C&C Research Laboratories, NEC Europe Ltd. > ====================================================================== > ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]