RE: [soa-rm] Service Consumer in RM or not?

["Peter F Brown" <peter@justbrown.net>]

Duane:
I'm not actually advocating one or the other approach (I might even own up
to being a little confused), with or without "service consumer", but tried
only to encapsulate the different views that came out of the meeting.

Running the whole through my sluggish brain, I suppose I do have to come
down one side or another, and I come up with:

I agree with your refinement that a service is an invokable event, rather
than an event per se. Invokable, not invoked - I think that is your point.
It underlines intent.

[Careful with your analogy with "message" however: There does need to be an
intention for a content to be transmitted to another entity for it to be
considered as a message, otherwise it is simply a document: I would agree
however that it does not need to have been successfully transmitted or
received, for it to be a message. Again, it underlines intent.]

Equally, and by analogy, a service does not require for there to be a
consumer, in order to be considered as a service. We need therefore to
establish only an intention and capability to provide a service (implicitly,
providing it to another entity, the consumer): hence service-oriented. The
RM should thus be the model from which any service-oriented architecture can
be derived, no more.

I would still argue that service consumer and service provider are two roles
of the same abstract entity, "agent"; BUT accept that this is not within
scope of the SOA-RM. I think your suggestion of including this as another
non-normative text might help to satisfy those who wish nonetheless to
answer the concern about situations in which a provider may in some
situations be a consumer or vice-versa.

-Peter


-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: 07 June 2005 01:40
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