RE: Proposal: A Registry Browser GUI tool

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

I think it's inappropriate for the ebXML POC to showcase proprietary 
technologies and I understand that one person's "defacto" standard is 
another person's open standard. I am obviously highly supportive of 
specifying (in an open forum) functionality that we think is consistent 
with ebXML's overall mission and charter - but we need to draw the line 
where we prematurely bind the functionality to technologies that have the 
potential of impacting open interoperabitlity.

The TRP WG has specified functionality that does not preclude private (i.e. 
non interoperable) implementations of the specifications but the POC WG is 
unlikely to showcase such implementations. Why anyone would really want to 
have a non-interoperable ebXML implementation is beyond me but I'll leave 
that to the bean counters to debate.

I therefore propose we follow the TRP model for regrep. Lets get the 
functionality and associated messages nailed first. There is plenty of 
opportunity for vendors to have private implementations/solutions (and yes 
even non-interoperable ones !!) once the specs are done.

Hope this helps.

p.s. I think binding UDDI to SOAP was a mistake and hopefully (as Klaus has 
already suggested) they will correct this in a future release.

At 10:26 AM 9/13/2000 -0700, Matthew MacKenzie wrote:
>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.