Examples cannot be produced at this point because the syntax and the design have not been agreed upon. Unlike other activities email has more complex setup and more moving parts. Let us focus on making the design decisions first. There are two concepts in play. * mail template describes the contents of an email * mail producer takes a template as input and produces a template as output In Brad's current model, the above concepts are treated as two parts of the same thing. The mail activity configuration is read into the fields of the mail producer, and the produce(Execution) method reads those fields to create an email. public interface MailProducer { | Email produce(Execution); | } In my alternate proposal, the template is a separate entity object that represents the configuration. The template is passed to the producer to create an email. The producer thus becomes a control object: it appears to be stateless from the outside. public interface MailProducer { | Email produce(Execution, MailTemplate); | } In my current conception, MailTemplate is a concrete class, as emails have a standard-defined structure. The extension points are narrowed to the producer itself. As soon as we decide on a design, we can jump to work out examples. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225770#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...