isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Reworking of commands and events for 1.13.0-SNAPSHOT
Date Mon, 16 May 2016 06:26:37 GMT
Hi folks,

just to say that over the last few weeks I've been refactoring and
improving the framework's support for commands and events.  This stuff will
be shipped in 1.13.0, which hopefully will release in a couple of weeks.
Right now the code is merged back into master.

I've been updating the docs; the most useful diagram to look at is here [1]

The key idea is that a Command (as per CommandContext service [2]) now
represents the _intention_ to execute an action (or edit a property); this
can then either be executed immediately in the foreground or deferred for
execution in the background.

The new InteractionContext service [3] is responsible for the actual
execution of a Command; the new Interaction object represents the action
actually being executed.  In fact, it encapsulates the concept of one
action executing another (by way of the WrapperFactory); in effect a

The existing PublishingService SPI has been deprecated, replaced by a new
PublisherService SPI [4].  This new SPI accepts Interaction.Execution
objects representing the execution of an action invocation or property
edit.  There can be more than one such implementation registered, and the
framework provides a default implementation of this new service -

The new execution objects are instances of a new "ixn" XML schema, so
convertible to/from XML via JAXB.

In addition:
- the PublisherService also publishes which domain objects are
created/updated/deleted; these are defined by the "chg" XML schema
- both the "ixn" and "chg" schemas capture metrics such as numbers of
objects loaded/dirtied etc, so this provides some useful info for profiling
- the new "cmd" XML schema defines a new format for reified Command object
(to be invoked in the background).  (The intention is for the old memento
format to still be supported, however).
- mixins are now properly handled (also for XxxDomainEvents).

Accompanying this work is an update to the (non-ASF) isis-module-publishmq
add-on [5] (though I haven't yet updated its README).  This now implements
PublisherService rather than PublishingService; the new version also
persists PublishedEvents as well as sending them to an ActiveMQ event bus
(to allow them to be republished in event of failure) and it includes a new
StatusMessage service and client to allow arbitrary messages to be
associated with published events (eg to track whether the event was
correctly processed by all subscribers).

More information in the docs; feedback welcome.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message