MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] RE: [wsrp] WSXL paper update
The framework does assume the Producer has a stateful service. The case of
a stateless service can be indicated by returning null from createInstance
() or possibly via setting of some read-only property (may even just be in
the property schema. A Producer that acts in a stateless manner doesn't
have a different interface, it ignores the incoming handle and the values
in the propertyList can be viewed as scoped to the request. It would be
appropriate to throw a fault on calls to setProperties() as well.
It is an interesting question as to whether there is a WSIA Property schema
that a property document must conform too as well as the Producer's schema.
The flavor of discussions has been toward resisting such a restriction with
the understanding that it may become necessary for the more advanced use
cases.
The Adaptation Description Language has been going through a significant
rewrite as the fundamental nature of properties has evolved and this
rewrite is not reflected in this version. The current definition has the
URI indicated as metadata for the service and there has been discussion
about allowing this to be more dynamic both to cover the cases you site and
those where different business partners are provided with different
authorizations to customize the output.
Eilon Reshef
<eilon.reshef@webc To: Rich Thompson/Watson/IBM@IBMUS
ollage.com> cc: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] WSXL paper update
04/12/2002 03:32
PM
Looks very interesting. I had some questions regarding the WSXL document:
Am I correct in my understanding that the framework assumes that the
Producer has a stateful service (portlet) end, that can store and return
the property values? Is this something you have been debating internally?
Did you also consider a hybrid model in which the Producer doesn't have to
store the property list, but rather receives it in the
getOutput/invokeAction calls, but still able to publish a schema for those
properties? Were there any interesting other approaches and pros and cons?
Regarding properties, did you envision that any schema would be legal, or
did you envision a model where the scheme is constrained in some way (e.g.,
name value pairs, ...)?
You chose to have a semi-dynamic model for adaptation points, so they are
not specified as part of the WSDL (makes sense, since they might change
with versions of the implementation), but are the same for all instances
(i.e., not on a per-instance basis). Did you have discussions around cases
where the WSXL service is itself highly customizable or personalized (based
on user / configuration / sequence of pages / properties) so that the page
layout changes significantly, and how to address that within the framework?
Eilon