RE: Sun / IBM joint submission on using UDDI to locate ebXML Registries

[Anne Thomas Manes <atm@sun.com>]

My comments inline below ...

-----Original Message-----
From: sean@ireserver.Ireland.Sun.COM [mailto:sean@ireserver.Ireland.Sun.COM]On Behalf Of sean macroibeaird
Sent: Friday, April 20, 2001 2:57 AM
To: Anne Thomas Manes
Cc: Scott Hinkelman; Farrukh Najmi; ebXML Repository; Barbara McKee
Subject: Re: Sun / IBM joint submission on using UDDI to locate ebXML Registries

 

Anne,

 

- We* should register a set of canonical ebXML tModels in UDDI, including
Reg/Rep, Core components, CPP, Business Process definitions, ebXML
Specification Schema, etc.

I think this would be a very useful item for UDDI v3.0 consideration.  

 

Good idea. We should raise this requirement at the meeting next week. 

- We should develop WSDL definition for the APIs to all of these services

I'm not clear on this. Given that WSDL provides a container for a set of end points,
what do you envisage being the end points based on the APIs, e.g. entry point to an Reg/Rep,
and the contained elements within it? Alternatively is it a WSDL representation for a particular
set of entries in ebXML for a particular business, i.e. it BP definition, the core components referred to,
its CPP, etc. I get the feeling I'm missing the point here :-)  

 

Sorry, I should have been more explicit. We should create WSDL definitions for all standard ebXML APIs -- particularly the Reg/Rep APIs. WSDL supports abstract definitions as well as specific definitions. We should use WSDL to describe port types, messages, bindings, and operations (but not the actual ports) for the Reg/Rep API. The bindingTemplate for a specific Reg/Rep service entry could point to a WSDL port definition at the Reg/Rep owners discretion. You would not need WSDL definitions for core components, BP definitions, or CPP, etc -- but we should define tModels for these models.

- These tModels should point to a much more comprehensive set of
specifications (DTD, WSDL, CPP, etc.)
- We should specify these canonical tModels in this document and tell users
to reference these tModels in their service entries (rather than imply that
users will need to define their own tModels.

This would then become a Best Practice as per you  original suggestion?  

 

Yes. Absolutely.  

 

* Where "we" = someone representing ebXML

/Sean