[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-pfb] Groups - Publish/Find/Bind teleconference added
Hi Richard, see <ak> below.
regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 07 June 2003 20:39
To: wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] Groups - Publish/Find/Bind teleconference added
Hi Andre,
currently I'm sitting in a plane so I can't explore your test business
(wish air planes had UDDI access :-) ).
<ak> Soon airliners will have WSRP displays so all you need is a UDDI Portlet! </ak>
However your minimal level of support reminds me of what the UDDI best
practices document version 1.0 describes.
Here they deal with the topic on how to publish a service wsdl into UDDI.
This is basicly the same you are doing here (which is not bad btw.)
Maybe we could/should align here.
<ak> Yes, I was aiming at approximating this best practice but keeping it minimal.
I think all that needs to be added is the WSDL tModel key to say this is
a WSDL service (a fact that can be readily inferred). </ak>
Currently you are publishing a WSRP portlet and I think there is no notion
of whether you are publishing a portlet or the producer.
I think we agreed that it should be possible to publish both: producers as
"meta services" and portlets. In both cases I could imagine to have them
both published as UDDI:businessServices.
<ak> What I publish is the same for a wsrp service or a portlet: a service wsdl.
On discovering the UDDI "service" you can do a getServiceDescription() and check
if the "service name" is one of the publicly offered portlets. If so then the
service is for a particular portlet (by convension check each handle against the
service name). </ak>
Therefore I would propose either a categorisation tModel which could contain
key values like: WSRP:Producer or WSRP:Portlet to indicate that the
businessService is a Producer or Portlet.
<ak> My thinking was to keep everything as minimal as possible. Then add
extra information. Just like the WSDL flag above we can add another (optional)
tModel "WSRP:Porlet" to be used in an additional instance info. As I always publish
the full WSDL, we do not absolutley need the "WSRP:Producer" flag but more such
flags could be added (as they are ignored if not understood).</ak>
Furthermore I think we should not map PortletHandles to businessService
names.
The Portlet handle is not necessary a meaningfull thing while a
businessService name should be something users could use to identify the
purpose of a service and to find a service. e.g. searching for "stock"
could deliver all StockQuote services.
Therefor I would mandate to include the portletHandle also in the published
UDDI structures (not saying here how).
<ak> That's more than the minimal publishing approach I'm exploring. I still
favour the new "getPortletHandle()" method / new Factor for getting low -
level handles. </ak>
I think by starting with eloborating on details (and I certainly pushed
that with my proposal) maybe we go to deep into a lower level.
Maybe we should start with some use cases first. This could help us to
determine what we really want and agree on. Then we could step deeper into
details.
<ak> Yes, I'm trying to meet the minimal use case where UDDI is just used to
discover a WSRP service wsdl. </ak>
When speaking of use cases I espacially would focus on find scenarios. From
these we could easily determine the publish scenarios and then the
technical details.
I try to come up with some once I return back home next week.
<ak>I think the trade-off will be extra meta info v.s. amount of scaffolding
one has to set up (for UDDI < 0.3 this has to be done for each registry).
If we enable minimal (standard) publishing and discovery for tools & admins
in the simplest form possible then we maximize likely adoption.
We can then add on more (optional) information, especially going up
UDDI versions, to help with our more sophisticated scenarios.</ak>
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 06/05/2003 05:03 |
| | AM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'Alan.Kropp@vignette.com'" <Alan.Kropp@vignette.com>, wsrp-pfb@lists.oasis-open.org |
| cc: Andre Kramer <andre.kramer@eu.citrix.com> |
| Subject: RE: [wsrp-pfb] Groups - Publish/Find/Bind teleconference added |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
As ground work for pfb, I wanted to look into a *minimal* level of support
for publishing WSRP in UDDI.
The results of my experiment are "discoverable" at
http://test.uddi.microsoft.com (search for business / provider "CTXS test"
and dig into the "testIBMportlet" service (ask me for help if you also find
the "Search" UI a bit unintuitive).
This service has one binding with an access point that references the IBM
test producer's wsdl doc (
http://wsrp.dyndns.org:8080/wsrp/wsdl/ibm_wsrp_service.wsdl) and has a
single instance info tModel called "WSRP" (this should be named WSRP1.0,
but it's going to be a registry private name & key for UDDI 2.0 in any
case).
The attached XML doc (uddi-example.xml) directs our client to retrieve the
above wsdl doc and introspects it for WSRP factors/ports (looks for named
business/service; verifies tModel key; uses access point URL; analyses
wsdl).
Our client then does a getServiceDescription(), registers etc as required,
and, by convention, uses the UDDI service name for the public offered
portlet handle to get the portlet description.
What do people think?
regards,
Andre
-----Original Message-----
From: Alan.Kropp@vignette.com [mailto:Alan.Kropp@vignette.com]
Sent: 04 June 2003 23:51
To: wsrp-pfb@lists.oasis-open.org
Subject: [wsrp-pfb] Groups - Publish/Find/Bind teleconference added
Publish/Find/Bind teleconference has been added by Alan Kropp
(Alan.Kropp@vignette.com).
Event description:
USA Toll Free Number: 877-718-0936
USA Toll Number: +1-712-923-6878 (outside US)
PASSCODE: 402957
Agenda:
tbd
Date: Tuesday, 15 July 2003
Time: 09:00am - 10:00am Pacific Time
View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp/wsrp-pfb/event.php?event_id=2259
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.
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-pfb/members/leave_workgroup.php
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-pfb/members/leave_workgroup.php
#### uddi-example.xml has been removed from this note on June 07, 2003 by
Richard Jacob
You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrp-pfb/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]