RE: Proposal: A Registry Browser GUI tool

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

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