[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][pfbm] -- Getting started
We may be talking of two different problems here ... 1. How to find WSRP services in 1a) Public UDDI - WSRP TC to publish WSDL interface definition, the resulting WSRP tModelKey to be used for searching for WSRP services in the public UDDI 1b) Private UDDIs - If the UDDI allows a WSDL to be registered under a given tModel, use the same one under which the WSRP interface is registered in the public UDDI. If the private UDDI in use would not allow this, the WSRP WSDL would have to be published and the resulting locally valdi WSRP tModel would have to be used in the scope of the intranet. 2. How to advertise a service both public and private - To publish a WSRP service in the public directory, publish under your business and the WSRP tModelKey. To publish a WSRP service in the private UDDI, publish under your business and the WSRP tModelKey valid in the scope of the private UDDI to which you publish (which should be the same as in the global UDDI) I think we probably should start taking this down in two paragraphs as a basis for more detailled discussion and later input for the spec (To publish a WSRP service, the producer does ..., To find a WSRP service, the consumer ...). Carsten, I know you have implemented something very similar in you job, - could you please take a first cut at writing up the detailled steps for publishing a WSRP service and finding a WSRP service in UDDI ? I think the search order of a portal (lookup in private, then in public, etc) would be out of the scope of the standard. (Nevertheless interesting) This would be up to the implementation of portral servers. Best regards, Thomas bill parducci <bill@parducci.net> on 04/05/2002 06:23:10 AM Please respond to bill parducci <bill@parducci.net> To: jbroberg@silverstream.com cc: Thomas Schaeck/Germany/IBM@IBMDE, wsrp@lists.oasis-open.org Subject: RE: [wsrp][pfbm] -- Getting started my guess is that the same service will have multiple entries (one public and one private) much how dns works today for web servers. this only solves the issue of allowing external entities to locate a shared service, not allowing internal clients access to both communities (unless i am mistaken about the lack of passthourgh queries: search local then remote, as is the case with dns) b On Thu, 2002-04-04 at 19:51, Jeff Broberg wrote: > I was just trying to find a way so that the model works the same in both an > intranet where the corporation maintains its own uddi registries, and where > it potentially exposes some of its services to external ones. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC