OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]