I think that this thought is leading us into an interesting wilderness.
There is a system of thought that codifies a lot of what you are
trying to get at. It is part of a field called (somewhat loosely)
"norms and institutions" (if anyone knows the better term, I'd be
grateful).
In any case, a quick summary:
Concepts such as contracts, purchases, money, rules, etc. are not
*real world* concepts but are examples of *social facts*.
A social fact is an assertion that is held to be true by a community
of agents -- that community operating by means of a signaling system
that the members *trust* (see below for a clarification of trust in
this context).
Unlike real world facts, social facts can be *established* -- they
can be made true simply by operating the communication system in the
appropriate manner. An example, when I sign a cheque, I have agreed
to pay the amount indicated on the cheque. Signing a cheque is,
however, different to *telling* someone I signed the cheque, or even
showing someone a picture of the signed cheque. (Cheque in the mail
anyone?)
Normally there are specific rules governing the establishing of
social facts. For example, if I sign a play cheque, or if I sign a
cheque as part of my role in a play, then I haven't signed a cheque
as far as my bank is concerned. (If you saw the movie "A series of
unfortunate events", there is an interesting example of this in that.)
(Of course, the bank might not be able to distinguish the cases of my
really signing a cheque and signing one in fun. In which case, the
signaling system is not functioning perfectly and I had better be
careful with my cheque book!)
Anyway, your house contract *becomes* an actual agreement to purchase
when the appropriate actions are performed -- according to the laws
of the land. And, again according to those same laws, the fact of the
agreement is independent of the physical paper but is in the abstract
realm of human affairs and not of the physical world. (You have still
agreed to the sale even if you lose the physical documentation. Of
course, proving that might become problematic in that case but that
is a separate issue.)
There is more to this, of course. What is of special interest to us
is that computations performed can result in establishing social
facts. That is what happens when a service is used to buy a book from
Amazon.com.
** On trust.
What is specifically required of a signaling system is that all
parties agree that when the system is performing correctly, the
signals communicated have the meaning intended. This is not quite the
same thing as trusting someone to behave correctly. (More like the
ontology assumption: that when I use the word "foo" it has the same
effect as when you use it.)
Question: Do we need this stuff to write an SOA RM?
Answer: I don't know. It helps me to keep my head clear though.
Frank
On Jun 7, 2005, at 11:12 AM, Metz Rebekah wrote:
> 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:]
>> Sent: Tuesday, June 07, 2005 1:58 PM
>> To: Metz Rebekah
>> Cc:
>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>
>
