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] 5/14 call minutes
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).
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?
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)?
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.
Cheers,
Tim
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC