Description
I recently implemented something very similar to this (I wish I had learned of this project a couple of months sooner).
In my version the "Work" interface was subclassed into several types: OneToOne, OneToMany, ManyToOne and ManyToMany. Each one had a slightly different signature. OneToOne was like your Work interface, takes in one WorkContext and produces one WorkContext, but OneToMany took in one WorkContext and produces a Stream of WorkContexts. Likewise, the ManyToOne takes in a Stream and produces a single WorkContext and ManyToMany takes in a Stream and produces a Stream of WorkContexts.
The reason I did it this way was to create reusable Work implementations that I could mix together in a variety of ways. For example, one Work implementation called "WriteToFolderWork" could take in one WorkContext that contains an XML and write it to a folder. This is a OneToOne Work implementation. Another Work implementation (say, called "SplitXmlWork") could split a single XML into several pieces. This would be a OneToMany Work implementation. The workflow framework too care of converting a "Many" output from one step to a repeating set of "One" inputs to another step and vice-versa.
Have you thought about something similar for easy-flows and rejected it? What are your thoughts?
I am contemplating the idea of forking your project, enhancing it and then replacing my implementation with a modified version of yours. I'd like to gauge your interest in these changes to see if I could submit a PR after I am done. Also, you may have another approach in mind that I haven't considered which is already handled by the current codebase.
Any feedback would be appreciated.