On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> Still not sure to understand, sorry.
> What is the added feature compared to
> the routing slip EIP pattern [1] ?
In Java terms, the routing slip feels like a series of method calls
whereas a pipeline of components is more like a chain of decorators.
For example, a natural way for me to introduce a component that
records how long a downstream component takes to execute would be to
add it in front of the component (i.e. all clients now call the
timingcomponent) and it then calls the downstream component and times
how long it takes. while this could be done with a static routing slip
(i.e. have the slip call the timing component, then the real component
then the timing component again), it doesn't feel like the tidiest way
to do it. I could be wrong, though.
Ok, I think I understood your idea now.
It's basically a proxy, like the wire tap, which a chain of handlers configured
on it, right ?
Something like:
<eip:handler-chain>
<eip:target>
<eip:exchange-target service="test:xpathSplitter" />
</eip:target>
<eip:handlers>
... list of handler beans here ...
</eip:handler>
</eip:handler-chain>
> Do you just want to
> get rid of the store ? I guess we just need to send
> the original exchange along with the requests to
> services (as a property on the exchange). I think
> the performances may be better if a few services
> are used, else it may be more costly as the
> original exchange will be serialized for each exchange
> instead of only once.
Yup, I mainly just want to get rid of the store to support the use
case above. The clustered asynchronous static routing slip is also
potentially expensive as it stores and serializes the exchange twice
for each call too (once to database and once when sending).
It would have to be the whole message history, though, which is why a
stack of message exchanges (with some way to optimise the stack) would
be useful. Just thought some more about the stack of delta's idea and
it wouldn't work using standard JBI (i.e. you wouldn't be able to
recreate a messageexchange from the stack unless it knows about
messageexchangeimpl... hmm... unless it was the delta of the
serialized bytes... okay too crazy). bother. That said, I'd still like
it as an option.
Just having an efficient way to support the message history pattern
(http://www.enterpriseintegrationpatterns.com/MessageHistory.html)
would be useful.
One of the problem when using clustered components, is the behavior
you want in case one node fails. Unless configured to do so, the NMR
will assume that when a component send an exchange, it may maintain
some state wrt to this exchange, hence the NMR will send the exchange
back to the same component instance (same node in a cluster). In such
a case, you can just keep the original exchange in memory. However,
if the node dies while waiting for the response, the exchange will be waiting
until the node is ready again.
The other way is to tell the NMR that the component does not maintain
any state or that this state is also clustered. This can be done
by setting the JbiConstants.STATELESS_CONSUMER property on the
exchange sent by the consumer, as done in the EIP component.
This allow the NMR to route the exchange to any component instance
in the cluster.
In the case of the pipeline you describe, there is a state to maintain, which
is at least the original exchange received by the component. If you want
the process to be asynchronous, you need to store this exchange somewhere
(either as part of the new exchange or in a persistent store).
Note that if you put the original exchange as a property in the new exchange,
the original exchange will be serialized each time the new exchange is also
serialized, which should be the same number of times (serialized only once),
but will be faster (as you do not need a remote jdbc call).
Note that for the static routing slip, the original exchange would be serialized
at least 3 * N times, N being the number of services invoked (once for in, out
and done exchanges), so in this case, I'm not sure it would be faster.
I guess nearly all EIP patterns could be improved to support such a store.
Btw, feel free to raise a JIRA on servicemix-eip.
cheers,
j.
On 10/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Still not sure to understand, sorry.
> What is the added feature compared to
> the routing slip EIP pattern [1] ?
>
> This component already handle the asynchronous
> reliable InOut patterns, but yes, it needs a store
> to keep the original exchange. Do you just want to
> get rid of the store ? I guess we just need to send
> the original exchange along with the requests to
> services (as a property on the exchange). I think
> the performances may be better if a few services
> are used, else it may be more costly as the
> original exchange will be serialized for each exchange
> instead of only once.
>
> [1]
http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-StaticRoutingSlip
>
> On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > hiya,
> >
> > > Could you be a bit more precise about your
> > > wrapping / unwrapping operation ?
> >
> > one way to do this would be with a message history pattern. have a
> > stack of ME's as an exchange property and just pop them as the
> > in-out's come back through the pipeline.
> >
> > of course, that'd be hideously inefficient after a few hops. the stack
> > could be smarter and just store delta's (that'd probably be useful for
> > just doing the message history pattern too). if each component in the
> > pipeline is changing the content radically then there still wouldn't
> > be that much benefit but often intermediate components are doing
> > aop-like things like logging, authentication, caching which don't
> > actually touch the contents particularly much (of course, all of the
> > previously mentioned use cases are catered for in other ways by
> > servicemix but you get the idea).
> >
> > please let me know if you need more info.
> >
> > cheers,
> > j.
> >
> > On 10/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > Could you be a bit more precise about your
> > > wrapping / unwrapping operation ?
> > >
> > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> > > > Not sure if this makes sense but:
> > > >
> > > > I'd like a way to do reliable / clustered / asynchronous in-out
> > > > pipelining of message exchanges without having to use a JdbcStore. One
> > > > way to do it would be to able to wrap message exchanges as they pass
> > > > through each component in the pipeline (and then unwrap them on the
> > > > way back).
> > > >
> > > > cheers,
> > > > j.
> > > >
> > > > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > > ServiceMix is ultimately your project, and we need feedback
> > > > > to help focus on what you think is needed to improve the project.
> > > > >
> > > > > If you have ever thought, "ServiceMix would be such a nice project, if
> > > > > only ...",
> > > > > it' s time to speak !
> > > > >
> > > > > We'd like to hear from everyone, from beginners to advanced users,
> > > > > so please fell free to speak and list the topics you'd like to
> > > > > improve or new features to be implemented.
> > > > >
> > > > > Please, every user out there, give us your top 5 things we
> > > > > can do to make ServiceMix better for you.
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
--
Cheers,
Guillaume Nodet
