From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> > > From: Nicola Ken Barozzi <[EMAIL PROTECTED]> > ... > >> RT about a business logic definition system that has > >>these goals: > >> > >>1. has a quick write-test-correct cycle, ie not to be compiled > >>2. is easy to write and understand > >>3. is modular > >>4. will make flowscript a solution to a problem, not a problem itself > > > > > James Strachan wrote: > > Certainly I think Jelly solves all the above goals. > > > > One of the things I wanted Jelly to do is to take existing declarative > > langauges for workflow, rules, business logic, testing, building and so > > forth and turn them into running code easily. So Jelly could, for example, > > implement the flow / workflow language defined in the commons-workflow > > component in Jakarta Commons sandbox, or any other declarative XML language. > > > > Lately I've been looking into using Jelly to implement declarative workflow > > style XML languages. There's a bunch of them out there like BPML, XLang, > > WfMC, WSFL etc. What I'd like is for us to design the most appropriate > > declarative XML language for the problem at hand, then try to use Jelly to > > turn that into a running script. So its on my todo list to investigate using > > Jelly with projects like OSWorkflow to implement the declarative part of > > business logic, make tag libraries for rules engines like drools or for > > state transition modules etc. > > > > I hope some of this has made some sense to some of you ;-). I'd appreciate > > any comments you might have. > > If we want to make a business logic system that is based on tasks, I have > little doubt that we could find something better than Jelly :-)
Bless you ;-) Though also making a business logic system based on other 'languages' could be done with Jelly too. e.g. I'm pondering about making some tags for working with drools' declarative rule language... http://drools.org So Jelly becomes like a glue to tie different languages, features, tasks and mechanisms together. > Not only can one reuse tags, but can use tag libraries that have been > incompatible before to be used together. > > The question is: what *is* business logic? To be business logic or not to be business logic that is the question ;-) > If we make a Jelly business logic system, a Jelly Generator, a Jelly > Transformer and a Jelly flow control system, what would prevent the > developer from getting mixed up and not understand what to code where? Totally agree. How these different things are segregated and connected is a tricky decision. Once its been decided, its easy to enforce with schema validation and so forth. For example, imagine we have a number of modular mini-XML languages to implement the parts, business logic, flow control, FSM or state transition stuff and so forth, we end up with different schemas. We can, if we wish, enforce that they are kept seperate or used together in a controlled manner, enforcing what can or can't be used together etc. In many ways this is nothing to do with Jelly per se - its about designing the XML languages for these things (which may include other languages, XPath, scheme, JavaScript etc) and how these 'languages' interact. Its a tricky problem indeed and its gonna be fun solving it ;-). I really was just mentioning Jelly to see if it could be useful at the implementation stage; it really should not in any way affect the design of how things fit together, since we're probably considering mostly declarative XML for much of this I think. I think its also worth keeping an eye on the workflow projects out there as well as they are trying to tackle similar issues using declarative (usually XML) languages. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
