Re: Parties and Partners

[Christopher Ferris <chris.ferris@east.sun.com>]

David/All,

All worthy points, but I think that the key point in all of this
is that there IS an agreement involved at some level whether you know it or not.
Whether it is a formal TPA or not is another issue altogether. 

- Your cell phone needs to know *how* to communicate with the Coke machine before
  you simply beam your cell phone at it to get a coke.
- you have an agreement/contract with your credit/debit card issuer
- the coke machine/vendor has one of these as well with each issuer or
  with each service (visa, mc, amex, discover, etc.) This might be a formal
  TPA or simply some contract that the vendor signs. I'm not privvy to
  how credit card services handle this...
- your cell phone has a CPP which describes its capabilities
  which it would match against that of the coke machine
  in some discovery/negotiation dance to establish a CPA
  to effect the actual exchange of messages. 
- more than likely, there is an explicit CPA template
  which Coke has for its machines and which all cell phone
  manufacturers would provide (or could be d/l'ed to the cell
  phone off of the web) along with the requisite software components
  to engage the CPA. Included or associated
  with the capabilities in the CPP are some identifier(s) to information
  which describes the "party" who "advertises" or exposes the CPA template

I think that the problem we're all having here is with terminology.
"Trading Partner" and "Partner" all have all sorts of contextual
baggage which make it seem as if it is only oriented towards formal
b2b exchanges. That is why we in TP have chosen slightly less offensive
language to describe what we're cooking:

	Collaboration Protocol Profile (formerly TPP)
	Collaboration Protocol Agreement (formerly TPA)

A CPA can be associated *with* a formal TPA or other form of agreement, 
but need not be. What it describes is an agreed upon set of protocols
which are to be used in the engagement of the process at a technical
and process level. 

Hopefully, this addresses people's concerns and makes it abundantly
clear what it is that the former tpaML is evolving to and was actually
meant to represent.

If you read the tpaML specification, you'll find that it is described as
an electronic configuration file, nothing more.

As for the terms "partner" and "party", I think that "party" is the one
to which most can relate. As Peter K has pointed out, "partner" has specific
legal definition which doesn't apply in all cases of b2b (or otherwise) 
e-business. IMHO, a "party" need not be explicitly related to a "market",
it just identifies some entity which can enter into a "transaction"
which is enforced by some agreement either direct or implied, legal or
simply technical.

<engages_flame_retardant_suit>
Maybe, what we should be using is the term "principal" instead of "party"
or "partner". 
<engages_flame_retardant_suit/>

Cheers,

Chris

David RR Webber wrote:
> 
> Message text written by Murray Maloney
> >We agree that the Coke machine has to publish its interface, but I
> don't see that being a 'Trading Partner' agreement.
> >
> >Since the GSM server will not let just anyone (or Coke machine!) talk to
> >it, there is a TPA there somewhere!
> 
> I think that the cell phone subscriber has a TPA with a cell service
> provider.
> And the owner of the Coke machine probably has a TPA with the ASP.
> And the ASP has a TPA with the cell service provider.
> 
> But the cell phone subscriber and Coke machine do not have a TPA.
> >
> <<<<<<<<<<<<<<<<<<<<<
> 
> Murray,
> 
> Let me introduce the term "Proxy TPA", I believe this is what we have
> here - and its an important part of the architecture, and happens all
> the time in business.   When I authorize the cellular company to
> debit my account for transactions I effectively enable that Proxy TPA.
> 
> One thing that has come to my attention is that our beloved Coke
> machine here is acting in a B2C role, and thus technically is
> out-of-scope for V1.0.   However, its importance is that it shows people
> what is to come, and how they have to change their paper based views
> of business.   I think we should look to include a 'Future Support' or
> similar section in the TA to show the forward thinking as well.
> 
> My assumption is that the Coke machine can use Bluetooth to do
> local networking with Bluetooth enabled devices.  We should
> include an interaction diagram to show the physical architecture,
> and also the logical interaction architecture.
> 
> But wait - there's more!  The Coke machine does have B2B capabilities.
> When we factor in the backend support intrastructure - we get lots of
> B2B.  The Coke machine can automatically order refills when it gets
> low; it can change the order mix depending on the frequency of
> product sales; and track its own seasonal use, so it can anticipate
> higher sales periods.  And then all those electronic payment
> transactions have to get reconciled by the backend accounting
> systems.   Then you have maintenance and support - it can
> request that too...
> 
> Yes, maybe the Coke machine gets it own separate little document?
> A Day in the Life of a Coke machine - 2001, the Trilogy.
> 
> Would make a good supplement to the TA document.
> 
> DW.

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903