RE: [wsrp-pfb] UDDI questions

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: Message

So, is it ok to publish a "wsdl" document if we define a tModel? Have a look at the "CTXS test" business on test.uddi.microsoft.com. The access point for the "testOracle" service is:

http://portalstandards.oracle.com/wsrp/jaxrpc?WSDL

Which is the full wsrp service wsdl doc for that producer. The tModel for this is called "WSRP" but should be something like "WSRP-WSDL". This seems a quite natural use of UDDI that we IMHO should address.

For handles, if using "access point", we would need to compose more than one "access point" together to invoke the service as the handle is not enough by itself. You need both the "handle" and the wsrp interface(s) (a full service wsdl or ports in UDDI) to use the handle on. Is this stretching the "access point" concept too far? What's the most usual way to represent a value that is required to be passed into one or more Web Service interfaces?

thanks,

Andre

 -----Original Message-----
From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent: 15 October 2003 16:15
To: 'Andre Kramer'; wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] UDDI questions

Andre,

 

Thanks for your questions and sorry for the late answer.

Please find my comments inline <CvR></CvR>.

 

Claus 

-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Dienstag, 7. Oktober 2003 18:55
To: Von Riegen, Claus; wsrp-pfb@lists.oasis-open.org
Subject: [wsrp-pfb] UDDI questions

Hi Claus,

Could you point us at the best practice text that states that publishing a "wsdl" in UDDI results in actual non-compliance?

My opinion (voiced on the call) is that people will want to publish a WSRP producer's wsdl as a "service" and therefore we should support this (simple / intuitive) use case. This would add a "wsrp wsdl" tModel used to classify a binding template which we would define (extending the pre-defined "wsdl" tModel - if I understand UDDI).

Is this something we are actually prevented from doing? Or do we need to do something more to meet minimal requirements? [Or any technical arguments why this is a really bad idea.]

<CvR>One of the recent versions of the specification outline for portlet publication mentioned that a businessService should be published that does not contain a bindingTemplate - this may have been a misinterpretation. As long as we develop "standard" tModels that represent WSRP WSDL portTypes and bindings and reference them in bindingTemplates that represent the actual portlets, we conform to the general UDDI model and can meet the requirements of the "Using WSDL in UDDI" Technical Note.</CvR>

Another question I have for you concerns publishing our portlet handles (a producer assigned unique identifier). What would be the best mechanism for publishing these in UDDI? We could put them in a per-portlet server's binding template but these are not "endpoints" or even URIs (e.g. portlet1, portlet2 ... portletN). Would a keyed reference be more appropriate? In which case, do we need a binding template at all, as we have nothing concrete to publish (just the service entry with type info and a "portlet handle" keyed reference (and possibly a link to the hosting wsrp producer service - i.e. it's wsdl :-)?

[In WSRP, a consumer normally does a getServiceDescription() call on one port type which returns a list of portlet descriptions. Each description includes a handle for the portlet that the consumer uses to invoke that portlet, over other port types.] 

<CvR>Since I don't know too much about WSRP, I'm not sure if I got the idea. The question on how to model portlet handles in UDDI depends on what you want to do with them. If you want to use to parametrize your queries, then you should better develop a corresponding category system and put the handle in a keyedReference within a categoryBag. It it is something you use for "invocation", the bindingTemplate's accessPoint seems to be appropriate.</CvR>

We understand that service identifiers are registry specific and not producer chosen so these can not be used without a mapping by a wsrp producer. Is this correct? 

<CvR>This assumption is correct for UDDI V2. In UDDI V3, you can use publisher-assigned keys, for example, domain-based keys.</CvR>

 

thanks,
Andre

-----Original Message-----
From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent: 07 October 2003 12:39
To: 'Alan.Kropp@vignette.com'; wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] Groups - Publish/Find/Bind Telecon modified

Alan,

I'm sorry, but I am on the road tonight. I'd be happy to discuss the issues by mail, if possible.

Claus

-----Original Message-----
From: Alan.Kropp@vignette.com [mailto:Alan.Kropp@vignette.com]
Sent: Montag, 6. Oktober 2003 19:44
To: wsrp-pfb@lists.oasis-open.org
Subject: [wsrp-pfb] Groups - Publish/Find/Bind Telecon modified

Publish/Find/Bind Telecon has been modified by Alan Kropp (Alan.Kropp@vignette.com).

Event description:
US toll-free:  866 257-1032
US toll:       +1 650 260-9022
Meeting ID:    0864

Agenda:
I've captured a couple of the discussion points via email of the last week or two, so we can plan on exploring these during the call:

1.  Publish registry binding details as normative parts of the specification, or separately in one or more non-normative "binding" documents?  I think the answer is we look to what some TC's have done (e.g. UDDI) in the form of "Technical Notes".  These are separate from the spec, but provide detailed guidance (don't know if we call this "normative") for implementers.

2.  Claus raises the issue of UDDI wsdl technote compliance in terms of our _not_ putting detailed binding information in a bindingTemplate, which is what we're proposing by making endpoint information available exclusively in the Producer-specific wsdl.

Date:  Tuesday, 07 October 2003
Time:  09:00am - 10:00am Pacific Time

This event is one in a list of recurring events.
Other upcoming dates include:

Tuesday, 26 August 2003, 09:00am to 10:00am Pacific Time
Tuesday, 09 September 2003, 09:00am to 10:00am Pacific Time
Tuesday, 23 September 2003, 09:00am to 10:00am Pacific Time
Tuesday, 21 October 2003, 09:00am to 10:00am Pacific Time
Tuesday, 04 November 2003, 09:00am to 10:00am Pacific Time
Tuesday, 18 November 2003, 09:00am to 10:00am Pacific Time
Tuesday, 02 December 2003, 09:00am to 10:00am Pacific Time
Tuesday, 16 December 2003, 09:00am to 10:00am Pacific Time

View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-pfb/event.php?event_id=2628

PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web
browser.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-pfb/members/leave_workgroup.php.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-pfb/members/leave_workgroup.php.