RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument

[Gil Tayar <Gil.Tayar@webcollage.com>]

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:Kirk.Wilson@ca.com]
Sent: Saturday, June 08, 2002 5:51 PM
To: Rich Thompson; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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:kirk.wilson@ca.com

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, June 07, 2002 3:38 PM
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)