[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