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-

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