Re: Proposal: A Registry Browser GUI tool

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

I am sorry but I am still not seeing eye to eye on this. I thought the first job in POC
is to show ebXML
spec functionality in an ebXML TRP based interoperable way. Showing interoperability
with non-ebXML technologies and leverage of products and technologies is not a
priority IMHO.

That said, all of us POC participants use specific products and technologies (e.g.
Viquity hub, HTTP, web servers, Databases, LDAP, whatever) in our implementations of as
long as they are supporting the POC demo behind the scenes and are not the focus
themselves.

--

Regards,
Farrukh

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