[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp] WSRP Publish, Find & Bind Presentation for F2F
Eilon,
see my comments below
Mit freundlichen Gruessen / best regards,
Richard Cieply
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:cieply@de.ibm.com
|---------+----------------------------->
| | "Eilon Reshef" |
| | <eilon.reshef@webc|
| | ollage.com> |
| | |
| | 09/04/2002 07:47 |
| | PM |
| | |
|---------+----------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Richard Cieply/Germany/IBM@IBMDE |
| cc: Lothar Merk/Germany/IBM@IBMDE, Thomas Schaeck/Germany/IBM@IBMDE, <wsrp@lists.oasis-open.org> |
| Subject: RE: [wsrp] WSRP Publish, Find & Bind Presentation for F2F |
| |
| |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Thanks - two comments below.
-----Original Message-----
From: Richard Cieply [mailto:CIEPLY@de.ibm.com]
Sent: Wednesday, September 04, 2002 12:39 PM
To: Eilon Reshef
Cc: 'Lothar Merk'; 'Thomas Schaeck'; wsrp@lists.oasis-open.org
Subject: RE: [wsrp] WSRP Publish, Find & Bind Presentation for F2F
Eilon,
yes, if a producer offers multiple entities like a whether portlet
and a
stock ticker portlet both would be published as services to UDDI.
<ER> Isn't this an overlap with the explicit "entity" parameter
that's passed on every call? </ER>
<RC> no, I don't think so. The consumer is talking to a entity "via"
the producer, indicating which entity he is calling via the entity
handle.
The idea behind this is to publish and find "real world services" to
UDDI like whether portlets, stock portlets. However the access point
to these is
still the producer (and access them via the handle).
I think user's and administrators are more interested in finding
services related to distinct topics rather then finding 'abstract'
WSRP producers.
The UDDI approach is an alternative to self description.
Otherwise one could publish the producer and then the consumer needed
to use the self description to obtain entities the producer provides.
Imagine an administrator who is interested in a stock service
supporting WSRP. He had to find first producer's and then crawl the
producers
to check whether they support a stock service or not.
The UDDI case would be to find a stock service implementing the WSRP
protocol, i.e. finding a producer that indeed provides such a stock
service entity. </RC>
The common access point is meant as the <wsdlsoap:address location
="URL">
element within a <port> element.
It is required to be common for session handling between differen
factors.
<ER> Isn't this more of an implementation issue than a generic issue?
The explicit session parameter in the interface is obviously
orthogonal to the port question. The cookie/session hack seems to be
implementation-specific (there's nothing in WSDL that refers to HTTP
cookies, naturally). You mentioned it's part of the discussions, but
it seems somewhat restrictive to me to force a single URL for all
calls, if I got that part right. This will only get worse as the
interface evolve and producers will have to support multiple
interfaces. </ER>
<RC> Yes, it is an implementation issue. The idea of using HTTP
sessions (between consumer and producer) for each group id came up
from an use case in clustered environments.
I think all you state is correct. It is restrictive and there are
issues which even prevent us from doing it this way.
One point is that the WSDL seems to disallow inter-port
communication. Rich is currently checking this.
Onother point is that this does not solve the problem when
communication alternates between HTTP and HTTPS. Then we would have
-per definition- different access points, which breaks the sollution.
We said that it was required to have a common access point because
AXIS (the JAX-RPC reference implementation) stores cookies per access
point.
So I would agree to you and think we should not consider this
sollution.
This point should and I'm sure it will be discussed at the F2F. </RC>
Assume a producer that exposes two factors like the WSRP 'base'
factor and
the 'properties' factor.
Each factor would be represented as <portType> in WSDL sense.
You then need two bindings - one for each portType (for example
soap-rpc
for both).
Your service would then have two <port> elements, each port
referencing one
of the bindings.
To allow a session state to be maintained between calls to both
factors you
need one common access point.
Another scenario would be if a service exposed one interface, say the
WSRP
'base' interface and then
allow two bindings to it like soap-rpc or soap-rpc encapsulated in
DIME.
This would also result in two ports.
This topic is currently under discussion in the calls.
We have to figure out if we are allowed (WSDL spec for example) to
share
information between ports and if this is implementable.
It may hit the factoring discussion.
Mit freundlichen Gruessen / best regards,
Richard Cieply
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:cieply@de.ibm.com
|---------+----------------------------->
| | Eilon Reshef |
| | <eilon.reshef@webc|
| | ollage.com> |
| | |
| | 09/04/2002 12:30 |
| | AM |
| | |
|---------+----------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Thomas Schaeck/Germany/IBM@IBMDE, "'WSRP
(E-mail)'" <wsrp@lists.oasis-open.org>
|
| cc: Lothar Merk/Germany/IBM@IBMDE
|
| Subject: RE: [wsrp] WSRP Publish, Find & Bind Presentation
for F2F
|
|
|
|
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Thomas,
Nice summary - would you be able to clarify the following two
statements:
"Each producer offered entity is represented as a service in the WSDL
sense"
Does this relate to the WSRP notion of persistent entities? Does this
mean
that if a producer has a weather portlet and a stock ticker portlet,
these
will be two services in the WSDL sense?
There will only be one common access point for all ports (required
for
consistent session handling)
What does access point mean? Does this mean that the producer cannot,
for
example, use one URL (or servlet) for certain operations and another
URL
for other operations? If that is the case, why is that so and how is
that
being enforced?
Regards,
Eilon
-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Tuesday, September 03, 2002 6:07 PM
To: WSRP (E-mail)
Cc: Lothar Merk
Subject: [wsrp] WSRP Publish, Find & Bind Presentation for F2F
Dear WSRP Members,
please find attached the presentation Richard and Carsten
provided
for the
F2F Meeting.
(See attached file: F2f-PFB-V0.2.ppt)
For time constraints, we need to keep the discussion on this
topic at
the
F2F relatively brief, so I'd like to ask everybody to review
the
presentation and what's written about Publish, Find, Bind in
the WSRP
0.5
spec draft and raise any questions on the Publish, Find, Bind
mailing
list
in advance of the F2F meeting.
Also, please let me know of any issues that you think require
discussion at
the F2F in advance so that I can plan and adjust the slots
appropriately. I
want to collect all discussion points by Thursday this week.
Best regards,
Thomas
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC