RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.44]

[Eilon Reshef <eilon.reshef@webcollage.com>]

Title: Message

I agree to both points.

 

To your point #1: The two operations don't even necessarily have the same signature, you can imagine the persistent one being something like createPersistentThingy(persistentThingyHandle, boolean indicating clone/copy), etc.

 

To your point #2: The question of how to describe optional operations (portTypes or pre-defined responses or other means) is there across other operations as well (e.g., setProperties). It also needs to be resolved, although probably under a different group (and I have the same preference as you). However, one way or another - using a separate operation for semantically distinct functions provides a much clearer way to document and understand the "optionality" of the operation.

 

Per one of the questions raised in the draft that you circulated, below is an attempt to describe the Transient Thingies in a way that captures both transient instance and sessions. I wonder if people have comments about the text below:

 

Transient Thingies

 

Transient Thingies allow Producers to associate multiple requests with the same user interaction. At any point within the user interaction, Producers MAY return a Transient Thingy, which the Consumer MUST pass on subsequent request that belong to the same user interaction.

 

For example, the operation

 

getFragment (...)

 

returns, among other things, a Transient Thingy. It is possible for Producers to include in the Transient Thingy a token identifying a Session object created in the underlying application server.

 

Consumers MAY also explicitly request Producers to create a Transient Thingy in the beginning of the user interaction using the operation

 

createTransientThingy (...)

 

This function is provided for convenience and completeness only, and the Producer MAY change the Transient Thingy by returning a different value in subsequent calls.

 

Eilon

 

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Monday, June 03, 2002 11:00 AM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.44]

I see 2 different issues in your comments:

1)  Would it be better (cleaner, more understandable, etc) to have 2
operations (createTransientEntity & createPersistentEntity) rather than a
boolean parameter? I favor the 2 operation model as this is clearer for the
developers of both the Producer and Consumer.

2) If we choose the 2 operation model, would it be better to factor the
createPersistentEntity operation into a separate portType? I think the
fundamental tradeoff here is complexity. The question is whether requiring
a Producer that only supports the creation of such persistent entities
though out-of-band means to implement an operation that always returns null
(or throws a spec defined fault) is worse than requiring Consumers to deal
with this being an optional operation (potentially breaking the goal of
this level of the spec supporting plug-n-play of Producers). In this case,
I would strongly favor requiring the Producer to implement the operation
and having the spec define the expected behaviour.

                                                                                                                    
                      Eilon Reshef                                                                                  
                      <eilon.reshef@webc        To:       wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org      
                      ollage.com>               cc:                                                                 
                                                Subject:  RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec   
                      06/03/2002 01:10           0.44]                                                              
                      AM                                                                                            
                                                                                                                    
                                                                                                                    

Rich,

Sorry for the late response --

I am slightly concerned with the approach of consolidating the "create"
operations into a single concept. Not to beat a dead horse, but your
previous analysis revealed different operations, such as:
- Creating a transient thingy from a persistent one ("instantiation").
  This is a relatively simple concept.
- Creating a persistent thingy from another persistent one.
  This is a much more complex beast, that raises questions such
  as inheritance, cloning, etc. - not sure that there's a single
  operation here.
- Creating a persistent thingy from a transient one.
  This is even a more complex beast: the question of what gets
  persisted etc. is tough (e.g., the user has just typed in a
  stock symbol, does that get persisted?). It probably deserves
  a different interface.
- Creating a transient thingy from another transient one.
  Not sure if that's needed at all.

In addition, I foresee many services, especially in the WSIA world but
possibly even in WSRP in B2B scenarios, where an organization would provide
run-time access to a WSIA service / portlet but would not support creating
new persistent thingies, etc. (which require manual processes that relate
to
approval, billing, etc.).

I believe we would be much better off defining the run-time model
separately
(i.e., creating transient thingies and transferring them throughout the
interaction), and then merge it with the management aspects, which, as
Alejandro suggested, may even be better encapsulated as separate
interfaces,
and even if not - have a completely different spin to them.

Any thoughts?

Eilon

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, May 30, 2002 9:30 AM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: Re: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.44]

Sorry about this duplication, but I just remembered that I had intended to
turn on line numbers so as to make the discussion easier (provided we all
use them to point at the area we are commenting on). Here is the version
with this turned on.

(See attached file: WSIA-WSRP Joint Spec Draft 0.44.doc)

                      Rich

                      Thompson/Watson/I        To:
wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
                      BM@IBMUS                 cc:

                                               Subject:
[wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.44]
                      05/30/2002 08:57

                      AM

As requested on Tuesday, here is a modified version of the Draft Spec that
reflects having orthogonal concepts of "sessions" and "entities" carried
throughout the API. Thomas has inserted a few initial comments from a WSRP
perspective (in particular, potential answers to some of the open questions
in the Note blocks).

(See attached file: WSIA-WSRP Joint Spec Draft 0.44.doc)

#### WSIA-WSRP Joint Spec Draft 0.44.doc has been removed from this note on
May 30 2002 by Rich Thompson

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>