MHonArc v2.5.2 -->
wsia message
[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