this is very interesting thread!
i have a question on a related note: will Synapse support clustering and
if yes then how that is going to work? that is of course not for M1 but
for Mn ...
i think it is a fundamental concern for how rules are executed and where
and how state of execution is maintained.
the way i see it Synapse should work on set of distributed persistent
and transactional message queues (so no messages are "lost" when Synapse
dies because machine on which it is running is restarted etc.) - that
would work if course best with something like WS-RM/WS-R/WS-RX so
message queues support reliable delivery.
then there should be some kind of state machine that executes any kind
of (pluggable?) state transition logic (as rules, scripts, BPEL
workflows, ...) but in transactional way as well: starting a
(distributed?) transaction, taking message from incoming queue, doing
state transitions, putting message(s) into outgoing queue(s), committing
transaction - this clearly implies need for a tightly integrated
transactional storage (RDBMs, XML DB, ...) - keeping state in memory and
serializing it to disk may not be enough (i think Sandesha2 already has
this problem with AXIS2 ...)
in a way then Synapse can scale from a simple firewall-like rule
engine/dispatcher (one machine, very simple state machine) to clustered,
transactional, scalable, high performance workflow engine and ultimately
network of Synapse nodes (each node may be clustered or not - does not
matter from WS point of view) and that may be this mystical Unicorn
beast everybody is hunting, ahem, ESB? :-)
best,
alek
Paul Fremantle wrote:
Geoffrey
One view is that *EVERYTHING* is a subset of workflow.
In this case I think the real issues are - dynamism, flexibility and
performance. I actually think what we are trying to do here is much
more like aspects than workflow. The actual execution of aspects is
like a workflow but the semantic model is different. Maybe we should
stop using the word rule here. The synapse rules we have so far are
much more like aspects because they are simply attaching a behaviour
(mediation) to a set of messages (xpath selector). Its actually the
same model as a firewall that effectively implements a security policy
by selecting packets to act on.
Of course the behaviour - the mediator - can be a workflow and I hope
we will write a BPELMediator as well as script mediators. But that is
not the primary model that we are currently working to for the engine.
The primary model of the engine is attaching behaviour to messages in
a global manner.
Paul
On 10/21/05, *Mukund Balasubramanian* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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]
<mailto:[EMAIL PROTECTED]>>
To: [email protected] <mailto:[email protected]>
<[email protected] <mailto:[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]
<mailto:[EMAIL PROTECTED]>> <[EMAIL PROTECTED]
<mailto:[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://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] <mailto:[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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
:
: Geoffrey Fox [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> FAX
8128567972 http://www.infomall.org
: Phones Cell 812-219-4643 Home 8123239196 Lab 8128567977
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
