Comments and questions embedded.
Alejandro
On Tuesday, August 5, 2003, at 04:57 PM, Michael Freedman wrote:
> Last week we discussed the value of defining an in-band event model
> vs. a state changed model. Here are some further thoughts:
> I see the following types of events that could be dealt with:
> a) WSRP events -- these are well known events that WSRP defines
> -- currently these "events" are implicit in our protocol being
> explicitly represented as lifecycle calls [and their
> parameters/returns]: i.e. perform action, render. Examples of such
> events we might consider adding are Begin/EndTransaction. I.e.
> placing a series of calls between portlets within a consistent
> transaction. [Important once we start propagating state changes/data
> across portlets?]
I think we should keep WSRP completely outside of transactions. All
interactions that require transactions has to be handled in a
transactional environment (i.e. EJB container). If not soon well have
to deal with transaction monitors, two phase commit, etc; way out of
the scope of WSRP chapter. Not to mention there is not standard
infrastructure to enable web-services to do such a thing yet.
I would suggest we make clear that any eventing we define through WSRP
is to aid the user experience when interacting with a collection of
portlets through a consumer. But any eventing requiring reliability
should be done in the business logic layer.
> b) Mappable events -- these are events typically defined by the
> producer [though also can be done by the consumer] that the receiving
> portlet is not aware of. Consumers provide a facility to declare
> mappings from one portlets event namespace to anothers. Yossi
> indicated he will provide some examples of this.
> c) Known events -- these are events typically defined by the
> producer [though also can be done by the consumer] that the receiving
> portlet is aware of. No mapping is necessary, consumer merely route
> the events to interested parties. Commonly used within a producer to
> build cooperation within a known set or portlets or by producers
> building building-block portlets that it hopes other producers will
> include in a cooperating set.
Not clear what known events we would have, this seems similar to the
discussion on having predefined roles.
> d) Mappable state changes -- probably the most common form of
> mappable event where the consumer acts as a mediator for data exchange
> between two portlets. I.e. an action results in state changes, a
> portion of which a portlet wishes to publish [e.g. bug report number].
> The consumer understands that the portlet "publishes" this data and
> supports mapping it to similarly published state in another portlet.
> e) Known state changes -- like known events, the consumer doesn't
> provide any mapping -- the sending/receiving portlets understand/agree
> on the data being exchanged via prior knowledge/agreement.
It is not clear to me why we have to consider 'events' and 'state
changes' as two different things. IMO a state change triggers an event.
> I agree with Yossi that Mappable events are a generalization of
> mappable state changes. However, I am not yet convinced that our
> in-band mechansim needs this generalization. For me there is a
> developer and user cost/complexity to introducing MappableEvents here.
> As I don't yet have an example of a pure event -- one that indicates
> no state change/has no associated state -- A mappable event leaves the
> developer in the quandry of whether to define a new event for every
> state change or whether to expose the state changes via a common event
> [e.g. UpdateModel]. The later has the benefit of having a single form
> allowing the consumer to present a simplified user interaction -- map
> from this portlets published data to the other ones. When
> individually named events are involved the user must first choose the
> event they want to map and then map the data between the events. For
> me, this is an unnecessary complication to the user interaction. Until
> I see/understand the use cases for in-band mappable events that aren't
> satisfied by mappable state changes my preference is to limit our
> in-band mechanism just to mappable state changes.
> As for (c) and (e) -- known events/state changes -- should we care and
> if so what is its priority? Mappable events/state changes is a
> superset of the known case -- should we care and if so is it a
> priority to support Consumers who merely want to deal with
> distpaching/managing known events/state changes but not mappable ones?
> -Mike-
>
>
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/wsrp-coord/members/
> leave_workgroup.php
>
