RE: Proposal: A Registry Browser GUI tool

[Nicholas Kassem <Nick.Kassem@eng.sun.com>]

Getting back to the original question. I think having a regrep client (i.e. 
tool) would be very nice particularly if it used ebXML TRP. I think this 
could solve another problem we have, namely that there is talk in some 
quarters that ebXML TRP is not suitable for B2C. I don't subscribe to this 
notion and it would be very good if we could dispel this myth. Thoughts ?

Nick

At 10:22 AM 9/13/2000 -0700, Krishna Sankar wrote:
>Exactly. I fully agree with you. And we *do* want to show interoperability
>and leverage. I did not mean it in another way.
>cheers
>-----Original Message-----
>From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
>Sent: Wednesday, September 13, 2000 10:26 AM
>To: Krishna Sankar; ebXML poc
>Subject: RE: Proposal: A Registry Browser GUI tool
>
>
>Krishna,
>   Our suggestion toward WebDAV and associated specs was an attempt to
>enforce the ideas that Farrukh and yourself have expounded upon.  In a POC
>team, there are bound to be members of the team utilizing technologies that
>are implemented by their employers, so to stay vendor neutral, and thus
>unbound to any technology - why not use a standard that is well out of any
>one party's hands?  This Proof of Concept is obviously going to be a hands
>on interpretation of a lot of the ebXML specification work, how will it
>synthesize without being attached to some technolog(y|ies)?
>
>Cheers!
>
>-Matt
>
>-----Original Message-----
>From: Krishna Sankar [mailto:ksankar@cisco.com]
>Sent: Wednesday, September 13, 2000 10:11 AM
>To: ebXML poc
>Subject: RE: Proposal: A Registry Browser GUI tool
>
>
>Hi all,
>
>         Let me add my 2c to the discussion - I could only remain silent 
> so long ;-)
>
>         I agree with Farrukh (for a change) in the sense that the technology
>binding would be services over the regrep APIs. And yes, UDDI jumped the gun
>by making SOAP binding as a part of the spec. May be the next version will
>abstract out that dependency.
>
>         Farrukh, I think we the ebXMLites are in aggrement with the above
>statement.
>
>         cheers
>
>-----Original Message-----
>From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
>Sent: Wednesday, September 13, 2000 9:58 AM
>To: Matthew MacKenzie
>Cc: Farrukh Najmi; ebXML poc; Krishna Sankar
>Subject: RE: Proposal: A Registry Browser GUI tool
>
>
>Mathew,
>
>Thanks for your suggestion. DW has passed this on earlier.
>
>I must stress that the task at hand in Registry Services (RS) spec is *not*
>to specify technologies but to specify functional behavior. Once that is
>nailed
>down then there *must* be a default interoperable ebXML TRP Messaging based
>API specified for accessing the functionality. Beyond that we can have any
>number
>of bindings to specific technologies (e.g. Java RMI, Corba IDL, DASL,
>SOAP....).
>
>IMHO, getting married to stuff like DASL up front is not what ebXML is all
>about.
>We can however look at things like DASL to leverage concepts and ideas.
>
>The above philosophy I propose could be applicable to any and all ebXML spec
>work.
>To exemplify that philosophy let consider UDDI as a case. It would have been
>nice if
>UDDI specified the functional behavior of the service independent of any
>technology
>(e.g. SOAP). It could then have specified a SOAP binding to the UDDI service
>and
>
>we in ebXML could contribute an ebXML TRP Messaging binding.
>
>I hope that this philosophy is consistent and resonates with my colleagues
>in
>ebXML.
>
>--
>
>Regards,
>Farrukh
>
>Matthew MacKenzie wrote:
>
> > Farrukh, Everyone,
> >
> > I have been working a lot on XML Global's registry and repository effort,
> > and as such have been investigating adopted standards that are already
> > floating around to integrate with our own core technologies with an end
>goal
> > of providing a complete registry interface.
> >
> > My main focus has been DASL (DAV Searching and Locating Protocol), but I
> > have also dived into the WebDAV spec.  WebDAV has been implemented by
> > Microsoft and included by default in their operating systems since Win98
> > OSR2 (or earlier).  Using "WebFolders", you can cut, copy, paste, delete,
> > mkdir, put and find properties on files from a familiar Windows Explorer
> > window. If a registry can "virtualize" its content and expose it via this
> > protocol, you have a GUI browser right there.  There are also open source
> > Java DAV Browsers available for download if you look for them.
> >
> > Something to think about, perhaps.
> >
> > Cheers,
> > __
> > Matthew MacKenzie
> > VP Research & Development
> > XML Global Technologies, Inc.
> > (604) 717-1100 x 107
> >
> > -----Original Message-----
> > From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> > Sent: Wednesday, September 13, 2000 7: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.