Re: Proposal: A Registry Browser GUI tool

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

My thought was that the tool would use ebXML TRP Messaging for exactly that
reason.

Nicholas Kassem wrote:

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