[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] RE: Service definition at nauseum
|
I
just worked my way through the “Service definition” email
thread. I second Frank’s comments, he addressed my thoughts as I
was reading through the thread. A
service with an opaque implementation could at a later time be transparent if
the service provider chooses to describe the implementation of the service.
The once opaque service and transparent service are still equivalent assuming
nothing else changed about the service. It seems arbitrary to use opaque which
is why I like Frank’s distinction. The same goes for technology
neutrality. I
would disagree with this statement: >>
Service Contract may not be a part of Service Description by
definition of 'contract': >> no service consumers, no contract but this does not
change the Service Description. While the second line is true, a Service Description becomes a
part of the contract once a service consumer uses it. A contract is not a
contract until it is signed so to speak. As much as I dislike to think of
current WSDL definitions as part of a contract, I had to use this analogy with
another company that had to implement a WSDL provided by our company. They
took our WSDL, generated web services using .NET and then had to reconstruct a
WSDL because Microsoft treats the WSDL as a by-product of .NET WCF
configurations. The WSDL that was reconstructed was not in compliance
with the WSDL provided. When our web service client indicated discrepancies
in the interface, I had to use an analogy of a real-estate manager providing a
renter a lease agreement. The real-estate manager provides the renter a
lease agreement, the renter takes it home and changes it and signs it, gives it
back to the real-estate manager and then the real-estate manager points out it
is not a contract because the renter changed the provided lease agreement. Danny From: Francis McCabe
[mailto:fmccabe@gmail.com] Jeff, I sympathize and agree with much of this. I have a couple of sticking points: I do not think
that you should even mention technology neutrality. A given service may or may
not be offered in a technology neutral way (somehow I think that all actual
services will have actual technologies). From the SOA paradigm perspective, it
is enough to say that the technology is not necessarily important. Similarly, while it may be good practice to hide
implementation details, it is better to say that implementation details are not
intrinsic to the concept of a SOA service. The caveat on descriptions is important. It is one of
the characteristics of SOA that descriptions be appropriately available. I personally think that access is part of the service;
even if we do not always want to see it. On a related thought, we can ask when two services are
equal. This is critical when understanding when it is ok to use automated
methods for discovery. One approach: 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. Frank On Apr 22, 2010, at 3:01 PM, Estefan, Jeff A (3100) wrote:
Colleagues, After
reading e-mail thread after e-mail thread and giving this some intense thought,
here’s how I see it. Starting
with the base concept of service defined as follows (slightly paraphrased from
CBDI SAE metamodel): *
A service in the general (notional) sense is a capability offered by a provider
to a consumer according to a contract. Caveats: *
A service IS a capability but a capability is NOT NECESSARILY a service (unless
it is a service-enabled capability). *
A service may or may not expose the internal workings of the capability offered. Therefore, *
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. This
implies that: *
A SOA service IS NOT a mechanism. *
A SOA service IS NOT an interface. *
A SOA service IS NOT an interaction or connection point. *
A SOA service IS a capability! These
other concepts are all very important in capturing the dynamics and meta-level
aspects of a SOA service, but they are not the service itself. For
the paradigm of SOA, we take the specialization of the general (notional)
concept of service a step further: * A SOA service is opaque to the
implementation of the capability offered. *
A SOA service is accessed using a prescribed technology-neutral interface. *
A SOA service is exercised consistent with contracts and policies as specified by its description. Now
that we have that out of the way, let me suggest a more formal definition of
SOA service: *
A service (in the context of SOA) is a capability that is offered by a provider
for a consumer where the implementations details of the capability offered is
opaque to the consumer. Its access is provided using a prescribed technology-neutral
interface, and is exercised consistent with the contracts and policies as
specified by its description. The
proposed definition above is close to what we provided in the RM but it’s
not exactly the same. The differences I have noted in bold text in the
above bullet points and I purposefully dropped the introductory text on
“mechanism” as well as a few repetitive words. Perhaps
we can make the minor adjustments in the RAF, but unless I see major
objections, this is how I’m going to start talking referring to the core
concept of service (in the context of SOA) with my constituents. It is
not that far off from the RM definition but I believe it is not only accurate,
it is more precise. Finally,
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 and it’s going to cause
us nothing but headache in my opinion. First, I have seen no evidence of
a formal industry standard definition of what a business service actually is or
what constitutes such a service. To me, we would be better served if such
a concept were referred to as “business capability” from which one
could derive the notion of a “service-enabled business capability”
but, again, I think this is just going to drive us down a big rat hole and
I’d rather not go there – IMHO. Regards… -
Jeff E., NASA/JPL |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]