To clarify: We already achieved consensus on the service consumer aspect of this on our last conference call.�
�
That is, we decided that:
�
(1)�Although a service orientation RM (which we decided Figure 2-1 represents) does not require a service consumer, a service-oriented architecture RM does.
�
(2) We would develop a SOA RM that extends the current service orientation RM as part of our work, and that SOA RM would include (at a minimum) a service consumer in addition to the service orientation RM.
�
(3) This inclusion of a service consumer would not be a reference architecture, but rather a reference model - namely, a SOA reference model.
�
Thanks,
Joe
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