[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia] RE: [wsrp] WSXL paper update
Part of the reason for factoring things into the portTypes as you see them
in the position paper has to do with reuse. We can see both the
WSXLServiceDescription and WSXLLifecycle as having applicability in a
broader sense than just WSIA. If the functionality can push lower in the
web services stack, that would be great. If not, perhaps they can be
generalized (likely just a name change) so that many web services will
publish them as available ports. I think our need is proceeding this work
and should therefore look to provide a good model for both cases.
"Eilon Reshef"
<eilon.reshef@webc To: Rich Thompson/Watson/IBM@IBMUS
ollage.com> cc: <wsrp@lists.oasis-open.org>,
<wsia@lists.oasis-open.org>
04/12/2002 05:19 Subject: RE: [wsrp] WSXL paper update
PM
Thanks.
BTW, I really liked the new write-up.
Another question or two (I hope it's OK...):
The getServiceDocument and hasPortType seem to be very "generic" in the
sense that they could apply to essentially every Web Service (not
necessarily a WSIA one). Pragmatists may even argue that it's somewhat of a
more sensible model than the registry model (UDDI) (especially the
getServiceDocument one, and especially if it can be provided via a simple
HTTP GET request). Do those definitions come from other IBM work (is this
related to IBM's dynamic Web Services invocation stuff?)? Do you know if
such an approach has been actively promoted anywhere else in the Web
Services "world"?
How do you think that WSIA should handle this topic - should we define such
interfaces and state that they should be propagated to the lower parts of
the stack? Should we wait for the lower parts of the stack to support it (I
hope not)?
Any particular thoughts on the lifecycle management along the same lines?
Were you guys aware of any "generic" Web Services notion that captures
stateful Web Services? Should we define those interfaces and basically
explicitly note that we expect the lower part of the stack to adapt or
refine them? Or maybe are we (WSIA) the right part of the stack?
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, April 12, 2002 3:55 PM
To: Eilon Reshef
Cc: wsrp@lists.oasis-open.org; wsia@lists.oasis-open.org
Subject: 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
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, April 12, 2002 12:17 PM
To: wsrp@lists.oasis-open.org
Subject: [wsrp] WSXL paper update
Here is the update that will be appearing soon on
developerWorks:
(See attached file: WSXL_Position_Paper.zip)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC