RE: [wsrp] on non-blocking perform interaction

[Andre Kramer <andre.kramer@eu.citrix.com>]

Removing an operation would only break a client if the client (web service
consumer) actually attempted a missing request (the web service producer /
stack will throw a "missing operation" SOAP fault). In our case, meta data
or the producer (for action ULRs) controls which operations get invoked.

Our factors add clarity, but are not required for loose Web service
contracts, even if proxies/stubs are pre-compiled.

regards,
Andre

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 28 March 2003 09:46
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] on non-blocking perform interaction



The removal or adding of operations is indeed a nice future but has one
major drawback:
it would break precompiled proxies if you remove operation from a portType.
I think that's why we introduced the different portTypes (interfaces) and
split the functionality into groups: to indicate what functionality is
supported by the producer.
If a producer wants to add/remove operations from portTypes it should then
define its own portType/Binding.
Then it will loose its interoperability as this would be a standard conform
portType/Binding.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


|---------+---------------------------->
|         |           Andre Kramer     |
|         |           <andre.kramer@eu.|
|         |           citrix.com>      |
|         |                            |
|         |           03/28/2003 10:17 |
|         |           AM               |
|---------+---------------------------->
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
  |
|
  |       To:       "'wsrp@lists.oasis-open.org'"
<wsrp@lists.oasis-open.org>
|
  |       cc:
|
  |       Subject:  RE: [wsrp] on non-blocking perform interaction
|
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|




In fact, you don't even need a no-op, as one can build a server from a wsdl
that does not have a perform(NonBlocking)Interaction. A nice feature of
SOAP
is that things will still work if one removes or even adds methods. And I
would say the contract between a producer and a portlet is a private one
...

Not wishing to re-visit the discussion, but, having relaxed the strict
mapping of client request / aggregation to performBlockingAction, and with
perform(NonBlocking)Action's future still uncertain (if we remove it then
perform(Blocking)Action would be more likely to be used multiply and with
returned mode changes etc ignored), I would like to make sure we
re-structure performBlockingInteraction's return values (so that we can
clone-on-write and initiate a portlet session, while returning a
redirectURL). Rich, could you promote my question on this to a change
request, TBD post #142?

Indeed, if we remove performInteraction, I believe we should also include a
boolean in InteractionParameters to help indicate if a re-direct is allowed
by the consumer: boolean consumerUncommitted, default false (but maybe I'm
jumping the [percussion-only] gun).

regards,
Andre

-----Original Message-----
From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
Sent: 28 March 2003 01:44
To: 'wsrp@lists.oasis-open.org'
Subject: [wsrp] on non-blocking perform interaction


A short follow up on today's discussion on this topic,

Mike is right on that a producer does not have to do anything in this
method, a NOP is enough. However the producer must stop portlets from
creating non-blocking action URLs. And on the consumer side, the
consumer must handle non-blocking perform interaction calls as it does
not know if producers/portlets will create non-blocking action URLs.

Alejandro