Re: Vote: Sterling and comment on Clarification on Business Processesand their payloads

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Dale,

See my comments inline. Dont hesitate to call me if you have any additional
questions.

--
Regards,
Farrukh

"Moberg, Dale" wrote:

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

ebXML RR api will require multiple payload documents in the submission
process. ebXML Messaging services used for RR client to RR communication
must support multiple payloads. The MS spec allows for multiple payloads. I
had raised a wanring in POC that MS providers should make sure this
capability is supported.


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

PA assembly is not part of RR API. It is not speced. However, there is no
reason why a client could not take to PPs in the RR and make a PA based on
some proprietary tool. PA Assembly is not required by RR providers. A PA
assembly demo would simply show what to do with a PP once it is discovered
via the classification scheme based browse/drill down discovery features of
the RR.

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

Agreed. There is no compulsion for a RR provider to provide PA assembly.

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

I will bring a working example of classification and discovery for the f2f
and show it using a Registry Browser GUI. This should help make things more
clear. In the meantime, RR implementors please feel free to ask any specific
questions you may have. In the absence of specific questions, I want to
point out that implementation of the ObjectQueryManager in the RR service
and the ObjectQueryManagerClient in the RR client should be all it takes to
support classification and discovery.

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


begin:vcard 
n:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard