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

[Matthew MacKenzie <mattm@adobe.com>]

Frank,

Nicely put.  I think the focus on Service rather than Consumer is a  
much cleaner approach for an RM.

-matt

On 7-Jun-05, at 12:28 PM, Francis McCabe wrote:

> I always understood the issue to be one of modeling versus  
> conceptualization.
>
> What concepts are required in order to be able to talk effectively  
> about an SOA? Those concepts belong in the RM.
>
> However, as I have previously said, when you want to talk about  
> agents communicating, you can either focus on the agents, or on the  
> conversation. The former approach emphasizes things like agents,  
> messages, and so on. The latter emphasizes what a legal  
> conversation looks like -- and does not focus on the agents  
> themselves.
>
> In a service oriented world, we have a similar choice: we can focus  
> on the participants or on the service. A focus on participants  
> leads to things like messaging, service providers, service  
> consumers etc. A focus on service leads to things like action,  
> policy, semantics.
>
> It is not that there are no service providers or consumers, but  
> that the focus is elsewhere.
>
> Frank
>
> On Jun 7, 2005, at 5:42 AM, Chiusano Joseph wrote:
>
>
>> 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
>> Visit us online@ http://www.boozallen.com
>>
>>
>> From: Matthew MacKenzie [mailto:mattm@adobe.com]
>> Sent: Tuesday, June 07, 2005 8:14 AM
>> To: SOA-RM
>> Subject: Re: [soa-rm] Service Consumer in RM or not?
>>
>> 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
>>>
>>>
>>
>>
>
>