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

[Rich Thompson <richt2@us.ibm.com>]

I would agree that not enough definition of fault messages (& when they
may/must be generated) has been worked through yet, but hope that we are
getting far enough on the appropriate concepts that time should be spent on
this next level of detail.

1. I agree that the semantics of the return values should be the same for
the creation of persistent and transient entities.

2. The idea of representing a stateless transient entity with a null handle
is hanging around from the timeframe when the service end-point was the
entity and the handle was only related to working around the stateless
character of the current infrastructure. I doubt those semantics still work
in the current model, but haven't thought through it yet.

Your general point: There are proposals going forward at the WSDL level for
stateful services. What I understand of the current proposals would not be
inconsistent with the approach we are currently taking. Once that level of
definition firms up, we definitely will need to revisit how Consumers
interact with stateful WSIA/WSRP entities.



                                                                                                                    
                      "Wilson, Kirk"                                                                                
                      <Kirk.Wilson@ca.c        To:       Rich Thompson/Watson/IBM@IBMUS, wsia@lists.oasis-open.org, 
                      om>                       wsrp@lists.oasis-open.org                                           
                                               cc:                                                                  
                      06/08/2002 11:50         Subject:  RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged      
                      AM                        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)