What follows is adapted from Rex’s email on Tuesday.
These are the criteria by which we should weigh the pros and cons of a proposal for the purposes of this discussion. In order of importance (starting with most important):
Extensibility-Requirements ensuring that the specification can be extended in accordance with the principles of interoperability within the constraint of compliance with XML 1.0.
Performance-Requirements ensuring the least computational overhead on each system component in order to maintain services, complete transactions, and perform the total number of operations required within a model of the interface specification.
Functionality-Requirements ensuring that a high-level for business functionality is met.
Privacy-Requirements ensuring that information private to individuals or organizations can be passed between system components implementing the WSIA (-WSRP) standard.
Simplicity-Requirements ensuring that the WSIA (-WSRP) standard minimizes the limitations on developer capabilities and on the complexity of toolsets.
Modularity-Requirements ensuring that subsets of the specification can be used without creating exception errors or invalidation by XML 1.0 standard-compliant parsers.
Flexibility-Requirements ensuring that the WSIA (-WSRP) standard supports different systems, methodologies, environments, tools and developer capabilities.
(Expressiveness-Requirements ensuring that Web Services that comply within the WSIA (-WSRP) standards can provide a much information about their characteristics and behavior to support robust development methodologies and feature-rich tools.)? I am not at all convinced that this particular requirement translates to criteria for this purpose [Rex’s comment].
There are two diverging views on the model, as it applies to service/portlet lifecycle and interaction with the Consumer. These are:
The discussion should proceed as follows, maybe it makes sense to do a complete walkthrough of points 1-4 of a model, and take comments/questions along the way:
From Jeff Broberg’s recent email on the topic, here are some of the general terms we should be considering. Model-specific terms, if any, should be introduced as well:
· client = an end user
· consumer = an intermediary responsible for the aggregation and control of heterogeneous producer services, responsible for the interaction between the client and the producer services placed on the clients application interface.
· producer = a container of producer services
· producer service = the WSIA/WSRP compliant service ( aka. portlet )
· template = a producer service, with initial settings specified
· entity = an instance of a producer service ( potentially based on a template )
· transient entity = an instance of a producer service
· persistent entity = an instance of a producer service + persistent data
· session scope = is a shared scope between all entities within a producer that a consumer chooses to group together. This can be all the entities of the producer, a subset of entities, and even at the extreme one session per entity.
The main proponents of each view should present diagrams and descriptions for the different models. We agreed this would be Mike F. for the Web App model, and Carsten for the OO model.
Both the OO and Web App models support very similar API’s, the distinction is likely in terms of sequencing and signatures. Diagrams would be helpful here as well.
It’s probably unavoidable that some mention of sessions/persistence will occur in the model discussion. Many of us agree that sessions are orthogonal to the model, so a separate discussion makes sense.
Both Gil and Carsten have agreed to walk the group through their viewpoints regarding sessions:
· Explicit vs. implicit construction, destruction. Also, who creates/manages session keys?
Do we have a definitive outline of what these are? Transient Data ~ Session Data? Supporting scenarios would be helpful.
This area hasn’t received a lot of discussion to date. What are the pros and cons of a separate ‘processAction()’ API? There have been a couple of scenarios floated on the email list, perhaps the proponents could offer these again to start this discussion
This has also been only lightly touched on in some of our discussions to date. There is some sentiment that this is purely a WSRP concept. Is it a particular scope if we look at it in the Web App context? Or is it itself a separate entity, and therefore has its own lifecycle, in the OO sense?