a) Application: Some process being executed that hits a task activity
b) Task Mgr: The current jBPM4 base model for managing tasks. It includes assignments, variables, etc.
c) Notification Mgr: Decouples the notification features. I.e. email, ical,etc. The idea is borrowed from the latest code contribution.
How and if the task management does notifications will be pluggable. We will probably provide a smtp notification mechanism as the default.
d) Form Mgr: Interfacing the outside world. Formost use would be HTML forms of some kind, but can be a WS interface as well. The Form Mgr relies on the variables and resources associated with a process.
5 comments:
Heiko, this looks good!
I also suppose the HTTP facade can easily be interchanged with any other kind of Facade (ie normal Java interface for example)?
The same could be said for the interconnection between application and Task Mgr: is there a facade (perhaps transparant) in between which allows easy interchange of interfaces.
HI Joram,
You are right. The HTTP facade is an additional component that stands on it's own. It's actually an addition to the Form Mgr that's optional.
The Form Mgr itself is pluggable and repesents a particular technology/implementation: Freemarker, Velocity, XForms.
Regarding the connetion between the application and the Task Mgr: Thiscan either be jBPM itself, dispatching task creation when task activities (jpdl) are executed or programmatic invocation of the TaskService.
Heiko, this looks interesting especially having just released my ical wrapper (taskcal) for jBPM.
The notification manager is a more elegant approach than using an action handler. I'm wondering though how this model will handle notification replies - via the protocol facade?
@Adrian
We would basically need to work our two interfaces:
a) jbpm core -> NotificationMgr
b) Notification Mgr -> iCal
IMO a) should be independent of the actual notifications that are triggered, iCal is just on example. Maybe the current eventing API already serves that purpose. If it get's protocol specific then it should be treated as a NotificationMgr implementation detail and transparent to the core engine.
Maybe we start with migrating your work to jBPM4 as a proof of concept?
Heiko,
Not sure when I'll get to this, but would definitely like to get an API definition.
One aspect that will need to be looked at is management of assignment states. iCalendar defines a number of states associated with 'inviting' an actor to participate in a task. Where would you see this being managed?
Post a Comment