Re: Proposal: A Registry Browser GUI tool

[Christopher Ferris <chris.ferris@east.sun.com>]

N.B.

The assembly/merge of two TPP's into a TPA is a relatively
trivial XSL transform assuming that both share a common
business process (exactly) and each can assume a complementary role
in said process.

Again, that is a non-trivial assumption which is why I 
feel that there must be some degree of negotiation which 
cannot be assumed to be automatable, at least at this stage of
our development.

Cheers,

Chris

Farrukh Najmi wrote:
> 
> 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.
> > >

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903