Title: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document
On your comment regarding faults - I second that. The document will be
clearer (although we should remember that this document is very
drafty).
On your questions:
1. We can always throw a fault to indicate a failure of creation, instead
of returning null. This will enable sending more information on the
cause of the failure.
2. I second the confusion. I am not certain what the difference is now
between a transient entity and a session. Actually, looking at the
API, A Consumer/Producer could use either the transientEntity
mechanism or the session mechanism to do the same thing - which is
basically identify a conversation between the two. I am certain I am
missing something. Per-my discussion with Mike, I believe what I
understand is that the transientEntity spans users, and that the session
doesn't, but this isn't explained in the document, and the line you pointed to
definitely doesn't help explaning it. Maybe explaining in the common scenario
why a Consumer would use a transientEntity would best explain
intentions.
Cheers,
Gil
P.S. I think question #2 is the biggest question, and if we finish with
that, we have a workable interface which we can pick on the details
of.
-----Original Message-----
From: Wilson, Kirk
[mailto:]
Sent: Saturday, June 08, 2002 5:51
PM
To: Rich Thompson; ;
Subject: RE: [wsia] [wsrp] [wsrp-wsia
joint interfaces] Merged interfaces document
Rich,
I would like to raise a question or two on the Merged
interfaces document. (By the way, I thought the document was much
clearer than the previous document and answered several questions I had
related to rev 0.44--revised signatures of set/getProperties removed some
questions I had. Section 2.1 was especially helpful to us "general
readers".)
First, a comment: where an operation throws a fault message, I
believe it is now standard to include that exception in the operation
signature.
The principal question concerns p.13 lines 2-3: "An
entityHandle [for a transient entity] can be a null string, indicating that
the requested entity is stateless." Two points:
1. In the case of persistent entities, a null return value
indicates failure of creation. Isn't the dual semantics of null return
values going to cause confusion? Assuming that creating an transient
entity may in fact fail for some reason, how does one distinguish between
failure of creation and having successfully created a stateless transient
entity?
2. What is a stateless transient entity (that doesn't even
have a handle), anyway? I thought (based on the conf. call on Friday) that
entities were like an instantiation of a Producer type which the Consumer
wants to talk to. But what's the purpose of a stateless transient entity
if all that can be done with it is to create it? Evidently, neither the
Consumer nor Producer is going to be able to talk very much to this
"thingy". Is a stateless transient entity equivalent/related to in
anyway to a stateless service? It would seem not (nor would it seem to
be necessary on the current model of stateless services-??). I believe
this question relates to an issue that was brought up at the very end of the
conf. call on Friday: What is the relationship between transience and
statelessness?
I also have a general question (stimulated by section 5.2),
which I hope is not too naive. WSIA compliant services can obviously be
stateful and they can also be stateless. There can also be certainly be
stateless non-WSIA services, and I assume that there could also be stateful
non-WSIA services that are perfectly legitimate. This would seem to
indicate that the specific standards for defining a stateful Web service
should be independent of defining a WSIA service (or a WSRP service in
particular). The WSIA (and WSRP) committees are defining a lot of what
is required for stateful services (more or less out of necessity because there
are no other standards for stateful services out there). My questions
are, Is/are any other committee(s) working on standards for stateful Web
services? (If so, shouldn't we be working with them on these groudwork
issues?) Or, is it expected that the standards we define will be the candidate
for industry acceptance? (Anyone can answer.)
Kirk Wilson
Computer Associates
Manager (Aion)
Tele:
603-823-4023
Fax: 603-823-4025
mailto:
-----Original Message-----
From: Rich
Thompson [mailto:]
Sent: Friday, June 07, 2002 3:38 PM
To:
;
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)
