[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Service Consumer in RM or not?
Hi - I'm back!!
Comments inline:
Peter F Brown
wrote:
>1) A service is an event
>
DN - a "service
invocation" is an event. The "service" itself is not an
event IMO, it is an
invoke able entity..
>representing a collaboration between two
parties
>for the use of defined resources: a "service RM" would be
concerned with
>representing both parties (provider and consumer), the
duality of their
>interaction through the event and the use of
resources...
>In this approach:
>- service consumer would definitely
be in, as one side of the event-based
>duality
(provider<>consumer);
>- a further level of abstraction can be
modelled, that of "agent", to
>highlight the shared properties of both
provider and consumer. In this
>manner, it would be easier to answer the
problem "how do we model the
>situation where a service provider can also
be a consumer, and vice-versa?".
>They are both agents. Whether they are
consumers or providers would
>therefore be modelled as a "role" in
agent.
>
>2) A service is a "directed collaboration" between two
parties: directed in
>the sense that one party provides a service to
another: a "service provision
>RM" would only be concerned with one side
of the duality, representing the
>service provider, irrespective of
whether the service is used, or whether
>there is a consumer at the end of
the "pipe"...
>
>
I would like to call for a vote on this
too to put it to bed for once an
all. My assertion = If I architect
something with a service, a consumer
does not have to be present for it to be
"service oriented". Nor do
messages, networks, signals, pings,
security, encryption etc etc. This
is much the same as stating
that a "message" does not have to be sent in
order for it to be a
"message". It can exist with or without being
transmitted.
If we
do go the way of the service provider and service consumer, this
could be
done in an illustrative (non-normative) manner in the RM or
(and I favor this
idea) as part of a reference architecture. If we do
vote to include the
SC, we then have to open up the RM to everything
else that follows which
means that it won't be a RM, it will be
architecture.
I had hoped we
could gain consensus on this and avoid a vote however I
feel a vote may be
inevitable.
BTW - has anyone else noticed that the list is very slow
today? It took
5 hours for my last message to come back to me via this
list?
Duane
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]