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

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-