On 9/1/06, dennis_djenfer <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> I'm trying to map a Reference Architecture to the OASIS SOA Reference
> Model, however I've been put in a quandary by some of the definitions
> in OASIS SOA-RM:
Your best option is to explicitly define your terms, just as OASIS
SOA-RM folks did. Your goal with your reference architecture is to
provide a clear and precise document for your organization. If you
don't like the terms used by OASIS SOA-RM, create different ones and
define them. But either way, people will interpret your terms the way
they want to unless you provide precise definitions. If you anticipate
that people within your organization may confuse your terms with other
commonly used terms, you should explicitly call them out and explain
why you've re-purposed a word for the purpose of the RA.
>
> 1) Service Description: "The service description represents the
> information needed in order to use a service." [OASIS SoA-RM]
>
> My interpretation of SOA-RM is that a service description will
> encompass documents like WSDL-files, XML-schemas, Policy document,
> Service Level Agreements and so on. A service description is like a
> map that points to all the information that a consumer needs to use
> the service. That's fine for me, but it clashes with the term "Web
> Service Description Language", which is not used for service
> descriptions according to the SOA-RM definition (if you uses Web
> Services). I guess we just have to accept this ambiguity.
As others responding to your query have said:
1. a service is not necessarily a web service
2. WSDL is mis-named
WSDL does not describe everything about a service. WSDL 1.1 describes
three things about a service:
1. what it does: it's interfaces (portTypes), including the supported
operations and the input and output messages for each, as well as the
schema of those messages
2. how to communicate with it: bindings of each operation to specific
protocols and encoding formats
3. where to find it: the endpoints for each binding
WSDL 2.0 constrains the definition even more because it limits a
"service" to a single interface. Therefore it is no longer a "service"
description language. It is an "interface" description language.
WSDL does not specify the constraints and capabilities of the service
(see WS-Policy). It does not specify interaction semantics (see
WS-CDL). It does not define message semantics (see RDF and OWL). It
does not specify remuneration, support, availability, and other
important aspects of the service (these could be described using
WS-Policy, or they might be described in text documents).
(I view an SLA [which is an "agreement"] to be part of a contract as
opposed to part of the service description, but perhaps the service
description may include a policy that expresses the performance and
capacity constraints of the service.)
>
> 2) Contract: "A contract represents an agreement by two or more
> parties." [OASIS SOA-RM]
>
> Most people think about a WSDL-file as a contract, like in
> "contract-first design", but is it really a contract? It is true that
> the requirement work for a service in most cases has been done with
> some specific consumers in mind, but after the service is deployed and
> new consumers discovers the service, the interface to a service is
> more like "take-it-or-leave-it".
>
> An SLA, on the other hand, is more like a contract that normally is a
> negotiated with every consumer.
I think "contract-first" or contract-based" design is a misuse of the
term "contract". A more appropriate term would be "description-first"
or "description-based" design. But you can't change established
vocabulary. You just have to make sure you clarify your terminology.
In legal terms, a contract is a formal agreement between two parties.
The SOA-RM definition follows this line. Keep in mind that a service
might support multiple bindings and multiple combinations of
constraints and capabilities (policies). A contract specifies that the
interaction between a particular consumer and a particular provider
will use a specific binding and utilize a specific set of mechanisms
to enforce the constraints and capabilities. (e.g., SOAP binding with
authentication based on digital signatures using an X.509
certificate).
>
> 3) Policy: "A policy always represents a participant's point of view."
> [OASIS SOA-RM]
>
> In many cases I would say that a WSDL-file is a policy-document if we
> use OASIS definition. It's something that the service provider states
> and the consumers has to accept. On the other hand, If a service state
> that it will not be operational between 3 A.M and 4 A.M, that could be
> a policy, but in many cases that is something that has been negotiated
> between two parties, even after the service has been deployd. I could
> very well imagine that a service provider will negotiate different
> policys with various consumers that need different QoS.
>
> In that case a policy is more like contract according to the SOA-RM
> definition.
I interpret the SOA-RM definition differently. As I said in my
response to the previous point, a service may support multiple means
to enforce a constraint or capability. For example, it can say in its
description that it requires authentication, and it supports 3
different authentication mechanisms. Meanwhile, a potential consumer
supports 2 authentication mechanisms. As part of the contract
negotiation, the consumer and provider examine the intersection of
their authentication policies and determine which authentication
mechanism they will use.
Hence the "policy" describes the constraints and capabilities from the
individual participant's perspective, and the "contract" defines the
agreed-to terms.
>
> So, the problems I have with SOA-RM are:
> 1) The well established term "Web Service Description Language" does
> not actually define a language that is used for a service description
> according to SOA-RM definition (well, this is a minor problem).
Minor problem, but you must clearly define your own terms to avoid
misinterpretation by your readers.
> 2) Is a WSDL-file a contract or a policy-document?
Definitely not a "contract" based on the SOA-RM definitions. It could
be interpreted as a policy document -- it defines the set of bindings
it supports, which then becomes a subject of negotiation for the
contract.
> 3) Does policy-documents always conform to the SOA-RM definition and
> reflects one participants view or could it be a contract between two
> parties?
Are you referring to a WS-Policy document? It could be used to both
express available constraints and capabilities (a policy document) or
runtime enforcement directives (codification of a contract). It
depends on how the policy is attached to its artifacts. e.g., it can
be attached to its description (via WSDL or UDDI), or it can be
attached to a contract within a runtime enforcement system (an XML
gateway, web services management agent, or service endpoint
interceptor).
> // Dennis Djenfer
Thanks for launching an interesting discussion.
Anne
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
