OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[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