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


I repeated the form >>that abstracts (or hides) the implementation details of the capability or function, and<< in my version of the Service definition because that time it was smaller issue than the 'business' inclusion into the definition.

Actually, Frank is right - if we are talking about an interface of a SOA Service, based on SO Principles such interface must abstract or hide the implementation details .

- Michael

-----Original Message-----
From: Francis McCabe <fmccabe@gmail.com>
To: Laskey, Ken <klaskey@mitre.org>
Cc: soa-rm@lists.oasis-open.org <soa-rm@lists.oasis-open.org>
Sent: Sun, Apr 25, 2010 11:15 pm
Subject: Re: [soa-rm] Service definition at nauseum (restarted)

Ken
 I agree that your definition is a nice reconstruction of what has been going on in the thread. I need to make a couple of responses though, because I think that you have not understood my earlier comments.

 The fact that an ATM enables access to an account at all times IS OF THE ESSENCE of the ATM service. The fact that online banking enables access at home is similarly OF THE ESSENCE. (Sorry for shouting) It is true that the capabilities offered are not the same; but I do not think that it is a simple subset relationship.

 The point being that a key part of the functionality may well include the fact that the capability is accessed as a SOA service. 

 I stress this because, as software engineers, we are used to 'abstracting unnecessary details'. However, one person's unnecessary details are absolute requirements for someone else.  So, I do not agree that one can say:

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.

 People in the packaging industry will naturally understand this point I believe.

 Equivalence of services is a useful tool for understanding them. It is obvious that two services are not equivalent if the goals you are trying to achieve are not achievable with both of them. However, taking the ATM example, an ATM is equivalent to online banking and real teller if what you want to do get your current balance. They are not equivalent if it it outside banking hours or you are trying to get cash. Equivalence depends on your situation and the goals you are trying to achieve.

 A more IT-ish example would be accessing corporate email out of the office. One can use a VPN to access the entire corporate network and then access email in the regular way. On the other hand, the company might offer a webmail service to give you access to your email.
 If your goal is to read email then the two approaches are equivalent. If your goal is to link email with your existing threads in your mail browser the two approaches are not the same.
 The message is that, depending on the requirements, the form of the service can be critical.
 With apologies to Macluhan, "the medium is the service".

 Incidentally, I believe that 100% equivalence of services (where EVERY offered action is the same and the MEANS OF ACCESS is the same) is pretty uninteresting. Even in automated service discovery you do not want this; you are more interested in service equivalence in relation to what you are trying to achieve.

 Finally, I am not at all sure why we need:

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

specifically, I do not understand why we need to say anything about how things are implemented. For me, this would be enough:

-          access is provided using a prescribed interface


Frank


On Apr 25, 2010, at 2:32 PM, Laskey, Ken wrote:

[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]