I have a few comments/questions based on the 5/14 joint
draft. I apologize
if these have been covered in
the subgroup, but time constraints have
prevented me
from participating in it too, and there has not been much
public discussion of the content.
1. Instance handles
It seems that these handles are being overloaded to identify
both a service
instance and the state that the
instance is in. Is an instance allowed to
be in
multiple states at once? If not, shouldn't the state be
encapsulated
within the producer (i.e., shouldn't the
handle refer to instance only)?
The description of performAction() says: "This operation may
return a new
instanceHandle (otherwise, null is
returned) to accommodate Web Services
that transition
from statelessness to statefulness." Is statefulness a
dynamic aspect of a service? I have always thought it was static
(i.e., a
service is either stateful or
not).
[ER] There's
quite a lot of discussion around the notion of a transient state versus
persistent state. The last meeting just started the discussion, and your
questions are definitely a large part of it.
2. Properties
It seems that there is a global set of properties for service
instances. Do
we want to allow for
state-specific properties?
The customization group has been discussing inter-property
constraints (such
as those introduced by
XForms). Do we want to include a hook for those here
along with the property schema?
[ER] There
hasn't been much discussion around how to describe the properties. I would
assume that would be under the WSDL sub-committee once the concept is
finalized.
3. Optionality, Capabilities, and portTypes
What is the motivation for introducing new constructs for
WSDL
extensibility/optional operations rather than
dealing with multiple
portTypes per service (as WSXL
seems to promote)?
[ER] This is
mainly a placeholder, which will probably be resolved by the WSDL
sub-committee as well. portTypes is one option, the mere existence of an
operation another. The main motivation for a separate operation (which I am
not a big fan of as well) is that portType is a WSDL concept, not necessarily
a programming language concept, so if an operation doesn't exist, that means
that the Java/.NET proxy code at the Consumer side needs to change, and it's
not straightforward how that is handled by the
Consumer.
4. Heterogeneity
The 5/14 version of the draft spec includes several comments
like "If the
service provides access to a heterogenous
set of objects, this operation may
need to take an
instanceHandle." Wouldn't each object type want to have
it's own binding (e.g., URI)?
This leads to a bigger question of whether we want to consider
separate
set/get operations for each property vs. the
current direction of a generic
property
collection. With the former approach we'd be able to distinguish
heterogenous objects through different portTypes.
[ER] This is
also one of the bigger open questions. I also believe that it's better to
follow the "homogeneous" approach, where a single WSDL document represents a
single portlet, and then use binding to denote different portlets. That can be
implemented very nicely using binding and URL paths (/container/portlet1
versus /container/portlet2) and significantly simplifies the semantics - for
example, different property sets, etc. However, there was only an initial
discussion around the two options.
Cheers,
Tim
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>