[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Proposal: A Registry Browser GUI tool
I might have missed something but are we still planning to have an automated TPP merge capability in the registry (if all that is needed is just to adjust the partner-- oops, party-- identities.) I still am not certain how the merge or TPA formation was to work within the registry. Farrukh, do you think that is a reasonable thing to complete for this POC or maybe that it will take a little more time? Also, I am not clear on how all these proposals for functionality for the POC get merged. Does someone like say Nick ;-) supply that service? Do we have to thrash around reviewing each one and then reach a consensus (yikes). Dale Moberg > -----Original Message----- > From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com] > Sent: Wednesday, September 13, 2000 10:05 AM > To: ebXML poc > Cc: Krishna Sankar > Subject: Proposal: A Registry Browser GUI tool > > > > Maybe this is already covered by one of our many excellent POC > suggestions but.... > > This idea came about in a converstaion with Chris Ferris > recently and I > then bounced it off Krishna. > > > We should consider adding a functionality to Phillipes POC > functionality > matrix for a Registry Browser GUI tool. > > (As an aside we should have line items for other GUIs as well such as > buyer GUI, seller GUI, Message Monitor GUI etc.) > > The Registry Browser GUI tool would be a client of the > Registry Services > and would allow a human user to use a browsing > oriented navigation to sift through the Parties registered > and find the > Parities that match their needs. The tool would make use > of RegRep object classification support ((not yet speced but soon will > be)) to drill down to the interesting Parties. They could then > get the associated Party Profile Object Association support (not yet > speced but soon will be) in Registry Services. > > A second GUI (potentially in the same GUI application), a TPA > Assembler > tool, could then be used to assemble the TPA between the Party > represented by the tool user and the Party selected by the user. > > Once a TPA is established the parties could conduct the rest > of the demo > based on ebXML TRP messaging. > > I realize that the "(not yet speced but soon will be)" aspects are > risky, but we are working very hard in RegRep to make it happen by Sep > 21st. We are working closely with other WGs that are defining > meta-models for their specific areas on the classification support. > > I have run this idea by Krishna since he had good insights > and interest > in the discovery area. Note that this scenario shows > discovery based on > up and coming ebXML specs (not eCo and not UDDI). Krishna was > supportive > of the thoughts at a high level and had some additional ideas. I think > we should start some dialog on this subject to get the teams input. > > Thanks for your thoughts and comments. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC