OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

Title: Message
Although I am generally not part of that sub-committee, I happened to participate in the latest call, so here's a few perspectives (inline).
-----Original Message-----
From: Timothy N. Jones [mailto:tim@crossweave.com]
Sent: Wednesday, May 15, 2002 8:07 PM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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).  

[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.


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