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:]
> Sent: Thursday, April 04, 2002 10:59 AM
> To:
> Cc: bill parducci;
> 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" <> on 04/04/2002 05:30:45 PM
>
> Please respond to <>
>
> To: Thomas Schaeck/Germany/IBM@IBMDE, "bill parducci"
> <>
> cc: <>
> 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:]
> Sent: Thursday, April 04, 2002 8:33 AM
> To: bill parducci
> Cc:
> 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:
> Fax: +49-(0)7031-16-4888
> Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
> Boeblingen, Germany
>
>
> bill parducci <> on 04/04/2002 12:57:23 AM
>
> Please respond to bill parducci <>
>
> To:
> 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>
>
>
