OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: TPA and ebXML Header question


	Finally trimmed the addresses !

	I do agree that we should show that complex business collaborations and
processes can be developed using ebXML, during POC. But the primary goal of
the POC is to show the implementations and practicality of ebXML
specifications. The POC cannot and should not go "ahead" of the

	We all know that any of the participating organizations can develop very
exotic processes independently but can they develop these processes over
published ebXML specifications is the question. We answer that during POC
showing *representative* processes. We are finding some issues, like the
session management, we need to resolve. But once these are resolved,
hopefully by the Tokyo meeting, we can concentrate on the upper layers.

	My major concern is that the POC looses the momentum as soon as a
conference is over and then picks up about 3-4 weeks before the next
conference ! (After Tokyo, the year end and Christmas will take up time
until, again, we will be 4 weeks away from the next conference ;-0) One of
the things I am looking for is to keep the same POC team and keep on forging
ahead and have Vienna as the end game, with Vancouver as the mid point. We
should table the scenarios as we think of them (kind of a POC portfolio) and
add them to the POC while making sure that we can show traceability to the
ebXML specs.

	I have been discussing a few ideas with many of us and I think we had
communicated earlier about complex business transactions as well. Now that
the specifications are being solidified, we will be able to show some good
business processes during Vancouver.

	I think we are still on target - in SJ we concentrated on TRP, in Tokyo we
are showing off RegRep and the theme in Vancouver should and would be BP
with complex interrelated business processes.

	Another idea is to have a demo room (in the ebXML website) where we can
show different processes based on ebXML, that way we are not restricted to
the POC to show the breadth and depth of the ebXML efforts.


-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Saturday, October 14, 2000 1:01 PM
To: 'Krishna Sankar'; 'Moberg, Dale'; 'dick@8760.com'; 'Martin W
Sachs/Watson/IBM'; 'mark.hale@ajubasolutions.com'
Cc: 'Christopher Ferris'; 'Scott Hinkelman/Austin/IBM'; 'David RR
Webber'; 'Zvi Bruckner'; 'ebxml-tp@lists.ebxml.org';
Subject: RE: TPA and ebXML Header question

Forgive me for not trimming all the addressees;
didn't know where to start.

Krishna Sankar wrote:
>	This thread is getting interesting.

Isn't it?

Dale Moberg wrote:
>Applications could handle session, if they were newly created to know about
>PIPs, choreographics, and the more elaborate forking and joining BPs
>that Krishna clearly describes.

I am absolutely certain that new business applications will
emerge to handle complex collaborations between trading
partners.  In fact, this is happening already, and the EDOC
framework that several ebXML participants have been working
on is aimed at this position.

The BP metamodel has very clear provisions for more complex
choreographics which it calls BusinessCollaborations.
One BusinessCollaboration can be composed of many
CommercialTransactions, and each CommercialTransaction
can be composed of more than one BusinessDocuments.

The Economic section of the BP metamodel contains
the elements that can relate different transactions.  For example,
Order-Fulfillment-Payment, or Contract Negotiations,
or Bidding, or even Negotiated Order Acceptance where
the order may need to go back and forth with changes
before being accepted.

The order acceptance that is being done now both in
ebXML POC and often in "real" e-commerce is a joke,
witness the companies in trouble for taking orders
they couldn't fill last Christmas.  We could at least
do an automated Available-To-Promise query
with a human-judgment alert on failure.  (Not
proposing to add this to the Tokyo POC, by
the way, but some vendors said they could do it.)

There is more to business collaboration than sending
one isolated document, and the usual internal business
application systems have no idea how to collaborate.
I'm not sure how far ebXML will go in this direction,
but the hooks exist in the metamodel.  I'd like to
see at least one multiple-transaction scenario happen
in Vancouver, and would be happy to help anybody
who wants to work on one.

Have fun,
Bob Haugen

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC