OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Actor makes it worse in my opinion.

Frankly, your distinctions between RA and RM centering on components 
such as a service consumer are utterly meaningless, and are beginning to 
wear on my patience.  Even an architecture does not need to explicitly 
call out that there is a "consumer" or client.  If I were writing an 
architecture document for the Apache web server V3, I doubt that it 
would be required for me to define that the server needs to serve 
clients.  Some things in an architecture can safely be implied.

I would not be growing impatient at this if you came to the table with a 
serious hole in our considerations of RM.  I may agree to SO RM, but I 
do not agree to it for the explicit reasons you keep on stating.

-matt

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 <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 <mailto: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
>>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]