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?


Now that we've talked about the elephant in the corner....

What you stated regarding the differences between offer and contract
actually reinforces my point (perhaps mine though was not elegantly
stated).  I was trying to use a metaphor to more tangibly illustrate an
underlying difference in perception that seems to fuel recent
discussions on the list.  

In response, I would suggest that the nuance between an offer and a
contract demonstrates that the "ratification" rather than the
"existence" is really the key differentiator of a contract.  Can a
contract exist without ratification?  If not, what is it?  Is an offer
an ungratified contract (ok, so I really meant to type un-ratified but I
found the mistype HILARIOUS and left it in this message)?  If so, when
does it stop being an offer and when does it start being a contract?
Analogously, when does a message start being a message - at the offer
stage or at the contract stage?

Yes, there is much detail to define in a reference architecture.
However, as a TC, we continually struggle with what concepts (detail)
belongs in the RM and what is relegated to an RA.  My analogy was
attempting to demonstrate how certain underlying perceptions on what are
the critical characteristics of "service", "message", "consumer",
"contract", etc might be examined directly in efforts to reach consensus
on the concepts that demonstrate those qualities.

Rebekah
Rebekah Metz
Associate
Booz Allen Hamilton
Voice:  (703) 377-1471
Fax:     (703) 902-3457


> -----Original Message-----
> From: Matthew MacKenzie [mailto:mattm@adobe.com]
> Sent: Tuesday, June 07, 2005 1:58 PM
> To: Metz Rebekah
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Service Consumer in RM or not?
> 
> Rebekah,
> 
> I'll refrain from the hilarity that would ensue by continuing on about
> the elephant :-)
> 
> When you buy a house, what is to become a contract is actually just an
> offer until it is signed by the vendor.  I'm not sure what you are
> getting at in your discourse on "contract".  One thing that this
> underlines, however, is that there is a ton of detail to be defined in
> reference architectures....contract negotiation may be part of an RA
for
> example.
> 
> -matt
> 
> 
> Metz Rebekah wrote:
> 
> >Duane,
> >
> >I agree that the committee needs to reach some consensus on these
> >issues.
> >
> >That said, I suggest that maybe we take a step back to understand
*why*
> >there is such difference in opinion (other than we all relish and
learn
> >from healthy intellectual debate).  We might have better luck in
> >reaching consensus on these causes rather than consensus of the
> >'symptoms' per se.
> >
> >When looking at this issue, it appears to me that what we're really
> >trying to reach consensus on is the key characteristics of these
> >constructs/concepts.  For example, I would argue that a key
> >characteristic of a message is that it its role in *exchange*.
> >Thus, it seems to me that we might be proverbially touching different
> >parts of the same elephant with blindfolds on, essentially looking at
> >the same thing but resonating more closely with certain
characteristics.
> >
> >
> >To add more fodder to the conversation, I would ask, is a message a
> >message if it is not exchanged?  In response, I looked for tangible
> >examples outside of the technical realm for metaphors that would help
> >the gap between these perspectives.  For example, my husband and I
are
> >looking to purchase a home.  When we found a property that we wanted,
we
> >put in a contract on that house.  However, it was not a contract, in
the
> >legal sense of the word, until the seller accepted the terms of the
> >contract and it became ratified.  Thus, the critical characteristic
of
> >the contract would be ratification, or mutual acceptance of the
terms.
> >I would equate this to the view that the critical characteristic of a
> >message is its exchange.  Alternatively, one could take the position
> >that a contract existed as soon as we completed the paperwork.  Only
its
> >status or state changed (submitted, ratified, rejected, etc) changed
as
> >events occurred.  I would equate this to the viewpoint that a message
is
> >a message even if not exchanged.  Both perspectives are valid, but
> >different - and have implications on the overall model we build.
> >
> >Perhaps heading toward consensus from this perspective will be more
> >unifying than divisive?
> >
> >Rebekah
> >
> >
> >
> >>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]