RE: [soa-rm] A concern about the 'service' definition

["Laskey, Ken" <klaskey@mitre.org>]

Whatever we do needs to extend directly from the RM definition unless we are prepared to change that.  I believe the consensus 6 months ago was that is not a can of worms that will be beneficial if opened.

Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305              phone: 703-983-7934
7515 Colshire Drive                             fax: 703-983-1379
McLean VA 22102-7508
________________________________________
From: Francis McCabe [fmccabe@gmail.com]
Sent: Sunday, October 24, 2010 1:24 PM
To: Laskey, Ken
Cc: mpoulin@usa.com; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] A concern about the 'service' definition

I also agree with most of the premises in this note. These were long and difficult discussions if I recall.

However, I think that there are several perspectives around; and multiple dimensions. One of those dimensions is what I have been calling 'thick' vs 'thin' view of services.

If your dominant view of services is one of managing, deploying, describing them etc, then your likely to have the 'thick' view of service: as an entity that is separate from the capability being offered.

On the other hand, if your dominant view of services is one of a consumer of services then the interface, description, etc of the service is at best a necessary distraction to your real goal of getting something done. I denote this view as the 'thin' view of services - much like the plastic wrapping on fruit is a thin barrier to the consumer's goal of having something delicious to eat.

Neither the thick nor the thin view are universally covering: they are both partial views of the same elephant.

I believe that one of the lessons of the RA, compared to the RM, is that you cannot actually separate functionality from service. Put simply, the idea of 'wrapping a stove pipe and calling it a service' does not meet all the requirements. Certainly some services are best described in this way. Other services are not; a simple example being a composite service. But this is likely to lead to religious wars.

I am trying to get a formal definition of service in the RA because (a) the definition in the RM is not actually formal and (b) it is a glaring hole in the RA. I am not particularly happy with the RM view of service because it was too tightly coupled.

It also occurred to me that we could usefully leverage what we have in the RA to give a much stronger definition.

Personally, I would like to incorporate a 'modernized' definition of service: one that is compatible in spirit with the RM views but terminologically consistent with the rest of the RA, and learning from the RA too.

Frank

On Oct 24, 2010, at 9:14 AM, Laskey, Ken wrote:

> Michael,
>
> Just as we were in the final stages of RM approval, I brought up some of these points and circulated a draft (never completed) white paper that said, among other things, that "service" should never be used without a modifier, and the modifiers I concentrated on were business service and SOA service.  One of the reasons we split capability and access in the RM was because it was (and maybe still is) too prevalent for folks who had no idea how to address a Blat problem to say there would create a Blat service and the problem would be solved.  Part of our teaching mantra since then has been "No solution without SOA probably means no solution with SOA."
>
> The discussion at the time of the white paper linked the capability with the business function and the the idea of SOA service was a means to better deliver that business functionality.  Again, SOA is not magic if there was no functionality.  However, the RM notes that it is not an imperative to rigidly maintain the separation between capability and access, i.e. one could talk about the service providing the function as long as one kept in mind that there had to be a real idea of a solution and not just what was essentially access to magic.
>
> As I believe you note, this take on the RM definitions is both consistent with the RM and more tightly binds it to the business.  I regret this didn't come up earlier in the RM development and more of it make it into the Standard.
>
> However, Jeff noted during our discussion about 6 months ago that the RM definition is better than an 80-20 solution and our attempted rewording 6 months ago didn't increase that ratio but rather just slightly shifted what fit into the 80 side.
>
> My suggestion is our words in the RA should, where possible, emphasize these interpretations of the RM words.  I believe service description explicitly including functionality and RWE is a step in this direction and is one reason we've had a good response to the service description.  Making such connections will tie our efforts to the substance of interest to our perspective audience.
>
> Ken
> ---------------------------------------------------------------------------
> Dr. Kenneth Laskey
> MITRE Corporation, M/S H305              phone: 703-983-7934
> 7515 Colshire Drive                             fax: 703-983-1379
> McLean VA 22102-7508
> ________________________________________
> From: mpoulin@usa.com [mpoulin@usa.com]
> Sent: Sunday, October 24, 2010 6:55 AM
> To: soa-rm@lists.oasis-open.org
> Subject: [soa-rm] A concern about the 'service' definition
>
> Gentlemen,
>
> Reading Frank's proposal and DODAF exercise on the service definition, I've caught myself on the mismatch between what we understand as SOA Service today and what was written in RM.
>
> For the last couple of years, I identify service via its business functionality and RWE. I believe. Ken would support me in this (we discussed this a few years ago). Thus, a service (this is not an attempt to set new definition butrather the meaning of the entity) is something that Offers and Provides certain business functionality ('business' in this context may be anything -from a calculation of credit risk to washing clothes), and Delivers RWE (to theWorld).
>
> In contrast,  RM defines a service as:
> "A service is a mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface..."
> That is, "a mechanism to enable access to" perfectly fits with the definition of an interface; this is why many claim that Web Service technology and WS WSDL are services.
>
> So, the problem is: "a mechanism to enable access to" does not properly reflect characteristics of the service such as business functionality and RWE.
>
>
> Now, let me ask two questions:
> 1) if Service=Interface, how anybody can guarantee that particular business functionality is present and available? An interface may lead to anything and this anything may be simply invisible through the interface...
> 2) does any interface deliver any RWE?
>
>
> Here is a set of example questions:
> a) does a car door provide any car's functionality and move the passenger from A to B?
> B) does a door and even receptionist on the laundry shop defines the what the laundry does?
> C) if an interface accepts arbitrary commands (while the semantics of the commands is managed separately), can such an interface tell us anything about the business functionality to be triggered by particular command?(Actually, this Command-model is what I usually use with the Web Services)
>
>
> IMO (shared by many SOA experts), SOA Service is the combination of operations performed manually and/or automatically that together offer and provide certain business functionality and deliver RWE. To provide certain business functionality and deliver RWE, the service utilises certain capabilities. The RWE is delivered to the World, not necessary to the requester. The service may have as many prescribed interfaces as needed for its different consumer audiences and interaction channels. This understanding of the service positions the SOA Service right in between Business and Technology and opens the door into the Business Service-Oriented world.
>
> Sorry for so many words. I am afraid this problem with service definition is quite serious.
>
>
> - Michael
>
> ---------------------------------------------------------------------
> 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
>