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: [wsia] RE: [wsrp] WSXL paper update

Title: Message
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

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                                                                         

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?

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