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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: 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>,                          
                      04/12/2002 05:19          Subject:  RE: [wsrp] WSXL paper update                          


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
      () 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
      have a different interface, it ignores the incoming handle and the
      in the propertyList can be viewed as scoped to the request. It would
      appropriate to throw a fault on calls to setProperties() as well.

      It is an interesting question as to whether there is a WSIA Property
      that a property document must conform too as well as the Producer's
      The flavor of discussions has been toward resisting such a
      restriction with
      the understanding that it may become necessary for the more advanced

      The Adaptation Description Language has been going through a
      rewrite as the fundamental nature of properties has evolved and this
      rewrite is not reflected in this version. The current definition has
      URI indicated as metadata for the service and there has been
      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
                            ollage.com>               cc:
                                                      Subject:  RE: [wsrp]
      WSXL paper update
                            04/12/2002 03:32


      Looks very interesting. I had some questions regarding the WSXL

      Am I correct in my understanding that the framework assumes that the
      Producer has a stateful service (portlet) end, that can store and
      the property values? Is this something you have been debating
      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
      properties? Were there any interesting other approaches and pros and

      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
      name value pairs, ...)?

      You chose to have a semi-dynamic model for adaptation points, so they
      not specified as part of the WSDL (makes sense, since they might
      with versions of the implementation), but are the same for all
      (i.e., not on a per-instance basis). Did you have discussions around
      where the WSXL service is itself highly customizable or personalized
      on user / configuration / sequence of pages / properties) so that the
      layout changes significantly, and how to address that within the

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

            (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