Re: Proposal: A Registry Browser GUI tool

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

Dale,

See my comments below. Forgive me in advance if I misinterpretted any of
your comments since this is a speed read/response.

"Moberg, Dale" wrote:

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

Some have made a valid argument that TPA assembly is a service that should
not be part of core Registry Services (RS).
However, in the absence of another spec and since it is IMHO so important,
we have it in RS at the moment. The merge involves
superimposing two Party Profiles (half TPAs if you will) into one concrete
TPA.

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

If by *this* you mean TPA assembly, I think it is relatively staright
forward for the simple assembly (merging of 2 Party profiles)
More advanced TPA assembly from more discrete TPA elements in not being
addressed for Tpkyo.

If by *this* you mean the Registry Browser tool, then I think that it could
be done if a participant could do that and only that
with all their focus while working with a Registry provider of their choice
(Sun is one). Krishna, has privately experssed some interest in taking on
this task though he has other things he would like to do as well. Krishna
please share your thoughts.

In any event all of this RS functionality is agressive but I hope we RR will
meet our comittments. I am begining to think that maybe I should send an
updated matrix where I focus on one thing Registry Services provider (back
off from being buyer/seller)

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

The process I think we are following is to make up matrix with proposed
functionalities from all proposals on one axis and
participants on another. Each participant then fills out cells in the matrix
to indicate they are comitting to providing that functionality in POC demo.
If some functionality does not have any takers then I assume we will not do
it for Tokyo.

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