[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] RE: Service definition at nauseum
|
Michael, I am not buying this. A service is created by provider not for a specific consumer (this
will be a very non scalable model), but rather to expose its functionality. At
this point he specifies a service contract – service interface and a set of
access policies. At this point, a new consumer has to decide whether he wants to
use this service (relatively inexpensively) or pay a premium to the provider to
modify either interface or a set of policies. In the later case, provider
creates a new service for this new consumer. True consumer can have his own policies, but those are not part
of service contract – rather they are consumer requirements, that have to be
satisfied by a service contract. From: mpoulin@usa.com
[mailto:mpoulin@usa.com] Danny, the statement >> Service Contract may not be a part of Service
Description by definition of 'contract':<< is very simple. A potential consumer finds a Service Description, likes only a
part of it (because only this part covers the consumer's needs) and asks the
service provider to set and sign the Service Contract (with or without WSDL,
e.g., messaging services) that contains just a sub-set of policies and other
attributes included into the Service Description. If the service provider
agrees, the Service Contract gets signed. Moreover, as we talked
before, Service Contract may include consumer's policies in addition to the
provider's ones. So, strictly saying, Service Contract document is not a part of
Service Description document but rather a derivative from the Service
Description document. - Michael -----Original Message----- 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 The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]