Re: tpaml concerns

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

David/All,

Please see below.

Cheers,

Chris

David Burdett wrote:
> 
> Firstly
> 
> Many apologies for being out of the loop for so long on TRP activities, but
> I am just beginning to surface and have had opportunity to go through the
> tpaML spec and the several emails around it.
> 
> Although I think agreement of the conditions or contract between the parties
> involved is an important part of carrying out eCommerce. I really think that
> the current structure of tpaML is not the best way to do it.
> 
> In outline my concerns (which I expand on below) are:
> 1. the current tpaML contains multiple sections of a contract that should be
> separate documents

I agree. I have spoken with John I about this. For instance, Party
info would be likely retrieved from a Directory server. Ideally, it
should also follow the DSML vocab closely. Of course, the tpaML document
instances could simply be a "view" of a number of "documents" or
sources as merged by a stylesheet. In general, I think that this
is really more of an optimization point than a true failing of
tpaML.

> 2. we're defining the terms of a contract before we know what we want to
> agree (i.e we're putting the cart before the horse)

I don't follow. tpaML is an encoding of an agreement.

> 3. making TRP dependent on a pre-existing tpaML will cause a barrier to the
> use of TRP

How so?

> 4. the current data elements need to align with core components work.

Core components is not defining elements, they are defining a methodology
and model for *describing* them. There is no reason in my mind that we
need to model tpa *before* we have a schema/DTD. It should be a trivial
excersize to model tpaML after the fact and store the bits in RR according
to CC model, etc.

> 
> More detail is provided below. I'd be happy to go through these on the
> conference call today.
> 
> If any of these points have been covered previously in the F2F then I
> apologize.
> 
> David
> 
> tpaML HAS TOO MANY FACETS
> =========================
> The current tpaML document contains sections that describe:
> 1. The business process and document exchanges
> 2. How the documents in the exchange should be transported.
> 
> I really think that these should be defined separately as they will
> frequently be independent of each other. For example a company could have:
> * a standard method of doing a business process that could work over many
> transport protocols, and
> * several different methods of transporting the messages associated with
> that business process.

Agreed.

> 
> This will lead to replication of the business process definition and/or the
> transport rules that are not required. It could also result in
> inconsistencies in definitions.

Agreed, again, the tpaML instance need not necessarily be thought of
as definitive. It could merely be a view of a transform/merge of a
number of separate sources. This does not mean that I wouldn't favor
having tpaML be amended to reflect a proper separation of concerns
(e.g. with a tpaML instance doc linking to (xlink) or referencing
say the transport details, the process details, the party details, etc.

> 
> I think we need to:
> a) create separate specs for each section of the existing tpa spec where
> each defines a subset of the total tpa that *has* to be negotiated at the
> same time

Not a bad approach.

> b) specify a very short "full tpa" spec that defines how to link previously
> agreed sections together
> c) develop a separate "negotiation" business process spec that defines how
> to negotiate any of the above - this though should be done by the BP team

Agreed that BP owns responsibility for defining the negotiation aspect.
However, tpaML makes no claims on negotiation/discovery.

> 
> To draw a data modelling analogy, the current tpaML spec is "unnormalized"
> whilst the actual data itself should be normalized.

Agreed.

> 
> Further benefits of separate specs are:
> a) we can separately revise each part of the tpaML spec, so for example if
> we want to change the transport related aspects of the spec we can do so
> without changing the business parts and vice versa
> b) in the instance, two parties can negotiate a changed or improved business
> process without having to re-negotiate the transport, and vice versa.

I don't see what this has to do with the organization of the tpaML
vocabulary itself.

> 
> WE'VE PUT THE CART BEFORE THE HORSE
> ===================================
> When I look through the tpaML spec it seems to make many assumptions about
> what is required to support TRP or BP.

Both in fact.

> 
> I find this hard to accept when we haven't even finished the TRP spec yet.

Research into tpaML predates ebXML by years as I understand. It is certainly
a good starting point IMHO. I think that if we find that there are changes
necessary, that these will likely be considered.

> Until we do, we won't know what we will need to negotiate. For example in an
> earlier version of the header spec, we included the idea of message routing
> history. We might (or might not) put it back in. If we do, it's quite
> conceivable that the maintenance of a routing history might be a
> configurable item in which case it needs to be agreed between the parties
> involved and therefore part of the tpa.

Quite possibly, but again, nothing is cast in concrete. If we find that
there are elements which are needed in tpaML to support our requirements,
I am confident that we can submit these for consideration. Marty/Scott and John,
please feel free to comment.

> 
> The point I'm trying to make is that we can't work out what should be in the
> agreement (and therefore the tpa) until we know what we need to agree.
> Secondly, only the group that is working out what needs to be agreed can
> specify what goes in the TPA anyway.

I'm not sure I follow.

> 
> So what I think we should do is:
> a) develop separate tpa sections for each area (see previous comment)
> b) place responsibility for developing each section on the part of ebXML
> that is developing it, e.g. TRP for transport, BP for business process, etc
> c) develop the specs for each tpa section as part of the development of
> activity of the appropriate working group

This is certainly an approach to be considered. However, I think
that we should be veeeewy cawefuw that we not fragment the concept
to the point that it is lost. There are likely to be cross domain
issues and we cannot have these separately developed (IMHO).

> 
> WE'RE CREATING A BARRIER TO THE ADOPTION OF TRP
> ===============================================
> Firstly if tpaML remains monolithic (as currently defined) then it means
> that TRP can ONLY BE USED AS PART OF A BUSINESS PROCESS. This just doesn't
> make sense as sometimes you just want to send a message reliably to someone
> and get a response back.

I disagree.

> 
> Secondly in many instances, there will be standard "agreements" on how to
> send messages that do not need any pre-agreement. For example, if we want to
> send an email we don't agree in advance with someone that if they don't
> reply we will resend the message, but if they've already received it they
> should ignore it.

This implies an implicit TPA as we have discussed. In your example, there
is an agreement that party A can send party B an email via Party B's email
address. True, it is a very light-weight TPA, but it is a TPA nonetheless.

> 
> I am very firmly of the belief that it should be possible to do TRP without
> having to agree a tpa first.

We discussed this in the f2f. There might be a tpa template which defines
a one-sided agreement. This is equivalent to say Amazon.com. Between customer
and Amazon.com, there is an imposed TPA over which the customer has no say.
Take it or leave it. All that needs to be negotiated is the Customer info
which is collected as part of the registration process.

> 
> To solve this problem, what I think we should do is:
> a) predefine a number of "standard" tpas for transport purposes and give
> them standard identifiers

Quite possibly a useful thing to do.

> b) allow messages to be sent, without prior negotiation or agreement,
> provided they reference  one of the predefined tpas

See above. This does not invalidate tpaML as being a useful expression
of the implicit agreement.

> c) if the recipient of a message cannot handle the predefined tpa, then
> reject the message with an error

Of course!

> 
> ALIGNMENT WITH CORE COMPONENTS WORK
> ===================================
> This has already been covered by other emails but I also think it important
> that element definitions inside the tpa adopt the structures developed by
> the Core Components group.

See my previous comment. CC does *NOT* define components, only the 
methodology and model by which *describes* an element and a context-based
approach by which elements can be assembled into a schema/DTD.

Domain experts get to *define* and describe their CC elements.

> 
> Product Management, CommerceOne
> 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

-- 
    _/_/_/_/ _/    _/ _/    _/ 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