[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument
Eilon - my comments are embedded in [CL] tags. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+-----------------------------> | | "Eilon Reshef" | | | <eilon.reshef@webc| | | ollage.com> | | | | | | 06/13/2002 12:33 | | | AM | | | Please respond to | | | "Eilon Reshef" | | | | |---------+-----------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Carsten Leue/Germany/IBM@IBMDE | | cc: Thomas Klein6/Germany/IBM@IBMDE, <wsia@lists.oasis-open.org>, <wsrp@lists.oasis-open.org> | | Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| Carsten, I don't have an extremely strong feeling as to the question of whether to leverage infrastructure (HTTP/1.1) for multiplexing or put it as part of the protocol (it will work both ways). It's clearly an engineering tradeoff (has advantages/disadvantages, but I feel that the cost/benefit is of putting it explicitly in the protocol is marginal. [CL] I disagree. Keep in mind that HTTP is only one possible transport layer. You would have to reproduce the whole procedure for each transport. In the explicit case this would not be necessary. [CL] The advantage to it is providing out-of-the-box support for request multiplexing. The main disadvantages I see are: 1. Simplicity - naturally a protocol based on arrays is harder to explain/use (at both ends). [CL] This is certainly true. We will have to decide between simplicity and efficiency. Both is important. [CL] 2. Exception handling - with arrays, you would have to re-invent some of the built-in SOAP exception mechanism. You wouldn't necessarily want the entire call to fail even if just one portlet fails, and you'd need to return multiple result types, so you'd also have to create a custom data structure to use instead of SOAP exceptions. [CL] I agree to this as well. The producer would have to return a null output to indicate an error. [CL] 3. Compatibility with SOAP network infrastructure - this is a concern I have even in having a single service serving multiple portlets, but is becoming even more so with multiplexing as part of the protocol. In general, we should expect software programs such as SOAP gateways, SOAP proxies, SOAP firewalls, etc. to gradually evolve. With multiple calls multiplexed onto a single call, such devices would not be able to add value. So, one may argue that a behavior like the one you described (distributing calls to different places) should be supplied e.g. by a SOAP gateway based on configuration rules so that if a call comes in with a specific parameter, it would be directed one way, versus another. Declaring everything as a single SOAP call essentially prevents us from pushing functionality down the technology stack. [CL] Can you elaborate a bit on the use of SOAP gateways? I was not aware of this. Furthermore: will it really be efficient to route requests for markups that potentially share the same session to different servers via such a gateway? Wouln't it be very inefficient to marshal the session state accross these servers? [CL] As for performance perspective HTTP/1.1 does support multiplexing of requests, namely the ability to send one request while the first one is being processes, so this should still result in the same number of roundtrips. Obviously, there's the addition of the HTTP header in the payload, but this is negligible. For example, by using a non-SOAP protocol we will save much more in terms of overhead. (We don't get many benefits from the SOAP envelope anyway, especially if our granularity is such that a single service supports multiple portlets and even more so if we can't use exceptions). The reason why we use SOAP is to be "good citizens", which also applies to using more granular calls that can be managed using services in the lower part of the technology stack. [CL] See my comment above on the transport issue. We might deal with multiple transport layer that do not support such multiplexing. In addition, client and server will have to negotiate how to exactly perform the multiplexing. Is this standardized? Is it included in today's SOAP stacks. If you don't mind I would love to get some education on this on the F2F. In addition it seems as if your scenario implies async method calls (send one request while the first on is being processed). Do I get this right? I had the impression that SOAP calls were synchroneous. [CL] Such an approach would allow the Producer to handle multiple requests concurrently, with the only limitation being that the Producer would not have full visibility into all the request so it would have to use an online algorithm for distributing the requests. However, that last issue is, I believe, balanced by another consideration that was brought up earlier. If you use a single request with an array of arguments, if the Consumer uses one of the common frameworks, it would have to wait for the full result before dumping it to the output stream. If the Consumer can issue multiple calls, it can manage this in more flexible ways. [CL] The consumer could still choose to send single requests. Using arrays is just an option, so this approach would not prevent your scenario from happening but would leverage different kinds of optimization. [CL] As for the overhead in marshaling and de-marshaling requests, this is indeed a consideration. However, I believe people can optimize this overhead out, either with pooling or by creating services on top of thinner libraries. My approach, in that respect, is that it would inappropriate for us to optimize - at the application level - issues that result from the temporary immaturity of specific SOAP frameworks, which especially in our case can be overcome since we only have a single interface (Proxy code). (Unlike issues inherent to the protocol, which we should optimize the hell out of). [CL] I clearly see your point. My answer is that I prefer a design optimization rather than an optimization of the implementation. At leat design optimizations remain effective accross different implementations. [CL] Please also note that an approach that's based on multiplexing at the network layer also lends itself well to optimization of heterogeneous calls, such as performAction and getFragment or even setProperties and not just a collection of related calls. [CL] that's true, but especially on getFragments and performAction I do not see how such an optimization might make sense. The consumer would have to wait anyway until a performAction request has been satisfied before launching the next getFragments request (because performAction might invalidate state). [CL] Despite my long e-mail (my apologies ;-), I view this as a possible tactical optimization, only that I feel that the tradeoff here works better for simplicity. Part of it may also be the balance between optimizing for Producers which are sophisticated multi-service portals versus simpler home-grown Producers. [CL] My feeling is that the array approach is especially helpful for home-growners, iterating an array is not that complicated [CL] Cheers, Eilon -----Original Message----- From: Carsten Leue [mailto:cleue@de.ibm.com] Sent: Wednesday, June 12, 2002 6:56 AM To: Eilon Reshef Cc: 'Thomas Klein6'; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document Eilon- thanx for providing more details on your approach. However I still prefer the explicit option for performance optimization for the following reasons: - what I understood from your comment is that you want to make use of the HTTP/1.1 feature to leave an established connection open during multiple request. This would reduce the overhead of opening/closing a connection. However it would not reduce the number of total roundtrips as you would still call the method (e.g. getFragments) multiple times. Furthermore you would still have the overhad of instantiating all the intermediate objects your SOAP implementation used to marshal/unmarshal the SOAP request. By passing arrays as parameters both disadvantages disappear. - from my point of view one of the major advantages of using arrays is that the producer can exploit parallelity when satisfying the requests. In your approach this would not be possible as all requests come in sequentially. - I don't agree that a consumer would be more difficult to implement. If its does not support arrays, its just sends out one element. The producer however would have to be able to deal with arrays. But this is trivial as in the simplest case it would just iterate over the elements of the array in a single loop. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+-----------------------------> | | "Eilon Reshef" | | | <eilon.reshef@webc| | | ollage.com> | | | | | | 06/11/2002 07:37 | | | PM | | | Please respond to | | | "Eilon Reshef" | | | | |---------+-----------------------------> > ---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Carsten Leue/Germany/IBM@IBMDE | | cc: <wsia@lists.oasis-open.org>, <wsrp@lists.oasis-open.org>, Thomas Klein6/Germany/IBM@IBMDE | | Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document | | | | | > ---------------------------------------------------------------------------------------------------------------------------------------------| Carsten, I apologize for the confusion. What I meant to say is that SOAP relies on an underlying stack of protocols. In our case, we can safely assume as much as optimization is concerned that the underlying protocol is HTTP (unless anybody has in mind SMTP portlets). In this case, one can use HTTP/1.1 as a transport mechanism for the SOAP requests. This does not require new opening new connections for every request. However, as you noted, this is not part of the common frameworks for SOAP. However, let's not forget that we must support the standard stack (SOAP/HTTP) but leveraging the existing frameworks is extremely important, but if there is a certain optimization that people can do outside those frameworks this is not something that should discouraged. More specifically, on the client (Consumer) side, I don't see this as a concern since we only need to have one proxy and we can manually construct it if necessary for the extra performance (it wouldn't be the first time that performance requires extra work, and I prefer that to a solution that the interface inherently implies extra work). On the server (Producer) side, I am more concerned: I am completely unaware of what the coupling between the Web server and the underlying frameworks is. If someone has an idea whether HTTP/1.1 can be forced to be used there, that would be beneficial. I disagree with you that is "tweaking" the transport: this may be tweaking the existing SOAP frameworks, but hey: they are just piece of auxiliary code, and I would rather look at is as moving beyond the infancy of the those frameworks. Eilon -----Original Message----- From: Carsten Leue [mailto:CLEUE@de.ibm.com] Sent: Tuesday, June 11, 2002 2:47 AM To: Eilon Reshef Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org; Thomas Klein6 Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document Eilon - i was not aware of this SOAP functionality. Can you detail a bit on this topic? How would I setup a batch call programatically? Is this batch processing part of the standard stacks (SOAP4J, AXIS, .NET)? Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+-----------------------------> | | Eilon Reshef | | | <eilon.reshef@webc| | | ollage.com> | | | | | | 06/10/2002 08:33 | | | PM | | | Please respond to | | | Eilon Reshef | | | | |---------+-----------------------------> > ---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org | | cc: | | Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document | | | | | > ---------------------------------------------------------------------------------------------------------------------------------------------| Rich, isn't call batching available today at part of the relevant SOAP stack via HTTP/1.1, unless you use a code library that doesn't support it? -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Monday, June 10, 2002 1:21 PM To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document We have to work through the array idea as it as big performance implications and I don't see any indications that call batching at the SOAP stack level will be available in a relatively short timeframe. My understanding from the WSRP interfaces discussions is that a template is a portal concept. It is effectively a configured portlet that is used from a toolbox to design pages. The concept of an instance is a configured portlet that is linked to the layout of a portal page. This configuration MAY have come from cloning a template. From the perspective of what the Producer needs to support, both of these are particular configurations of an entity the service exposes with the Consumer choosing to use them in different ways. I have been searching for reasons why there would be a difference for the entity, but haven't found one yet. If I understand your question about transient entities correctly, you see why sessions should be separated from entities so that they can be shared but question whether services will ever expose entities that aren't persistent. I can certainly imagine entities with no persistence (the service that hosts them likely has some persistence of who may use them along with some use log for audit & billing purposes). A simple entity that puts a UI on a stock ticker feed may be a good example. It chooses to delegate all the billing issues to the service where it is deployed and all the configuration persistence to its Consumers. In this case, createPersistentEntities() would always fail as only transient entities are supported. Andre Kramer <andre.kramer@eu. To: Rich Thompson/Watson/IBM@IBMUS, wsia@lists.oasis-open.org, citrix.com> wsrp@lists.oasis-open.org cc: 06/10/2002 10:37 Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged AM interfaces document Supporting a batch operation mode through arrays does not seem very clean. In the "getFragment" case (getFragments?), the portal will most likely then have to wait until the whole array is returned (i.e. all remote portlets have rendered) before it can display the resulting mark-up. How many consumer to producer parallel calls do we expect typically? I would rather leave call batching up to the (future) SOAP stack. Always using "Entity" as the thing to create remotely seem to loose the "class" versus "object" semantics that the WSRP "template" and "instance" operation names used to imply. Do we now see no no difference between remote data storage - 'templates' (possibly with inheritance) and computational entities - 'instances', that WSRP seems to naturally call for? Or are these the persistent v.s. transient entities of the document (for me, portlet instances persist too)? In trying to follow the discussion, I'm confused as to why we need both sessions and transient entities, both being under the control of the consumer. I do see a need for common sessions (same user/group or consumer portal) but do not see the need for other transient entities, expecting a consumer to have to pay for all entities, in some way, in the real world. I know the next call will discuss these but could someone give a brief rational before then? Thanks, Andre Andre Kramer, Citrix Systems, Inc. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: 07 June 2002 20:38 To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document Here is a draft of the merged interfaces document that Carsten and I have been working on this week. The largest conceptual change from the previous 0.44 Joint Spec Draft is the appearance of arrays in most of the operations. This allows Consumers on the scale of portals to efficiently interact with Producer services. (See attached file: WSIA - WSRP Interface Specification.doc) ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC