Re: [soa-rm] RE: Service definition at nauseum

[mpoulin@usa.com]

Rex,

"When the Service Consumer is an aggregator", we do not have the aggregate service, the consumer does the job. If this Service Consumer-aggregator later becomes a Service Provider to the end-user-consumer, the latter does not need to know what and how its Service Provider does its work, alone or by engaging helpers.

In your example with a certified anesthesiologist, an end-user-consumer may require a certified anesthesiologist to be a part of the Service (the mobile surgery unit) but this is possible only if the Service has appropriate interface to accept such end-user-consumer's requirement, plus, the end-user-consumer should not know how this requirement will be met by the Service.

In SOA, I strictly follow the rule: if a SOA service is a self-contained unit providing particular RWE, we have to accept that a service of my service is not my service. In SOA, as in Business, a good provider never exposes its internal problems onto the consumers, i.e. one-size-fits-all unless the provider fails in full (if you are a good provider).

A service consumer should not need to know about other services engaged by the explicitly faced service not because the service implementation is opaque only but because the consumer get the contract with the explicitly faced service only, not with other engaged services. If the service provider wants to expose engaged services to the consumer, they must be mentioned in the Service Description. This line of logic leads to serious problems with using ESB products in SOA: if a consumer is separated/shielded by the ESB from the service, the consumer must set a contract about business functionality and RWE with the ESB, not with an invisible service. I have not seen (m)any ESB products used in this way. Thus, the only SOA style solution of this problem is in having ESB a part of the Service Description/Contract that hides ESB from the consumer (e.g., the ESB SLA becomes a part of the service's SLA). I have not seen such things in the industry as well...

I totally agree with "We may need to distinguish aggregator-consumers from end-user-consumers"; we need to distinguish.

I hope, this will help to understand my position

- Michael

-----Original Message-----
From: Rex Brooks <rexb@starbourne.com>
To: Lublinsky, Boris <boris.lublinsky@navteq.com>
Cc: Francis McCabe <fmccabe@gmail.com>; mpoulin@usa.com <mpoulin@usa.com>; phestand@mitre.org <phestand@mitre.org>; jeffrey.a.estefan@jpl.nasa.gov <jeffrey.a.estefan@jpl.nasa.gov>; soa-rm@lists.oasis-open.org <soa-rm@lists.oasis-open.org>
Sent: Sat, Apr 24, 2010 3:53 pm
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