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: Service definition at nauseum (restarted)


Should your new opening phrase read:

A service (in the context of SOA) is a capability that is exposed as a business function in the context of the following constraints…

 

This would qualify the (SOA) service, rather than the capability…

 

Peter

 

From: Laskey, Ken [mailto:klaskey@mitre.org]
Sent: Sun, 25 April 2010 14:33
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Service definition at nauseum (restarted)

 

[I tried collecting a bunch of thoughts in a blank email but Outlook takes exception when I try to paste these into a simple reply.  So this is a continuation but will appear as a new thread.]

 

A collection of comments (that do not address the composition part of the thread):

 

Rex, Thu 4/22/2010 10:15 AM

“… At the Reference Model level, where the idea of

means or mechanism is problematic, I think we can say that a service is

a capability”

 

If we say this without qualification, I think we lose an important point.  From the RM:

 

The service concept above emphasizes a distinction between a capability that represents some functionality created to address a need and the point of access where that capability is brought to bear in the context of SOA.  It is assumed that capabilities exist outside of SOA. In actual use, maintaining this distinction may not be critical (i.e. the service may be talked about in terms of being the capability) but the separation is pertinent in terms of a clear expression of the nature of SOA and the value it provides.

 

Chris, Thu 4/22/2010 2:21 PM

“We have to look at what makes a ‘SOA Service’ different from what is not a ‘SOA service’.  Whatever definition we come up with should fail if applied to a ‘non-SOA service’.”

 

I think this is important because a great deal of the confusion I see is people trying to apply SOA art when their problem is really one of business process.  If you keep the distinction, it is much easier to push for a business solution before counting on an IT implementation.

 

Rex, Thu 4/22/2010 2:54 PM

“I disagree with "Whatever definition we come up with should fail if applied to a non-SOA service." Our SOA definition must build from the root, not contradict it.”

 

The RM quote above gives a way to relate the SOA service and the capability which is often the instantiation of the business functionality.  I don’t mind a SOA service falling under the general definition of service, but we run into trouble if all services can be considered SOA services.

 

Frank, Thu 4/22/2010 3:13 PM

“… there are significant differences in the kinds of capabilities that can be accessed in the different scenarios …”

 

No, the RM says there is the same capability but each service can expose a different subset.  True, the subset exposed by the ATM does not include processing a loan, although it could be set up to do something akin to online pre-approval.  It isn’t that it can’t but more that it doesn’t.

 

“…no interesting definition of service can distinguish between electronically mediated and physically mediated services …”

 

But a basic premise of the RM is we are talking about services in the software domain and not every possible service.  From the RM:

 

While service-orientation may be a popular concept found in a broad variety of applications, this reference model focuses on the field of software architecture. The concepts and relationships described may apply to other "service" environments; however, this specification makes no attempt to completely account for use outside of the software domain.

 

“A SOA service is a service that is accessed by message exchange across an electronic medium.”

 

The RM, I believe at Frank’s insistence, did not limit SOA to message exchange.  To quote:

 

In many cases, this [interaction] is accomplished by sending and receiving messages, but there are other modes possible that do not involve explicit message transmission.

 

Boris, Thu 4/22/2010 3:19 PM

 

“Building an SOA implementation through exposing a stovepipe functionality using service interface is a very valid approach to building services.”

 

Indeed.  From the RM:

 

There are no constraints on what constitutes the underlying capability or how access is implemented by the service provider.

 

Rex, Thu 4/22/2010 3:59 PM

“I don't see it as SOA vs non SOA, but Service AND SOA Service.”

 

Now this is a good starting point for a distinction.

 

Jeff, Thu 4/22/2010 6:01 PM

“A SOA service is accessed using a prescribed technology-neutral interface.”

 

This, at a minimum, needs some tweaking.  A typical Web Service uses a SOAP interface.  This is not technology-neutral.  Insisting it is, even in some abstract sense, will be trouble. {I see Frank also commented on this.]

 

“A service (in the context of SOA, i.e., “SOA service”) [or any other paradigm for that matter] is a specialization of this more general notion of service.”

 

I think I already agreed with this.

 

“A service IS a capability but a capability is NOT NECESSARILY a service (unless it is a service-enabled capability).”

 

Ditto

 

“…while I think we all understand the subtle distinction between a service and a capability (i.e., a service IS a capability but not all capabilities are services), the attempt to distinguish a ‘SOA Service’ from a ‘business service’ is a red herring …”

 

I tend to talk about the business service as the business function supplied by the capability, i.e. the capability provides the business service.  Most people (at least in a class setting) can deal with this and find the distinction makes sense.  The greater danger is still people who want to apply SOA to solve business problems they do not understand.  We need a first line of defense against SOA pixie dust.

 

Frank, Thu 4/22/2010 6:19 PM

“Two services are equivalent for a given purpose and interaction scenario (provider and consumer) and set of goals when both services may be used to address the goals and when the service requirements (execution contexts) are equally satisfied.”

 

I would argue that equivalence of service has nothing to do with goals.  Two services are equivalent is they provide the same real world effects when the interactions occur within the same execution contexts.  However, we still have the problem that there may be “hidden” effects (i.e. not visible through shared state) that could cause the two not to be equivalent.  Nailing this down would be difficult and is probably not something we want to tackle.

 

Chris, Fri 4/23/2010 10:15 AM

offered by a provider for a ‘generic consumer’

the term capability is really a potential for something, not the actual doing of something.  The noun ‘service’ is the ‘performance of duties or work for another’.

 

Good concepts to make sure we don’t lose, even though some wordsmithing is still required.

 

Dan, Fri 4/23/2010 10:28 AM

“service offered by a provider ‘as-is’ for market use”

“… the service is how that capability is realized …”

 

Good points that I think circle back to the original RM discussions.  Kudos to the new guy J

 

Frank, Fri 4/23/2010 12:33 PM

“These definitions are starting to read like essays, not definitions.”

 

J

 

 

So I guess it is time for me to take a crack.

 

A service (in the context of SOA) is a capability that exposes a business function in the context of the following constraints:

-          The service is offered and packaged by a provider and made accessible to consumers

-          access is provided using a prescribed interface that abstracts (or hides) the implementation details of the capability or function, and

-          the service is exercised consistent with the contracts and policies as specified by its description. 

In general, the specifics of the business function should be known independent of the service that exposes it.

 

Ken

 

 

---------------------------------------------------------------------------

Dr. Kenneth Laskey

MITRE Corporation, M/S H305              phone: 703-983-7934

7515 Colshire Drive                                    fax:        703-983-1379

McLean VA 22102-7508

 



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