I think we must agree on the building
blocks of RM and later decide (through discussion) which one we want to expand
more and which ones we should drop (or keep it abstract) because it is a
slippery slope. This will help us clear our thought process on how we came
about our decision. I think the end goal is as important as the process of
reaching it – keep the discussions going … For my understanding I
too would like to understand why SC should not be part of RM (it may not be but
I would like to understand).
Thanks,
/Prasanta
From: Michael Stiefel
[mailto:development@reliablesoftware.com]
Sent: Tuesday, June 07, 2005 5:45
AM
To: Matthew MacKenzie; SOA-RM
Subject: Re: [soa-rm] Service
Consumer in RM or not?
I can appreciate the slippery slope argument also.
But that is a different argument than saying it does not belong in the RM
because of the definition of an RM.
Michael
At 08:14 AM 6/7/2005, Matthew MacKenzie wrote:
If I can interject...
I think that Duane and I are concerned with the slippery slope that exists when
we start including endpoints such as consumers in the RM. After consumers
will come messages, and the next thing we know we'll have a WSDL binding in
appendix e or some such.
arrrrgggghhhh!!!
:-)
-matt
On 7-Jun-05, at 7:21 AM, Chiusano Joseph wrote:
<Quote>
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.
</Quote>
Duane,
This is an idea that I see you have
been pushing very hard almost from the start of our TC, yet I believe some of
us are perplexed as to why introduction of a service consumer into an RM is
against the notion of RM. Can you please clarify for us?
Thanks,
Joe
From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: Mon 6/6/2005 7:39 PM
To: peter@justbrown.net
Cc: 'SOA-RM'
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