[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] RE: Service definition at nauseum
When the Service Consumer is an aggregator it may need to know details that are not included in the interface provided for the end-user-consumer. Such details may need to be arranged out of band, but there are times when pre-conditions dictate that some component of the service MUST be available, such as a mobile surgery unit requiring a certified anesthesiologist. The immediate consumer is an aggregator that must know this BEFORE it can allow itself to complete the negotiations with the end-user-jurisdiction through its own service interface. In this case the ulitmate end-user is the current incident command system on site in an emergency with mass casualties. We have to be careful when we try to make one-size-fits-all statements. We may need to be satisfied with one-size-fits-most. However it is acceptable to me to say that the general case is that the implementation details MAY be opaque to the end-user Service Consumer. We may need to distinguish aggregator-consumers from end-user-consumers. Cheers, Rex Lublinsky, Boris wrote: > I do not think so. > Composition/aggregation is one of the approaches to service > implementation. A service consumer works against service interface and > a set of interaction policies and as a result, the actual > implementation should be invisible > > ------------------------------------------------------------------------ > *From:* Francis McCabe [fmccabe@gmail.com] > *Sent:* Friday, April 23, 2010 5:52 PM > *To:* mpoulin@usa.com > *Cc:* phestand@mitre.org; rexb@starbourne.com; > jeffrey.a.estefan@jpl.nasa.gov; soa-rm@lists.oasis-open.org > *Subject:* Re: [soa-rm] RE: Service definition at nauseum > > This is false in general. > On Apr 23, 2010, at 3:09 PM, mpoulin@usa.com <mailto:mpoulin@usa.com> > wrote: > >> I believe that >> >> a composition/aggregation does not require knowing details of the service implementation >> >> For consumers , such service does not appear differently from a >> non-aggregate service. >> - Michael >> >> >> -----Original Message----- >> From: Hestand, Dan <phestand@mitre.org <mailto:phestand@mitre.org>> >> To: rexb@starbourne.com <mailto:rexb@starbourne.com> >> <rexb@starbourne.com <mailto:rexb@starbourne.com>>; Estefan, Jeff A >> (3100) <jeffrey.a.estefan@jpl.nasa.gov >> <mailto:jeffrey.a.estefan@jpl.nasa.gov>> >> Cc: soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org> >> <soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org>> >> Sent: Fri, Apr 23, 2010 9:46 pm >> Subject: RE: [soa-rm] RE: Service definition at nauseum >> >> Rex, >> >> You just said something about composite services that made me stop and think. I >> never think of a composition/aggregation as something that requires knowing >> details of the service implementation. Primarily, I've always assumed this >> stance because if a detail changes and the composition relies on that changed >> detail, then the composite service would be invalid, nonfunctional, or >> incorrect. Did I interpret your statement correctly? >> >> Dan Hestand >> Lead Software Systems Engineer >> The MITRE Corp >> 781.271.3755 >> phestand@mitre.org >> >> >> -----Original Message----- >> From: Rex Brooks [mailto:rexb@starbourne.com] >> Sent: Friday, April 23, 2010 4:25 PM >> To: Estefan, Jeff A (3100) >> Cc: soa-rm@lists.oasis-open.org >> Subject: Re: [soa-rm] RE: Service definition at nauseum >> >> Well said Jeff, >> >> I ran into this in the DM2 meeting today when I gave a cut down version >> of this, saying that a SOA Service offered a capability according to a >> contract and then added that the details were contained in the service >> description but not necessarily revealed to an end user but might be to >> another service provider for use in a composition or aggregation. What >> was heard was "SOA Service offered a capability according to a >> contract." Fortunately Dave and I took on the Action Item to clarify >> that and a few other things, so we can convey our consensus. >> >> However the one sentence rule applies. >> >> Cheers, >> Rex >> >> Estefan, Jeff A (3100) wrote: >> > >> > Frank, >> > >> > Your right, however, the alternative would be to chunk up the formal >> > definition into separate sentences, which I would ordinarily be OK >> > with but clearly from our experience, the stakeholder community out >> > there ends up adopting a one sentence definition. For example, if we >> > simply defined a SOA service as a capability offered and stopped >> > there, nobody would get the essence of what services means in the >> > context of SOA. >> > >> > There are some key elements to our *service* (in the context of SOA) >> > definition that it has to embody. One, is to articulate that a SOA >> > service IS a capability offered by a provider for a consumer. Second, >> > that access is provided using a prescribed *[service] interface* that >> > abstracts (or hides) the implementation details of the capability. And >> > finally, that it (the service) is exercised consistent with *contract* >> > and *policy *constraints* *as specified by its *[service] description*. >> > >> > <SIDEBAR> The last sentence is a slight variation from my earlier >> > proposed definition and could be worded using slightly better English. >> > What I noticed missing from the original definition of service in the >> > RM was the notion of *contract* and it originally stated "...constraints >> > and policies..." and we know, of course, that contracts are key to ANY >> > service paradigm, and that both contracts and policies are just >> > specific types of constraints. If somebody could clean up the wording >> > a bit, that would be great. Maybe it's OK as written above.</SIDEBAR> >> > >> > I'm OK if we chunk these key characteristics of the definition for SOA >> > service into separate sentences but they MUST be articulated in such a >> > way that the collective whole constitutes the formal definition of >> > this very important core concept of the SOA paradigm. >> > >> > Cheers! >> > >> > - Jeff >> > >> >> -- >> Rex Brooks >> President, CEO >> Starbourne Communications Design >> GeoAddress: 1361-A Addison >> Berkeley, CA 94702 >> Tel: 510-898-0670 >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > ------------------------------------------------------------------------ > The information contained in this communication may be CONFIDENTIAL > and is intended only for the use of the recipient(s) named above. If > you are not the intended recipient, you are hereby notified that any > dissemination, distribution, or copying of this communication, or any > of its contents, is strictly prohibited. If you have received this > communication in error, please notify the sender and delete/destroy > the original message and any copy of it from your computer or paper > files. -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]