[wsrp-interfaces] [wsrp][interfaces] Agenda 8/15

[Michael Freedman <Michael.Freedman@oracle.com>]

Let's discuss factoring and protocol extensibility.  The basis for the
discussion is my e-mail from 7/24: "[wsrp][interfaces] Protocol
factoring" as well as the current WSDL as reflected in the v.32 draft.
I have appended my message below for those that don't want to find it in
the archives.

Since the message we introduced 2 new [types of] factors for
consideration:
     a) a factor for initEnvironment()
     b) a factor for the various binding types we want to support
[dime,soap w/ attachments, etc)

My hope is the discussion can be concrete with respect to the WSDL as
presented in v.32 sent yesterday/today.

We need to answer two types of questions:
     a) How many factors should we define [and what is in them]?  In
WSDL speak, how many ports do we define?
     b) For these factors, what types and how do we want to support
extensibility?

Call in numbers are the same:
877.302.8255, 303.928.2609
ID: 8814427

     -Mike-


----------------------------------
Folks,
   A preliminary proposal on how we [WSRP] should approach the protocol
factoring and extensibility issue.  This is designed to be a starting
point for discussions.

Coming out of the F2F we needed to define
extensibility support in our protocol.   There are
four cases we want to consider:
    a) How should the protocol be factored?
    b) How will we support interface changes in future
revisions?
    c) Should we (and how do we) support adding new
parameters to the protocol without causing a
version/interface change?
    d) How can vendors extend the protocol without
affecting the version/revision?

To promote discussion I offer the following proposal:

    a) How should the protocol be factored?  We should
only factor the protocol into multiple interfaces if
we find common usage's that can be expressed in
distinct layers.  The three I have considered are:
sessionless vs. session, render only vs.
render/action, wsia vs wsrp.  Of these the only one I
consider worthwhile factoring for is wsrp/wsia.
Basically, I propose we only support one
interface/factor in this first version of the
standard.  This protocol should only include function
used by wsrp.  I.e. I want a single clean interface
covering the exact function we require and no more.
To date I don't see wsrp specific multiple usage
patterns that would lead me to split the protocol into
multiple factors (though I do see such a need for
wsia).  Yes, a case could be made for either the
sessionless vs session or the render/only vs.
render/action but I think web app folks are already
comfortable with the concepts provided be each
coexisting in a single protocol.

   b) How will we support interface changes in future
revisions?  The way SOAP/WSDL works is that each
explicit protocol change results in a new port type.
I.e. explicit protocol changes are represented in
distinct interfaces.  This leads us to question (c)
... since all explicit changes mean a new interface
...

  c) Should we support adding new parameters to the
protocol without causing an interface change?  The
real question here is do we want to define an API
mechanism that will allow us to "fix" mistakes within
our protocol between versions?  I propose we do not
add such extensibility.  Basically, I find the trouble
of using such an official  mechanism creates too  many
problems -- i.e. maintaining attributes across future
version even after upgrading the API to make the
parameter first class or worse yet leaving the
parameters just in our extension capability and ending
up with first parameters + oops (we forgot)
parameters.  And in any case I think the API generally
has enough parameter extensibility mechanisms already.
 performAction/getMarkup already receive as parameters
some A/V lists relating to the request that should be
a suitable location if needed.  Otherwise, I suggest
all interim fixes be treated as vendor extensions
until it can get into an official revision (though we
could of course get most/all vendors to extend in the
same way).  This leads to:

d) Vendor extensibility.  We want vendors to be able
to express more function/data/description then we will
currently define in the protocol.  This requires:
       a) the producer is able to determine the vendor
       b) the producer is able to receive the vendors
extended information.
The later requires we add a vendorExtensions property
list to most of the calls in our API.  (We may not
need vendor extensions to set/getProperty or
getServiceDescription).

        -Mike-