[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
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 ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]