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:  []
> Sent: Sunday, October 24, 2010 6:55 AM
> To: 
> 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
>