[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
True. However, it is also true that it is not always the provider of a service that defines it: Wallmart, GM and others are major buyers -- and *they* get to say what services are out there; and how they should be invoked, but they are merely requesters. I just think that the key is the information you need to use a service; not how you get that information. From an infrastructure PoV, if you mandate an advertising agency (UDDI, LDAP, Bluetooth discovery mode, CORBA name registry ...) you set up potential choke points and barriers to implementation. Frank On Apr 12, 2005, at 6:30 AM, Matthew MacKenzie wrote: > 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]