Re: CPA composition from multi-role CPPs

[Martin W Sachs <mwsachs@us.ibm.com>]

Sorry - I forgot to push "reply to all".

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

Martin W. Sachs
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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 01/19/2001
06:18 PM ---------------------------

Martin W Sachs
01/19/2001 06:18 PM

To:   Duane Nickull <duane@xmlglobal.com>
cc:
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  Re: CPA composition from multi-role CPPs  (Document link: Martin
      W. Sachs)

Duane,

I am still having trouble buying the arguments about who does the data
transformations.  Since I am wrestling with more fundamental issues (like
completing the first draft of the CPA chapter and then dealing with the
large number of good comments received to date),
I am inclined to leave this question for the future.  However:

   I think you are saying that the sender should always transform to
   something the receiver can read.  If so, the sender has to deal with as
   many different data formats as the receiver would if it were doing the
   transforming.  An alternative view is that  if the message itself is in
   a neutral format (e.g. an XML document described by XML schema), then
   each side only has to be concerned with the transformation between its
   own internal format and the message format.  If the industry can manage
   to converge on a countable number of message formats, this should result
   in fewer kinds of transformations for everyone.

   Regarding the concern over a delay for the receiver to obtain the
   necesary data transformation software:  I can't see this as a major
   issue.  Once two parties agree on the formats of the messages sent and
   received, each has time to obtain the necessary transformation software
   and the two are doing it in parallel with other preparatory actions.  Of
   course my argument falls apart for spontaneous ecommerce but I would
   guess that for a long while, spontaneous ecommerce will only work if it
   is limited to simple situations requiring simple software at each end.

Regards,
Marty



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

   Martin W. Sachs
   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
   *************************************************************************************



Duane Nickull <duane@xmlglobal.com> on 01/19/2001 04:52:18 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "Moberg, Dale" <Dale_Moberg@stercomm.com>, "'christopher ferris'"
      <chris.ferris@east.sun.com>, ebxml-tp@lists.ebxml.org
Subject:  Re: CPA composition from multi-role CPPs





Martin W Sachs wrote:

> The second paragraph states "After receiving verification that the format
> and usage of a business scenario is correct, an acknowledgement...by the
> registry" . I don't understand "format and usage of a business scenario".
> The registry is application-independent. I don't see how it can possibly
> verify anything about the business scenario.  I would not expect the
> registry to check more than that the CPP can be parsed and that its
> metadata conforms to the registry rules.

This is all I had in mind too.  It coud have been better emphasized.
Grammar has never been one of my strong points.(as you may have guessed
by my erroneous spelling ;-)

 The latter is probably a check on
> the registry's request form and not on the CPP itself. Furthermore if we
> continue on the path of referencing rather than embedding the business
> scenario, whatever checks the registry does on the business scenario
> document will have been performed when the business scenario document was
> submitted and would not have to be rechecked when a CPP referencing it is
> submitted.

Good points!!

>
> Third paragraph:  this paragraph states an assumption that it is the
> discovering party that is responsible for performing any data
> transformations into a form in which the discovered party can process it.
> It is not obvious to me why there should be this restriction, even in an
> example (since the example will convey an impression of what the correct
> practice is).  A more appropriate scenario is that companies A and B
agree
> on the format and syntax of the documents to be exchanged.  If data
> transformations are necessary to either company, that company performs
the
> transformation before sending or after receiving the document.

This was a question that the TA team wrestled with for a long time.  We
originally had an idea that it could be done at either end however this
was revised to reflect a possible scenario.

Let's envision two parties (Company "A" and Company "B") as per the
documents' example.  Comany "B" requests Company "A's" CPP and find, via
the Buinsess Process document,  that they require an xCBL 3.0  purchase
Order document (Order.xml) and they will send back a format called
"OrderResponse.xml" as an official acceptance of the order.xml.  Company
"A", who states this in their CPP, fully understands what it is they
require,  but have no idea what other data formats other trading
partners may have.  Accordingly,  they have no idea whether or not they
are capable of performing data transformations on that data.

Company "B", who now has the data format required by Company "A", can
make a determination about whether or not they can transform the data
from their format (for example say a cXML "PurchaseOrderRequest.xml"
format) into the format required by Company "A".  If they decide yes
they can, they can transform it and send it accross.  If not,  they
chose another trading partner.

Now - let's examine what can happen if they could send it accross
without it being transformed.  Company "B" sends it and Company "A" now
has the burden of performing the transformation.  This possibly takes
more time and effort therefore their cost of sale s rises.  Also there
is no guarantee of complete transformation or even the capabilities to
semantically recognize the data.  The return confirmation, if data
cannot be recognized, cannot be given accurately either, thereby leaving
a Question as to whether or not the order was actually placed.

In the time lapse between company "B" sending the PO and Company "A"
rejecting it, several days may pass and/or other opportunities are
missed.

The most efficient path to take is a general assumption that the
receiving end cannot do data transformations (unless there is a mechnism
for an explicit statement of such in the CPP they post?).  This makes it
easier for the sending side to be certain that their business process
will succeed (or fail).   There is a great unknown variable on the type
s of incoming data so it would be extremely difficult for a receiving
company to state whether or not they can automatically (or manually)
convert all data types that are sent to them.  It was felt that more
than likely,  a receiving company making statements would at best be
able to cover only a very minute amount of possible transformation
possibilities, therefore this mechanism of stating capabilities is
likely to be incomplete and result in a lot of missed business
opportunities.

ebXML methodology works in a manner such as this:

declarations
discovery
agreement
transact

The delcarations are done via CPP's, Business processes, and GUID's on
Core Components.

The discovery makes use of those declarations to perform discovery.

The agreement phase involves knowing or understanding that enables
someone to take actions

The transaction phase is the actual run time phase.

<IMHO> a methodology of Transact, declare, discovery (with possible
reversion to a previous state) is innefficient and is in contrast to
most of the generally accepted methodologies of ebXML.

Of course,  that is just my opinion.  I am certainly not the final voice
on this and I invite alternative points of view.

>
> Fifth paragraph:  There is, of course, a bootstrapping issue here which
> surfaces frequently.  If the two companies are negotiating a CPA via
ebXML
> messaging (or any messaging for that matter), they are performing a
> business process that should be described by a negotiation CPA.  Then how
> do they first negotiate the negotiation CPA?  The answer is probably that
> vendors may wish to supply sets of CPA templates for common functions and
a
> CPA should be able to be negotiated from one of these templates by a
quick
> phone call.  Another alternative is a "middleman" negotiation service
that
> supplies a canned negotiation CPA to each of its customers.

I support your answer to this problem.  The CPA for negotiating
subsequent CPA's probably needs to be placed somewhere in the CPP
document.

" how can you ask someone how to talk to them if you don't know how to
talk to them"

hehehe

Nice

Cheers all:

Have a good weekend

Duane Nickull