On Sun, 2005-10-23 at 17:11 -0500, Geoffrey Fox 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.
The big question to me is: even when we do have (say) a BPEL model describing the full mediation, whether we still need a simple matching layer on top to select *which* workflow to run for a given message. Mukund, if I understand you correctly, in the case of the Infravio code, this issue is avoided because you're deploying a specific handler configuration for a given mediation. Is that correct? Clearly we need to support that pattern too- where the mediation is chosen based on the <To> URI and no other "matching" occurs. A simple strcmp will do for that process! However, as a general mediation framework, do we not all agree that there needs to be some capability to select which mediation to run given a message? If so, that's the outermost execution logic of Synapse. Some type of a pattern matching approach does seem necessary for that to me. Whether we use XPath or simply string matching .. I actually suggest we use simple regexp matching against the <To> for a start and go more complicated later. Sanjiva. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
