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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

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

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


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



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

[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