|
Comments inline... -----Original Message----- 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. Exactly
the question you should address and whether the question “which mediation
should I run” should be determined by a mediation component in itself! this issue is avoided because you're deploying a specific handler configuration for a given mediation. Is that correct? You are
absolutely correct, in the case of the Infravio code, we deploy the entire
mediation chain as handler configuration and hence make this decision AS EARLY
as possible (deployment of an Axis 1 service representing the mediated
service). Decision making is then relegated to “routing” which
follows the rule based approach. 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! Correct.
XPath might be overkill, URI matching by the Web/App server could also do
though with more limitations. 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. We
agree to the use case. We agree to _expression_ in the form of rules. I just don’t
think I am ready to commit to the exact chain of responsibility since I
continue to maintain that some of these decisions can be made earlier than
message receipt. 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. That is
totally an implementation issue. We can use XPath to express the matching rule
and fall back to regexp to do the actual matching. Some of these standard
expressions are actually executed that way in the Infravio code today albeit
for simple xpath’s such as “true()”. Sanjiva. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |
- RE: Is Synapse workflow? Mukund Balasubramanian
- Re: Is Synapse workflow? Paul Fremantle
