[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] comments collected from SOA-RM presentation
This is one of the things I really like
about the RM as it enables quite complex business elements to be modelled
effectively, it doesn’t require the service description to be a single
entity for the service, so its fine for a service description to refer to its
parent/owner for certain policy decisions. Of course on a related note, there still
isn’t actually any implementation technologies that really enable
effective service description of both the information (which WSDL-S et al tries
to do) AND the functional (WS-Contract, WS-SLA anyone?) aspects of a service.
This is another reason I like the RM because it makes pretty clear that
description is the totality of service rather than just the technical elements
of the current WS-*. From:
McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs-sct.gc.ca] Hi Steve, Your points make sense but
I would hope though that any peculiarities with respect to service behavior
would be documented in the Service Description otherwise a consumer would have
a heck of a hard time trying to understand the non-linearity of expected
responses. The question of context is
interesting in that context can be assumed, deduced or made explicit. In any
case I also would hope that the consumer’s expectation of intended
behavior brought about by the context of the provider is well articulated
through the Service Description and any agreements made between the consumer
and provider. Thanks for the
clarification, Wes -----Original Message----- What I
was trying (badly) to get across is that the temporal nature of a service can
actually change its behaviour (responses). As a very crude example a
“Thermometer Service” will produce different results based both on
the time of the day its called and the location that it is at, there is little
point calling a remote service as it won’t give you relevant information
(hence can’t be called anywhere). Does that make sense? On the
ownership front, this is about context for the service that changes its
behaviour. As an example, you might have a “Procurement
Service” which is in your department, it has no direct ability to do
authorisation or actually buy things as its parent cannot grant those rights so
it is effectively useless. The same service inside the Finance department
however is able to do these things as its surrounding context is able to
provide those rights. Another example could be an authorisation which is based
on the policies of the owner of the card rather than on the card itself, if the
card is transferred to another owner then its contract is fundamentally
changed. Does
that make any sense?
From: McGregor.Wesley@tbs-sct.gc.ca
[mailto:McGregor.Wesley@tbs-sct.gc.ca] Hi
Steve, From
my point of view a service description may or may not have temporal information
included within it. It is up to the service provider (or the community of
interest it belongs to) to formulate any time constraints or requirements. However,
I am not sure how ownership of a service alters its behavior. Isn’t
ownership merely an attribute of a service? I understand how legislation,
policy, guidelines and agreements etc. can alter behavior but not ownership per
se. Can you help me here? Thanks, Wes
-----Original Message----- Personally
I’d be against this as a definition as it’s tied to software type
considerations rather than business ones. It’s more a description (IMO)
of component based development than SOA, in particular if you consider a person
being able to offer a solution it’s a bit tricky to consider them “distributed
anywhere” or “owned by anyone”. This implies both that
service has no temporal information, and that ownership of a service
doesn’t alter its behaviour. From: Michael Stiefel [mailto:development@reliablesoftware.com] According to
this definition 3. Possible one line description of SOA: A modular
design of solutions where the modules are distributed anywhere, owned by
anyone, and reused by everyone (in a manner consistent with specified
constraints and policies, including those which limit access).
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]