Matt and Duane,
I
completely understand your concerns as stated below. Is there perhaps a middle
ground, where we can constrain expansion into architecture? Do comsumers have to
be viewed as "endpoints"? Or can they be viewed as "actors"? If so, does that
change any perspective?
If this does not make sense (in terms of not making sense to include
service consumers in the RM), and we include them in an RA, I hope we can leave
open the possibility that this TC's outputs can potentially be labeled
as:
-
A Service Orientation Reference Model (SO RM) - that is, don't label this as
"SOA RM" but rather "SO RM"
-
A SOA Reference Architecture (SOA RA)
rather than a single SOA Reference Model
(SOA RM).
Joe
Joseph Chiusano
Booz Allen Hamilton
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
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
|