[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] comments collected from SOA-RM presentation
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]