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:]
Sent: Monday, June 03, 2002 11:00
AM
To: ;
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: ,
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:]
Sent: Thursday, May 30, 2002 9:30 AM
To:
;
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:
,
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>
