Although I agree that there is a general aspect of workflow, we are going to address this with standard approaches (BPEL, E4X, Spring assemblies, etc).
I still think that there is a key point here, that maybe I didn't make clear first time.
There is a difference between directly building a workflow and deploying it as an endpoint, and attaching mediation to an existing service interaction. It is exactly the same difference between aspects and ordinary Java. In AOP, you use the same mechanisms to write code, but there is a more flexible attachment (pointcut) process. In particular, both AOP and Synapse provide for a transparent mediation model which allows you to attach mediation code to existing interactions without changing either of those interactions. In AOP this is by plugging in at the JVM level to intercept, in Synapse we will allow plugging in at the network level.
Whether or not we use XPath as the fundamental attachment model, the significant difference between Synapse and a generic workflow engine is that Synapse provides the flexible attachment model and then uses whatever workflow engines are available to it to execute mediation logic.
So my view is that the Synapse engine we are architecting is orthogonal to the workflow aspect. Now perhaps the discussion has focussed too much on the compositional model of that engine. Because, to continue the analogy, you could write whole applications as aspects in AspectJ. Of course that would be stupid - you are meant to use the aspects to attach cross-cutting concerns and then use Plain Old Java to write the actual business logic.
In our current model, the xpath/mediator attachment is meant to be nothing but the way of attaching cross-cutting concerns, and then the main composition is meant to be done in Java/BPEL/script.
Paul
On 10/23/05, Geoffrey Fox <[EMAIL PROTECTED]> wrote:
I guess I have something like the opposite problem.
I think you may end up needing all the features of workflow
(and ESB's ) and somehow end-up with a non standard version
of this with various features/restrictions that reflect history
Also there are many applications of Web Services/Grids that
use filters to transform messages in various ways -- any Sensor
application needs to do this. This looks like mediation to me.
You use xpath which is perhaps distinctive but we
steered clear of this as it is pretty slow compared to other
selection strategies. I am struggling to see
where Synapse will be in future and how it compares with
other related projects.
Mukund Balasubramanian wrote:
>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]
