RE: [wsrp-interfaces] [wsrp][interfaces] Protocol factoring

[Eilon Reshef <eilon.reshef@webcollage.com>]

Title: Message

Mike,

 

Comments below <ER>, in particular a comment regarding approach to extensibility - also relates to an earlier comment by Rich.

 

Eilon

    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. 

<ER>
I agree - however: one should look at this not just from an IA/RP perspective but also (mainly?) from a conceptual perspective: interactive applications versus portlets. The main distinction is below.
</ER>

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

<ER>
The main usage pattern that is RP-specific is the API for managing entities on the Producer side. If you take a generic application (say: the Google search engine, which anybody can put on their public Web site) - it doesn't necessarily support an API for creating/deleting entities and/or of an "edit mode" (which edits the entities). All the administrative functions are done directly on the google.com Web site (where developers using the service log in). I see this as the main set of functions we need to factor.
</ER>

   b) How will we support interface changes in future
revisions?...  
   c) Should we support adding new parameters to the
protocol without causing an interface change?   
 d) Vendor extensibility.  We want vendors to be able 
 

<ER>
There are two distinct viewpoints: one looks at WSIA/WSRP as a _protocol_, the other looks at it as an _API_.

Whereas an API is theoretically equivalent to a protocol, in practice the design criteria are different. When you think about APIs, you typically think about structured data passed as parameters to function calls. When you think about protocols, you typically think of a generic mechanism to transfer data that allows extensibility. Protocols like SMTP and HTTP define an extensible wire-level mechanism, which supports forward-compatibility, and assume that the complexity of the protocol is hidden in protocol-specific libraries (JNDI, JavaMail, etc.). These libraries look like an API to the user but translate to invocations of a more open wire-level protocol.

Where the confusion in WSIA/WSRP lies is that the marketing behind Web services suggests that with WSDL you can create an API, define it WSDL, and the protocol is "automatically" there, a-la RMI or the traditional RPC. The pro of this is that users of the protocol are not required to use a protocol-specific library. The con is that each version or extension of the protocol creates a new API which is not transparently binary-compatible. So, you must specifically design for extensibility, and for versioning you typically resort to using multiple functions (as in the infamous Win32 API - CreateWindow, CreateWindowEx, and eventually we'll get to CreateWindow221 ;-) - which the user has to choose from.

If we believe that people indeed will be using generic proxies to invoke WSIA/WSRP APIs, then I would agree with you that we should think of WSIA/WSRP as a collection of function calls, and leverage the same practices one uses in programming languages as you suggested: fix mistakes or add features using new functions, etc.. If we believe that people (application servers vendors, portal vendors) will be building abstraction layers and libraries on top of WSIA/WSRP anyway, to encapsulate different versions and to add more value, then it's probably a better idea to design for a protocol which is more extensible at the wire (or: binary) level - for example to use a set of name/value pairs at the WSL level - and let a library provide an easier API (like the JSR168 API).

</ER>

         -Mike-