synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <ruwan.lin...@gmail.com>
Subject Re: JTA support in Synapse: general question
Date Sat, 22 Nov 2008 02:54:48 GMT
Well,

Irantha, it is required to support JTA standalone, but at the same time it
is much more important to support the application server translations as
well. Most of the time an ESB deployment is going to be on an existing
Application Server, though we would like people using ours standalone most
of the organizations tend to deploy it like this because of organizational
standards and many a reasons. That is what my experience about the
deployment of Synapse.

So I think we need to support both...

Thanks,
Ruwan

On Fri, Nov 21, 2008 at 12:24 PM, Irantha <irantha@wso2.com> wrote:

> On my view generally people like to have products that are easy to
> configure and use. Most of the time its easy to configure and get something
> working  with a standalone product than with multiple products /clusters.
> When somebody has to setup another application server to get transactions
> working, there is more possibility that they will not try it at all or mess
> it up.
> I don't think most of the time people who are going to setup a ESB are
> doing it for the enjoyment of their leisure time. But I may be wrong.
>
> Thanks,
> Irantha
>
>
>
>
> Asankha C. Perera wrote:
>
>> Paul / Andreas
>>
>> I definitely like being able to provide standalone JTA support without a
>> JEE server - like we already support DataSources without a JEE server.
>>
>> Looking at real world JTA use, one would most definitely agree that JMS
>> and DB's are the most common, though there can and certainly will be other
>> resource managers. Typically a JMS provider (since we don't bundle one), a
>> DB, and requirement for JTA, and any other JTA aware RMs, makes me think
>> that the client already has a TM too :-)    (e.g. a JEE server).. but I
>> agree this is just my personal view and I could be wrong in some cases.. So
>> I think we should not hard code anything specific to any of these standalone
>> TM's like Atomikos, JOTM etc.. or try to implement this support immediately,
>> as a pre-requisite to accept the enhancements we already have.
>>
>> We should rather be able to bind them (i.e. any standalone TM) to our
>> standalone JNDI, and use them as we use any other TM.. the research we need
>> here is how to do this.. and I'm sure that some users of these may have
>> already achieved this, or the providers of these already knows how to do
>> this, and would probably help us.
>>
>> asankha
>>
>>  Andreas
>>>
>>> The lightweight transaction managers are definitely good. I personally
>>> like Atomikos, but I'm happy to consider any alternatives. Do you have
>>> experience with any?
>>>
>>> Paul
>>>
>>> On Thu, Nov 20, 2008 at 10:15 PM, Andreas Veithen
>>> <andreas.veithen@gmail.com> wrote:
>>>
>>>
>>>> Sanjiva,
>>>>
>>>> The example was just meant to illustrate my point and probably there
>>>> are better examples. I just wanted to trigger a discussion about the
>>>> direction in which we are going. I agree with the approach outlined by
>>>> Paul and I think Asankha gave some very valuable information that we
>>>> need to take into account if we want to build higher level transaction
>>>> support later.
>>>>
>>>> My next question is what would be the recommendation to have
>>>> distributed transaction support (e.g. between JMS and a database) in a
>>>> Synapse stand-alone installation. Is there some lightweight Open
>>>> Source transaction manager that one can use (to avoid the burden of
>>>> installing a full-featured application server)? I'm thinking about
>>>> something as Jencks or JOTM.
>>>>
>>>> Andreas
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>


-- 
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/

Mime
View raw message