RE: tpaml concerns

[David Burdett <david.burdett@commerceone.com>]

Marty

I've already responded to Chris so Ive just made a few additional comments
where appropriate.

David

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, July 19, 2000 9:41 PM
To: Christopher Ferris
Cc: David Burdett; ebXML Transport (E-mail)
Subject: Re: tpaml concerns


Chris and David,

Since Chris beat me to the response, I will insert some comments on the
combined email and response.

Please understand that the current tpaML draft is an IBM Research proof of
concept prototype based on our experience with existing application
protocols such as OBI and RosettaNet.  Any and all parts and individual
tags should be considered to be up for discussion, and I am sure will be
thoroughly discussed.

The idea of splitting the TPA into multiple documents has also come up
inside IBM.  Some of the advantages are as David noted below.  One concern
that I have about splitting them is that there are interdependencies among
the parts in that choices trading partners make in one section can depend
on the choices they make elsewhere.  To me, having everything in one place
makes it more likely that the partners will get it right.  One possibility
is to define a tool that displays the complete set of parts as one
"virtual"  document or even permits one "virtual" document to be composed
and then splits it appropriately.  Another concern about separate documents
is that an implementer might get the idea that they don't have to implement
the whole thing.  
<davidb>I don't really buy this argument as it would be equivalent to saying
that you could implement ebXML Message Headers without implementing the
ebXML packaging. What you need to do is to make clear the dependencies in
the spec. In addition, I think that you should be able to implement the
transport part of the agreement without the business process parts.</davidb>

Defining all the parts in one specification might
alleviate that concern.  It seems clear that the business protocol section
should be coupled to BP while the rest should be coupled to TRP.  That's ok
as long as we can keep them in sync and publish them as a single standard.

Other comments are inserted below.

Regards,
Marty

****************************************************************************
*********

IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********



Christopher Ferris <chris.ferris@east.sun.com> on 07/19/2000 08:18:04 AM

To:   David Burdett <david.burdett@commerceone.com>
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  Re: tpaml concerns



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.

MWS:  I agree, as I discussed above.

> 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.

MWS:  If the above means that we need a lot of discussion of what should be
in such a contract, I agree.  What is in this draft reflects the IBM
Research team's experience with some protocols, as I noted above, but does
not mean that we covered all possibilities.

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

How so?

MWS:  Neither I nor (I assume), John Ibbotson, have any intention of
limiting TRP. Quite the contrary.  The TRP specifications are a normative
reference within tpaML, not the reverse.  An embodiment of tpaML depends on
the existence of particular fields in the TRP envelope and header which, I
believe, are already defined, but TRP should not be otherwise restricted by
tpaML.

> 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.

MWS:  Some might say that we must start with an abstract model of the TPA
and go from there.  I believe that if XML is nothing else, it is a
perfectly respectable modelling language for structured documents such as a
TPA(that is one of its main purposes, isn't it?) Of course, an abstract
model such as UML may also reveal pssibilities and suggest design aspects
that one might not think of working directly in XML.

>
> More detail is provided below. I'd be happy to go through these on the
> conference call today.

MWS:  I'm afraid I have a conflict and will not be on this call.
>
> 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.

MWS:  Working with separate specs during the standardization process is
perfectly reasonable but the result should be a single standards
specification (even if it specifies separate "sub-documents" to ensure that
a compliant implementation fully supports all sections.

<davidb>Agreed. See comments at the start about linking specs.</davidb>

> 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.

MWS:  Correct.  Negotation/discovery is a separate matter.  However one
might imagine that the partner profiles used in negotiation/discovery might
be similar to TPA templates.  Such a template would contain the information
about one partner only and the negotiation process would put the templates
together.  The templates might also need information indicating what is and
what isn't negotiable (perhaps additional attributes on various tags).

>
> 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.

MWS:  As I pointed out above, the problem here is that the partners
probably need to have all parts of the TPA visible together in order to be
able to make choices which affect more than one section.

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

MWS:  The current draft is a single document but we have carefully
established logical separations (effectively, layers) within the document.
It would be easy to decompose it into separate documents if that is the
agreed approach.  One can first discuss and revise the vocabulary and then
consider whether splitting it into separate documents is appropriate. On
the other hand, if it is agreed that tpaML should be within the purview of
the existing working groups (especially BP and TRP), then we may want to
start by splitting off the business protocol section (BP) from the rest of
it (TRP).

>
> 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.

MWS:  Actually, the only assumptions we have made are that a separate
message header specification will provide certain fields (document
identifier, request identifier, etc.) and that ebXML messaging is the
preferred such specification. We made no assumptions at all about  BP.  The
business protocol section is based on experience with existing applications
(forgive me if I am repeating here).
>
> 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.

MWS:  Chris is absolutely correct.

> 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.

MWS:  In our proof of concept prototype, the run-time framework provides
the logging (message routing) function separately at each partner.  The
only history needed in the headers is the identity of a past request to
which the current request refers.

<davidb>
I was using logging purely as an example of the uncertainty about what needs
to go in the tpa and therefore the difficulty in defining what should be in
it before we are further down the road with our work.
</davidb>

MWS:  Incidentally, we are trying to arrange for me to give a fairly
detailed presentation to at least the BP and TRP groups at the August
meeting.  I will discuss the run-time framework as well as the tpaML
grammar.

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.

MWS:  Absolutely true. Once ebXML starts working on tpaML, anything is up
for grabs though of course I would hope that some weight would be given to
the experience that my project has accumulated on this subject in the past
few years.

<davidb>Fair point. But as said earlier, I think this would should be done
by ebXML. I find it inconneivable that ebXML would adopt a proprietary
standard directly. As I said in my response to Chris's email, tpaML would be
an obvious input into this.</davidb>

>
> 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.

MWS:  I think I addressed this point earlier.

>
> 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).

MWS:  Yes, this is a critical issue.  A separate working group has the
advantage of keeping everything together but the disadvantage of being
perhaps too decoupled from BP and TRP.  Doing different pieces in the
existing working groups has the complementary risk of the pieces getting
out of sync.  Either way, we will have to invest in making sure that things
remain coordinated.

<davidb>I think one group should take overall responsibility - probably TRP
IMO - but work with BP to make sure that their requirements are
included.</davidb>

>
> 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.

MWS:  Sending a message and getting a response is itself a business
process.

<davidb>
I disagree. I think we're grossly overloading the term "business". I would
have said ...

	"Sending a message and getting a response is itself a process."

Business has nothing to do with it necessarily. If we follow your analogy,
then an email I send to a friend suggesting we go and have lunch and the
email sent back in reply is a business process that needs to be defined in a
tpa.
</davidb>

However, the real point is the one I discussed earlier.  tpaML
should be a separate specification with a normative reference to TRP.  In
that way, TRP provides messaging functions needed by tpaML but can still
serve a broader range of purposes.

>
> 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.

MWS:  For the simple case of a little customer dealing with a big supplier
via HTML, the implicit TPA is effectively defined by the browser
implementation and the customer's knowing the supplier's URL.  The mental
model we had in defining tpaML and the proof of concept run-time was two
peers doing business with server to server communications where a lot more
configuration information has to be agreed to for the application to work.
To cover the full spectrum of applications, I believe that we must design
for the big guys and understand how to simplify for the case where a
browser is sufficient.

>
> 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.

MWS:  Fine, but bear in mind that a TPA is not just an XML document. It is
an expression of configuration information for the run-time at each
partner.  Those predefined TPAs can't just be in a repository.  They have
to be instantiated at each partner before business can be done.  Again, in
some cases the only instantiation is to enter a URL into a browser but
there can be a lot more needed for more complex applications.

> 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