So I would really like to see what you describe. BUT - I also think there are two stages in any enterprise integration framework. Stage 1 is very high performance pervasive and STATELESS. Stage 2 is full workflow, transaction message processing. Stage 1 should be transactional but since its stateless that is fairly low key local transactions. Stage 2 encompasses both two-phase and long running transactions.
I personally think that Stage 1 is the scope for synapse, but that is just naming. Whether we do Stage1 and Stage2 under the Synapse project, or setup a follow on project to do Stage 2.
As regards clustering and failover, I see that as a key aspect of Synapse. In fact, when I say stateless, there probably is state associated with replies. Ideally we will aim to handle as much reply state as possible using the WS-Addressing model and reference params. For the cases where we can't we will need some state distribution and replication model, possibly based on an event model or a distributed database.
Paul
On 10/21/05, Aleksander Slominski <[EMAIL PROTECTED]> wrote:
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]
