--- Begin Message ---
* Now talking on #servicemix
<gnodet> good morning/afternoon/evening/night everybody
<terry> Hi from Leeds
<gnodet> who's listening here ?
<pbzdyl> hi, this is piotr
<gertv> I will be in half an hour or so, after dinner
<gertv> I'll quickly read the logs at that time, so I can just 'hop' in
<gnodet> great
<gnodet> i guess we can wait a few minutes as we're missing a few people
that should join
<terry> Poke 'em with a stick
<gnodet> like kit, brian and bruce
<gnodet> or maybe we can start and they will hopefully join...
<gnodet> i haven't been able to work much on the api since last week
* terry looks guilty
<gnodet> lol
<gnodet> yeah....
<gnodet> anyway, there are still some areas that are not clear
<gnodet> is there any points you'd like to discuss in particular?
<terry> I've only gotten as far as checking out the code, so have yet to
play with it in anger.
<gnodet> well, there' s not much yet for the impl
<gnodet> but there's lots of areas that need to be defined: security,
transactions, flows
<gnodet> threading model
<gnodet> lifecycle
<pbzdyl> I can see some listeners - are you planning to support also
interceptors?
<gnodet> yeah, this is something that has been discussed for jbi 2.0 too
<gnodet> i guess the main difference between a listener and an
interceptor would be a filtering mechanism
<pbzdyl> and possibility to influence invocation of actual target endpoint
<gnodet> you mean something like AOP ?
<pbzdyl> yes
<pbzdyl> most of things you can do with listeners
<pbzdyl> but in listener you cannot e.g. abort sending exchange to
target endpoint (e.g. security or throttling interceptor)
<terry> WRT transactions and flows: I would like to be able to have
persistent flows that follow a queue-based transactional model, but
still permit non-persistent, synchronous calls within the scope of a
queue-related transaction.
<pbzdyl> I would also like to explicitly mention throttling
<pbzdyl> if you cooperate with external businesses you need to ensure SLA
<terry> Agreed
<pbzdyl> but this probably can be implemented by interceptors
<gnodet> so for the interceptor, i guess one problem is that the
exchange processing is not synchronous
<pbzdyl> I guess we are discussing only ESB without components
capabiblities?
<gnodet> so that you can not modify a return value as you could do with AOP
<terry> In general, contract / SLA behaviours ought to be describable as
aspects.
<gnodet> we can talk about components too
<gnodet> but aspects mainly define procedual things, don't they?
<gnodet> when you need to correlate exchanges, aspects won't be
sufficient i guess
* rdavies ([EMAIL PROTECTED])
has joined #servicemix
<pbzdyl> you need also some storage to collect correlated exchanges...
<pbzdyl> not a nice thing
<terry> aspects as a view across the system, rather than as a specific
implementation technology
<jstrachan> pbzdyl: btw seen this?
http://activemq.apache.org/camel/throttler.html - it might need a bit of
work to be a nice jbi citizen though :)
<gnodet> yeah, but i guess this is an implementation detail somehow
* romkal ([EMAIL PROTECTED]) has joined #servicemix
<gnodet> yeah, i was thinking of using some camel constructs to define
some behaviors
<pbzdyl> jstrachan: thanks
<gnodet> like redelivery, exception handling, even routing
<gnodet> so maybe think as JBI endpoints as real services
<gnodet> and use camel between them
<gnodet> we would need to enhance camel to support everything needed of
course
<terry> That suits my view
<pbzdyl> this seems good for me
<gnodet> but at the same time, if it could be policy based, that would
be nice
<jstrachan> gnodet: yeah :)
<gnodet> so we need a way to convert a policy to a camel dsl maybe
<gnodet> but one could use the camel dsl directly of course
<jstrachan> yeah - another approach is the AOP style too; applying
policies on top of some routing DSL
* terry nods
<pbzdyl> also in case of several smix instances it would be good to have
this throttling feature clustered
<jstrachan> yeah
<pbzdyl> but this is also an implementation detail
<terry> From a development POV, it's the QoS stuff that is hard.
<gnodet> agreed
<terry> So anything we can do to seperate from business logic is a win.
<gnodet> but the problem is that transaction are tied to
synchronous/asynchronous
<terry> Grunt developers never grok QoS issues
<gnodet> i'm not sure how to remove this coupling so that the
tranactional behavior would not affect the code
<gnodet> the easiest solution would be to say: if there is a
transaction, everything will be synchronous
<gnodet> that could be the default
<terry> It's more a matter of making it consistent
<gnodet> but it may not suit some needs
<jstrachan> gnodet: yeah - thats kinda hardcore; all of spring's txn
stuff for example assumes a sync programming model
* bsnyder ([EMAIL PROTECTED]) has joined #servicemix
<gnodet> so the other solution is to tie the transactional behavior to
the mep
* prb ([EMAIL PROTECTED]) has joined #servicemix
<terry> Hence what I said earlier about joining sync transactions in
between async ones.
<terry> At least it's predictable
<terry> And can solve many EIP situations
<gnodet> yes, i agree
<gnodet> this may lead to problems using flows as they are defined in
smx 3.0
<gnodet> because atm, the flow can be considered as a transacted resource
<gnodet> and you need to put that away if you tie the transaction to the
mep i think
<terry> Are you restricted to a single flow at a time?
<gnodet> not really, but for a given exchange, i guess yes
<gnodet> so different exchanges can use different flows
* bsnyder has quit ("When the going gets weird, the weird turn pro.")
<terry> So it ought to work
<gnodet> problem comes with clustering
<gnodet> if you want it to be transparent
<terry> Hmmm
<gnodet> because usually, you can not do transactional in/out with a
remote endpoint
<terry> JCA?
<gnodet> yes, if you use async
<gnodet> sorry, i was thinking about synchronous
<gnodet> so if you use a synchronous call on an InOut mep, you can do
that transactional if the endpoint is local, but you can't if the
endpoint is remote
<gnodet> not sure if this is a real problem though
<gnodet> as i guess you may want to design your application knowing
where can the endpoints be remote
<gnodet> or else just use asynchronous calls
<romkal> it depends on the endpoint - JMS can be transactional
<gnodet> not for request/reply
<romkal> if we cannot use transaction becouse of the nature of the
endpoint then - sorry
<romkal> right
<gnodet> yeah, so you may have optional policies and mandatory
<gnodet> if there is a conflict, then raise an error
<gnodet> terry: about what you said earlier
<gnodet> you want to have a transaction, and within the transaction that
executes synchronously, be able to use persistence between endpoints ?
<gnodet> this is not very effective, isn't it?
<romkal> in some cases it is more important to have transaction than to
have performance anyway
<gnodet> yeah, my point is that it's easier to use transaction and
persistence together
<gnodet> that's what jms provides
<gnodet> if you rollback the transaction, the message is still there
<gnodet> so there' s no point in persisting the message between two
endpoints that use the same transaction
<gnodet> anybody familiar with acegi ?
<romkal> but it requires sync mode doesn't it?
<gnodet> between the endpoints ?
<romkal> yes
<gnodet> currently, yes
<gnodet> currently, synchronous means that the transaction is conveyed
with the exchange to the target endpoint
<jstrachan> a random idea; am wondering if the logical routing between
multiple services needs to be kinda refactored into possibly multiple
different exchanges, to kinda break the single exchange into multiple
exchanges to get around the transaction limitations. e.g. an InOut call
on a remote service could be transactional using 2 separate JMS
transactions; similarly we can sometimes use a queue / database as a way
of easing the transaction burden
<jstrachan> i.e. users just wanna route things together; then the
runtime/container/esb should figure out how to apply the transaction
policy to take a logical flow and turn it into physical transactions etc
<jstrachan> for some things like http / files - you may not use a real
transaction manager; you might just retry & filter duplicates
<gnodet> well, the problem is i'm not sure there is a clean way to
decouple transaction from the synchronous/async
<jstrachan> yeah
<gnodet> which means that you can not change the transaction
demarcations without changing the code
<gnodet> but is really bad
<gnodet> or maybe we can? that would be nice
<gnodet> so the idea is (as always) to remove any transactional /
persistence / remoting concerns away from the code
<gnodet> if we look at the EIP component, it can handle the different
cases though
<gnodet> you can invoke it synchronously or asynchronously
<gnodet> so if the code supports the different QoS, we should be able to
find a way to define these concerns in an easier way
<jstrachan> yeah
<gnodet> terry: if we tie the transactional behavior to the mep, one
would not be able to change the transactional behavior without
redesigning the flow, right?
<gnodet> wouldn't this be a problem?
<jstrachan> a given logical message flow could be represented by
multiple physical transactional flows (e.g. using JMS for each step -
merging steps together into a sync step, using WS-Transaction, using XA
and hosting every component, yada yada - part of me wonders if we should
split the logical routing steps from the transactional threading stuff
so folks can tinker - but its hard & right now I"ve no idea what that'd
look like :)
* terry has quit (Ping timeout)
<romkal> It definitely looks like distributed transaction in JTA. To
have it working we have to have transactional message exchange that can
be achieved by different transactions on JMSFlow
<gnodet> this really sounds like using different flows
<gnodet> romkal: it depends on different things i guess
<gertv> wouldn't it mostly depend on the endpoint itself?
<gnodet> if you want to invoke a remote endpoint transactionaly, send
this means distributed jta
<gertv> wouldn't it be possible to query the endpoint for the types of
transactions it can support?
<gnodet> gertv: i guess this would be nice for a tooling problem
<gnodet> but what is the purpose at runtime?
<gnodet> select between different endpoints maybe?
<gertv> or falling back to an alternative strategy: if it can't support
a 'real' synchronous transaction, perhaps it can do compensation
handling to mimic a transaction when a rollback occurs
<gnodet> yeah, but that would involve some coding i suppose
<gnodet> i think some of the problems comes from the InOptionalOut pattern
<gertv> yes, it would; at least, it would on the component's part
<gnodet> because one does not really know for sure where the exchange
will end
<gnodet> if there is no response, the exchange will end at the consumer
side when it receives the done
<gnodet> but if the provider sends one, the exchange will end at the
provider side
<gnodet> but i've yet to see an example of InOptionalOut
<gertv> but if it's in the JBI spec, we cannot simply drop it, I suppose...
<gnodet> we could say: if you want transaction, don't use it
<gnodet> but i think there are other problems
<gnodet> i need to think more about relating transactions to meps
<gertv> how would they relate in your mind?
<gnodet> terry suggested InOut => the transaction is conveyed
<gnodet> and InOnly => the delivery is transacted
<gnodet> or something like that
<gnodet> it seems everything is much more complicated when dealing with
asyncrhonous stuff
<gnodet> but we cant really drop asynchronous stuff ;-)
<gertv> I'm really sorry, but I'm called to duty again (putting the kids
in bed ;) )
<gnodet> yeah, it's being late
<gnodet> i will post the thread to the dev list for further discussion
<gertv> I think we still have a lot to talk about
<romkal> So maybe I'll try to start a thread about some other functionality
<gnodet> romkal: feel free to do so
<gnodet> i think we can have a weekly meeting on friday, and move it to
suit everybody availability
<romkal> We have an ExchangeListener that can be declared on
servicemix.xml level. I thought about similar functionality on
component/endpoint level
<romkal> it looks quite easy and it can help a lot in some
monitoring/metric scenarios
<gertv> perhaps it's nice if we can summarize the ideas for new features
to the wiki, once they have discussed
<gertv> so we end up with a well-documented roadmap for developing 4.0
<gnodet> yeah
<romkal> now to intercept message arival we can use AOP on an endpoint,
but we cannot detect any outgoing message because of possible async
processing
<gnodet> yeah, and that' s what makes things difficult
<gnodet> so maybe we should have a simple synchronous model
<gnodet> but i guess we already have it: just use jaxws
<gnodet> does anyone has a log of the channel in a readable form ?
<gnodet> mine is ugly or xml :-(
<gertv> mine is kind of readable, I guess
<gertv> <gnodet> so maybe we should have a simple synchronous mode
<gertv> <gnodet> but i guess we already have it: just use jaxws
<gnodet> nice :-)
<gertv> I'll post it on the mailing list this evening
<gnodet> cool, thx
<gnodet> romkal: fee free to start a thread on the mail list, really
<gertv> If I find the time (and succeed in understanding everything)
I'll also try to summarize it on the wiki
<gnodet> that would be awesome :-)
<romkal> And what about some error handling mechanism - I send message
and what I receive is an error with an java exception inside
<romkal> I don't really know where it was thrown
<romkal> Sometimes it is quite important
<romkal> Do we have any solution for such problems? Maybe instead of
simple exception in Error message we should send some additional info?
--- End Message ---
