You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Guy Pardon <gu...@atomikos.com> on 2005/09/30 16:04:32 UTC
[Axis2] Feedback on handlers and services
Hi Axis team,
We at Atomikos are using Axis (currently 1.2) to implement web service
transaction support.
However, I recently found out about the axis 2 architecture which seems
a good answer to all the problems we encountered with 1.2 (such as no
support for WS-Addressing, insufficient support for asynchronous
messaging etc).
During our implementation of transaction handlers, we also found it to
be necessary that handlers have access to the same thread context that
will be used by the service implementation.
This is because the Java JTA binding of the WS-Transaction
specification will require this feature.
After going through the Axis2 documentation it is not yet clear if this
is the case in Axis2 (it works in 1.2, though).
Since support for WS-* standards seems to be one of the goals of Axis2,
I thought I would let you guys know about this.
Best,
Guy
Dr. Guy Pardon ( guy@atomikos.com )
Atomikos: The Transaction Processing Company
http://www.atomikos.com/
Visit my personal blog spot at http://guysblogspot.blogspot.com
The information in this email is confidential and only meant for the
addressee(s). The content of this email is informal and will not be
legally binding for Atomikos.
Re: [Axis2] Feedback on handlers and services
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
> On 9/30/05, Guy Pardon <gu...@atomikos.com> wrote:
> > Hi Axis team,
> >
> > We at Atomikos are using Axis (currently 1.2) to implement web service
> > transaction support.
> > However, I recently found out about the axis 2 architecture which seems
> > a good answer to all the problems we encountered with 1.2 (such as no
> > support for WS-Addressing, insufficient support for asynchronous
> > messaging etc).
Great .. any chance of you folks contributing to Kandula?
http://ws.apache.org/kandula/
> > During our implementation of transaction handlers, we also found it to
> > be necessary that handlers have access to the same thread context that
> > will be used by the service implementation.
> > This is because the Java JTA binding of the WS-Transaction
> > specification will require this feature.
> > After going through the Axis2 documentation it is not yet clear if this
> > is the case in Axis2 (it works in 1.2, though).
As Srinath pointed out, Axis2 does not switch threads in the default
message receivers. An message receiver which provides an async
programming model for the server could indeed switch but for the J2EE
integration case that will not be necessary.
Sanjiva.
Re: [Axis2] Feedback on handlers and services
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
> On 9/30/05, Guy Pardon <gu...@atomikos.com> wrote:
> > Hi Axis team,
> >
> > We at Atomikos are using Axis (currently 1.2) to implement web service
> > transaction support.
> > However, I recently found out about the axis 2 architecture which seems
> > a good answer to all the problems we encountered with 1.2 (such as no
> > support for WS-Addressing, insufficient support for asynchronous
> > messaging etc).
Great .. any chance of you folks contributing to Kandula?
http://ws.apache.org/kandula/
> > During our implementation of transaction handlers, we also found it to
> > be necessary that handlers have access to the same thread context that
> > will be used by the service implementation.
> > This is because the Java JTA binding of the WS-Transaction
> > specification will require this feature.
> > After going through the Axis2 documentation it is not yet clear if this
> > is the case in Axis2 (it works in 1.2, though).
As Srinath pointed out, Axis2 does not switch threads in the default
message receivers. An message receiver which provides an async
programming model for the server could indeed switch but for the J2EE
integration case that will not be necessary.
Sanjiva.
Re: [Axis2] Feedback on handlers and services
Posted by Srinath Perera <he...@gmail.com>.
As far as I understood you need the transaction handlers to be get
called by the same thread that will call the Service impl.
I think you are safe ..in Axis2 the Service impl is called by
component called a Message Receiver .. there could be Sync or Async.
If you use the Sync one (which is the default one :) ) it is the same
thread that call the handler and the Service impl.
If it is Async one threads are different, I think we can copy the
transaction context at the point of creating the thread explicitly
(See Async*MessageReceiver) .. it is not there yet.
See http://ws.apache.org/axis2/Axis2ArchitectureGuide.html#mr
Srinath
I cc the dev list to make sure other devs see this too, Thanks very
much for the comments .. we are looking forward for more !! :)
On 9/30/05, Guy Pardon <gu...@atomikos.com> wrote:
> Hi Axis team,
>
> We at Atomikos are using Axis (currently 1.2) to implement web service
> transaction support.
> However, I recently found out about the axis 2 architecture which seems
> a good answer to all the problems we encountered with 1.2 (such as no
> support for WS-Addressing, insufficient support for asynchronous
> messaging etc).
>
> During our implementation of transaction handlers, we also found it to
> be necessary that handlers have access to the same thread context that
> will be used by the service implementation.
> This is because the Java JTA binding of the WS-Transaction
> specification will require this feature.
> After going through the Axis2 documentation it is not yet clear if this
> is the case in Axis2 (it works in 1.2, though).
>
> Since support for WS-* standards seems to be one of the goals of Axis2,
> I thought I would let you guys know about this.
>
> Best,
> Guy
>
> Dr. Guy Pardon ( guy@atomikos.com )
> Atomikos: The Transaction Processing Company
> http://www.atomikos.com/
>
> Visit my personal blog spot at http://guysblogspot.blogspot.com
>
> The information in this email is confidential and only meant for the
> addressee(s). The content of this email is informal and will not be
> legally binding for Atomikos.
>
>
Re: [Axis2] Feedback on handlers and services
Posted by Srinath Perera <he...@gmail.com>.
As far as I understood you need the transaction handlers to be get
called by the same thread that will call the Service impl.
I think you are safe ..in Axis2 the Service impl is called by
component called a Message Receiver .. there could be Sync or Async.
If you use the Sync one (which is the default one :) ) it is the same
thread that call the handler and the Service impl.
If it is Async one threads are different, I think we can copy the
transaction context at the point of creating the thread explicitly
(See Async*MessageReceiver) .. it is not there yet.
See http://ws.apache.org/axis2/Axis2ArchitectureGuide.html#mr
Srinath
I cc the dev list to make sure other devs see this too, Thanks very
much for the comments .. we are looking forward for more !! :)
On 9/30/05, Guy Pardon <gu...@atomikos.com> wrote:
> Hi Axis team,
>
> We at Atomikos are using Axis (currently 1.2) to implement web service
> transaction support.
> However, I recently found out about the axis 2 architecture which seems
> a good answer to all the problems we encountered with 1.2 (such as no
> support for WS-Addressing, insufficient support for asynchronous
> messaging etc).
>
> During our implementation of transaction handlers, we also found it to
> be necessary that handlers have access to the same thread context that
> will be used by the service implementation.
> This is because the Java JTA binding of the WS-Transaction
> specification will require this feature.
> After going through the Axis2 documentation it is not yet clear if this
> is the case in Axis2 (it works in 1.2, though).
>
> Since support for WS-* standards seems to be one of the goals of Axis2,
> I thought I would let you guys know about this.
>
> Best,
> Guy
>
> Dr. Guy Pardon ( guy@atomikos.com )
> Atomikos: The Transaction Processing Company
> http://www.atomikos.com/
>
> Visit my personal blog spot at http://guysblogspot.blogspot.com
>
> The information in this email is confidential and only meant for the
> addressee(s). The content of this email is informal and will not be
> legally binding for Atomikos.
>
>