[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument
Kirk - 2. I believe you are right and the null handle is semantically inkonsistent with the rest of the spec. I think we may want to specify that a provider must return a handle in any case. For a stateless service this might be just a constant handle so it does not impose much overhead for the producer. Your remark for stateful services: as Rich pointed out there are initiatives to intoduce statefulness in WSDL. However these will neither be finished in the near future not will this be implemented in the standard SOAP stacks in the next few month. Given our WSRP schedule I think that at the moment we cannot live without defining the statefulness ourselves. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Rich | | | Thompson/Watson/I| | | BM@IBMUS | | | | | | 06/10/2002 01:00 | | | PM | | | Please respond to| | | Rich Thompson | | | | |---------+----------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org | | cc: | | Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| 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) ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC