RE: Vote: Sterling and comment on Clarification on Business Processes and their payloads

[Mark Hale <hale@ajubasolutions.com>]

Dale,

Your made some good comments. Given the limit of the specification to the
TPA at present, the thought was to do the following:

0) For Track 2 & 3:  conversations can either be static (no registry
services) or dynamic (with registry services).  The dynamic case requires a
PA.  Track 1 was included to show a baseline PA.

1) PP would be done prior to the real-time demo for those signed up to do
Track 1.  This would be done for each using RR services but the process
would not be highlighted real-time during the demo.  We do not have an
explicit conversation defined and desired not to scope one as a time
consideration (to fit within the time allotment at Tokyo).

2) The TP formation process would follow the conversation as outlined in the
proposal.
Steps 1-4:  PP Discovery
Farrukh addressed the fact that Steps 1-4 are achieved using some of the
RegRep browsing capabilities.
Step 5:  TP Formation
The example I was going to put together would be a TP merge or union as a
baseline.  Realizing that TP Formation work is being done at present, the
intent is to show the concept that TP Formation occurs.  This would be a
client service and not a registry service.  Participants (more explicitely
Buyers) can use their own formation processes.  A union will just be given
as a baseline for the concept.
Step 6-9:  PA is agreed upon and synchronized between the parties.  Note
that the conversation does not included RegRep.

Can you add any additional insight that should be considered?  I am happy to
include more as I piece together the examples in the upcoming days.

	Thanks,

	Mark


> -----Original Message-----
> From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
> Sent: Tuesday, October 10, 2000 6:40 AM
> To: 'hale@ajubasolutions.com'; ebXML-poc
> Subject: Vote: Sterling and comment on Clarification on Business Process
> es and their payloads
>
>
> Sterling votes Yes on the direction for Track 1 and abstains
> on Tracks 2 and 3 (not doing for Tokyo)
>
> What Mark proposes to do for Track 1 is very much appreciated.
> The actor models given so far need to be tied to the Service Request
> and Responses for Registry/TPA functionality found in the RegRep
> services spec.
>
> For example, the TPP register process needs a 3 part multipart/related
> in the request. (First one for this forum, I think.)
> Is that what everyone involved plans to do?
> Will a manifest be included in ebXML header?
> And so on.
>
> Also, I do not see a spec explaining how the actual formation of a
> TPA from the TPPs occurs. The swim lanes show that happening "buyer"
> side (BP initiator side.) I actually think it is premature
> to try to do TPA formation for Tokyo, given that the first TP
> WG f2f is later this week.
>
> Registry providers do not typically
> provide the TPA formation function, as I understand it.
> If so, the role assignment chart for TPA
> formation should omit Sterling from the TPA formation role.
>
> Just how many services the RegRep provider is offering
> needs to be nailed down next week too. The classification
> and discovery machinery seems to be unclear
> in the scope of effort required and that makes
> me unconfortable about committing to supply by Tokyo.
>
>
>
> > -----Original Message-----
> > From: Mark Hale [mailto:hale@ajubasolutions.com]
> > Sent: Monday, October 09, 2000 7:13 PM
> > To: ebXML-poc
> > Subject: Clarification on Business Processes and their payloads
> >
> >
> > POC,
> >
> > I wanted to clarify my work in organizing the payloads for
> > the POC.  As you
> > know, we have three tracks each with a business process.  In
> > turn, each
> > business process is represented by a sequence diagram (or
> > conversation)
> > noted in the proposal.  Here is a summary:
> >
> > 	Track 1:  TP Formation
> > 		BP:  TP Formation
> > 	Track 2:  Retail
> > 		BP:  Item Alignment
> > 		BP:  Purchase Order
> > 	Track 3:  Automotive
> > 		BP:  Materials Management
> >
> > At each step in the conversation is a payload (Order, Acecptance, Ack,
> > etc.).  You have seen traffic concerning my working with
> > GCI/AIAG in getting
> > the payload DTDs for Track 2 & 3.  XML examples have been
> > created as well.
> > That data has been inserted into the POC draft proposal and
> > an electronic
> > version will be made to POC participants within the next few
> > days. Track 2 &
> > 3 are complete with the exception of Ack's for Track 3.  In
> > both tracks,
> > payloads were modified by me in order to fulfill an implementable
> > conversation for POC in the Tokyo timeframe.  Changes were
> > fed back to their
> > respective organizations.  Most of the changes were done to accomodate
> > Ack's.
> >
> > I began work on Track 1 late in the game resulting in some
> > confusion in the
> > manner in which it was presented in the proposal.  My intent
> > is to organize
> > the payloads corresponding to the TP Formation conversation
> > in Track 1 in a
> > manner similar to Track 2 & 3.  Hence you will see a PP and
> > PA dtd in the
> > draft sent out.  After speaking today with Farrukh, I
> > realized that this
> > should be better aligned with the tpaML DTD and I am working
> > to do that in
> > the next few days.  When I do this, you will see PP and PA
> > examples with the
> > single tpaML DTD.  Similar to Track 2 & 3, any modifications
> > that are done
> > for the conversation will be returned to the respective
> > groups for approval.
> >
> > 	Thanks,
> >
> > 	Mark
> >
> >