Geoffrey: This is a pretty interesting catch. It is true that the architectural flexibility of a general purpose rule engine could end up being overkill. And interestingly I don't think it is NECESSARY at the core of the Synapse engine. It (rule evaluation and execution) is an essential component of some aspects of mediation - routing as an example - but I believe it should be externalized.
One way to make the decision is to agree upon use cases, expression language for policy requirements and then translate this into rule bases, late decision execution model as well as an earlier decision making model that I would personally advocate especially given performance considerations. Mukund Balasubramanian -----Original Message----- From: Geoffrey Fox <[EMAIL PROTECTED]> To: [email protected] <[email protected]> Sent: Fri Oct 21 07:27:04 2005 Subject: Re: Is Synapse workflow? Firewall penetration can certainly be scripted and at its most sophisticated involves a complex script. It doesn't orchestrate services as just varying port and protocol and negotiating with proxy servers, so I would call it a "script".rather than "workflow". However as I mentioned extended scripting languages with "services" "ports" "streams" as primitives support workflow just fine. "pipes" in UNIX are a good simple example of scripted workflow. I think Synapse is meant to support rather general filtering/mediation and in this generality, I am noting you compete with the plethora of workflow systems. Davanum Srinivas wrote: Do you consider firewall (ipfw?) rules as workflow? (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html) -- dims On 10/20/05, Geoffrey Fox <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: I don't understand how Synapse is different from workflow I understand that it has a rule-based mediation model but isn't that just one of many choices for the programming model (I think it is fair to consider workflow as programming services) Maybe the Synapse model is a winner but it has a lot of competition from many fronts (not all these are at same levels as we have for workflow: runtime engines, execution models, languages and user programming models) BPEL and other XML business process/transaction models Endless scripting models from Python to Shell script based approaches Graphical models as famous from myGrid pictures Dataflow like Triana and Kepler LINDA and all the old distributed programming from the past See recent collections/reviews at: http://www.extreme.indiana.edu/groc/ggf10-ww/ http://www.cc-pe.net/iuhome/workflow2004index.html http://grids.ucs.indiana.edu/ptliupages/publications/Workflow-overview.pdf http://www.gridbus.org/reports/GridWorkflowTaxonomy.pdf If you study all these papers, you will note they all report success! So I wonder what are new key features/requirements that Synapse will have to differentiate it from the pack? PS I would make same comment on almost any workflow Apache project or in fact any research project in field. -- : : Geoffrey Fox [EMAIL PROTECTED] FAX 8128567972 http://www.infomall.org : Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977 -- Davanum Srinivas : http://wso2.com/blogs/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- : : Geoffrey Fox [EMAIL PROTECTED] FAX 8128567972 http://www.infomall.org : Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
