[no subject]

On 6/7/05, Matthew MacKenzie <mattm@adobe.com> wrote:
> Actor makes it worse in my opinion.
>=20
> 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.
>=20
> 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.
>=20
> -matt
>=20
> Chiusano Joseph wrote:
>=20
> > 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 wou=
ld
> >>     >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 =3D 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 bein=
g
> >>     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 everythi=
ng
> >>     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
> >>
> >
>=20
>