Re: [jbpm-dev] Features and jBPM 5

Notification ============== By making this a more generic interface, it will be interesting to see what the community does. We have one client who is using a 3rd party tool to notify workers through Text to Speech through a headset driven by jBPM. Pretty cool. Other notifications I can think of off the top of my head: Jabber. Audit Logging ============== I think we could just pass all Audit Logs into a queue. However people want to process from that Topic is their business ;) We are doing this at one client with a large throughput. The benefit is that their secondary system which processes from the Queue can be responsible for the CPU needed to persist and also display [through a custom UI] the audit logs. OOTB, we could offer a listener to the Topic which can persist to the DB. Another which may listen to the topic could be responsible for analytics such as throughput. As the system scales, since these listeners would be standalone, people could move them off the default instance for performance sake. Web Editor =============== I think by providing an advanced, rich Eclipse development environment, we will come out ahead for sure. Sure, it might look nice for presentations; but the minute there is a product bakeoff at a large customer, I imagine that will not stand up. That said, a lot of our customers do ask if Workflows can be imported from Visio -- which the Business users generally are using. Maybe they are targeting it for this purpose. Regardless, developers always will have to get involved. Also, I have never seen this as a deal-breaker when it comes to a company adopting the technology = low on the feature list in my opinion. Brad -----Original Message----- From: Alejandro Guizar [mailto:aguizar@redhat.com] Sent: Friday, May 28, 2010 1:21 PM To: Brad Davis Cc: jbpm-dev(a)lists.jboss.org Subject: Re: [jbpm-dev] Features and jBPM 5 The notification framework is a compelling proposal - the ability to send a message as an email, or alternatively as a fax, SMS, pager or even a social network, through a regular interface is quite valuable. This is the kind of feature that differentiates proprietary and open solutions. As for offloading audit logs to a separate DB, I don't know what would be best, relying on the persistence framework capabilities (e.g. Hibernate Shards) as we have discussed previously, or design with a secondary DB in mind. The former should be more flexible. JBoss Cache: this is already going into the platform. This will serve as an early experience. https://jira.jboss.org/jira/browse/SOA-1406 Cluster-ready timer executions: noted. The EJB timer service solution did not make this requirement, but the other two solutions in the platform did (JCA inflow, Quartz). I share your opinion on the web designer, the Eclipse/desktop alternative is richer, more reliable and overall better, with one exception - the web designer makes for more dramatic presentations. I, for one, was impressed the first time I saw it. Devs will soon realize it is more fluff than stuff (at least in its current state), but if it helps convince the "business analysts", great. Lastly, your words, "I fundamentally believe that all our SOA initiative should start and end in workflow", reminded me of an article I read last year, where the author expresses a similar thought. http://www.itbusinessedge.com/cm/blogs/byron/talking-with-pierre-fricke-o... -Alejandro El jue, 27-05-2010 a las 09:33 -0500, Brad Davis escribió: