Discussion on vpec-t-golden-principles-applicabilty

[Seabird]

I am formulating the "big architecture" picture for my current
employer. The thinking was informed by conversations with Nigel Green,
and a very thrilling lunch with John Schlesinger, together with some
thinking from Jack van Hoof here - http://soa-eda.blogspot.com.

The separation of Policy, Event and Content drives an extremely
flexible thinking model. Because business events must be able to be
made available to other interested parties, and this set of parties is
unknown at the time any specific component is constructed, we need a
semantics for notifying the events.

The content can be pretty big and messy. Also the content associated
with any specific event may have to live beyond the instant of event
notification. There is another, sometimes under designed, requirement
- that where a component desiring to process an event misses it. There
is often the need for for the processor to re-request the content.
Putting those kinds of retry semantics on the event notifier is a poor
separation of concerns. So an approach that caches the content, and
publishes a token ("claim check") for subscribers to use to claim the
content can make the publisher less responsible for managing retries.

As far as Policy is concerned, this is an area that has historically
been very underserved. Some pollicy will be executed as part of the
logic of a software component, but other policy that deals with issues
spanning multiple autonomous operations doesn't have a home. That kind
of policy management should be handled as a "Situational Awareness"
type of component. Perhaps, initially the situational awareness
component does very little except discover interesting things
(confluence of events, missed events,...) and, in the future, could
start taking important decisions. Baby steps needed here, of course.

So the PEC pieces (at least) provide a powerful engine for building
loosely coupled business components which conform to policy, allow
policy to be changed and avoid the trap of managing large persistence
queues with data that perhaps never expire.