[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][pfbm] -- Getting started
i *think* that it can be set in some implementations (UDDI4J -- doubt ibm/ms/hp/et al would let you request a key :o) therefore, i suppose the process would be to have a key generated by a UDDI source and feed it to the internal PDDI for the service. not sure what this solves though. your client will still have to have a UDDI server defined (i don't believe that there is the concept of lookup hierarchy in UDDI: search X, if you don't find, search Y). my gut feeling is that most corporations that are willing to implement a PDDI solution are not likely going to want to register internal services in a public forum. b On Thu, 2002-04-04 at 14:19, Jeff Broberg wrote: > is there anyway for the internal and external tModel key to be the same ? > > -----Original Message----- > From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com] > Sent: Thursday, April 04, 2002 10:59 AM > To: jbroberg@silverstream.com > Cc: bill parducci; wsrp@lists.oasis-open.org > Subject: RE: [wsrp][pfbm] -- Getting started > > > > > The tModelKeys are generated and returned by UDDI directories after > publishing interface descriptions. In the case of the global UDDI, we - the > WSRP TC - could publish the WSRP interface definition, obtain the tModelKey > under which it then is registered in UDDI and then document this tModel key > as THE WSRP tModelKey (in the scope of the global, public UDDI). > > In the case of a corporation who wants to use WSRP internally, the > corporation would have to publish the WSRP interface definition, and the > resulting tModel Key would not be the "standard" one, but a different one > valid only in the corporate UDDI. In the scope of that UDDI, that tModel > would have to be used. > > Best regards, > > Thomas > > > > "Jeff Broberg" <jbroberg@silverstream.com> on 04/04/2002 05:30:45 PM > > Please respond to <jbroberg@silverstream.com> > > To: Thomas Schaeck/Germany/IBM@IBMDE, "bill parducci" > <bill@parducci.net> > cc: <wsrp@lists.oasis-open.org> > Subject: RE: [wsrp][pfbm] -- Getting started > > > > I agree, the tModel is probably where we should focus. I am not sure, of > the subtleties between the private and public registries in relation to > tModels, could you elaborate ? > > -----Original Message----- > From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com] > Sent: Thursday, April 04, 2002 8:33 AM > To: bill parducci > Cc: wsrp@lists.oasis-open.org > Subject: RE: [wsrp][pfbm] -- Getting started > > > > In the find part, I think the essential thing is to specify the tModel Key > to be used for finding WSRP services (this would have to be the tModel key > we obtain once we publish the WSRP WSDL interface definition to UDDI) > > The WSRP spec could then say someting like "WSRP services can be found in > UDDI by searching for the tModel key ... " > > Maybe it is somewhat more complex, for example we'll also need to specify > what to do in private UDDIs, but in principle, this kind of description > should be sufficient for portal vendors to write code that queries UDDI for > WSRP services. > > Best regards, > > Thomas > > Thomas Schaeck > Architect, WebSphere Portal Server > IBM Pervasive Computing Division > Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: > schaeck@de.ibm.com Fax: +49-(0)7031-16-4888 > Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 > Boeblingen, Germany > > > bill parducci <bill@parducci.net> on 04/04/2002 12:57:23 AM > > Please respond to bill parducci <bill@parducci.net> > > To: wsrp@lists.oasis-open.org > cc: > Subject: RE: [wsrp][pfbm] -- Getting started > > > > /* > - From interactions with customers and others involved with web services > currently, I've found few that really are pushing on the 'Find' part of > PFBM. Most folks are dealing with services they explicitly know about. > */ > this is consistent with what i have seen as well. > > /* > So I would propose that WSRP really doesn't need to invent anything new in > the 'Find' arena, unless of course the requirements we converge on for > 'PBM' > have some implications on what can be supported with the current UDDI > specs(which I'm not a SME on). > */ > my experience with UDDI is that you will be hard pressed to merge its > current capabilities into anything meaningful unless you are limiting > your scope to intrAnet applications. > > b > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > ---------------------------------------------------------------- > 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