RE: [SPAM] - Re: [AXIS2] J2EE Support - Message is from an unknown sender
Dennis Sosnoski ,
Why do you want to expose ejb's as webservices directly ?not all methods in
ejb has to be exposed as webservices operations right.In this case it better
to right wrappers to the ejb methods and expose that wrappers class as
webservice.
Do you have any advantages exposing ejb to as webservices - was wondering
why weblogic , jboss has such an option.
-Original Message-
From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 4:38 AM
To: axis-user@ws.apache.org
Subject: [SPAM] - Re: [AXIS2] J2EE Support - Message is from an unknown
sender
I think there are really two different approaches possible for handling
EJB web services. The first is what I think you're focused on,
automatic exposure of EJBs as web services using annotations or the
like. AFAIKS, this really needs to be implemented by the app server
framework because that controls both the class loading (you need hooks
into the class loading to see the annotations in the first place) and
the EJB deployment.
The second is what I was suggesting, which is to have the service
implementation basically function as a proxy to the actual EJB. This
means that the service implementation is just another client of the
service as far as the app server is concerned. The actual proxy code
could be generated by an Axis2 add-on. If you run Axis2 inside the app
server, the overhead of accessing the EJB in this way will be minimal;
if you run it outside the app server you'll have more overhead (as with
any EJB client), but you'll gain the flexibility of keeping your web
services support on a standard servlet engine rather than an app server.
Both these approaches work, but the first one (which includes JSR-109
support) can really only be implemented by the people running the app
server. JAX-WS doesn't require an app server so can be integrated
directly into Axis2 - but AFAIK it doesn't give you automatic EJB support.
- Dennis
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
robert lazarski wrote:
Well, so far in the developement of axis2 best as I can tell, for good
reasons, there has not been a pragmatic discussion of Axis2 and pure
EJB services, ie, a ServiceClass implementing SessionBean.
I'd like to think what I was trying to imply was that currently (A) no
one has a working case and documentation supporting it, (B) there is a
corner case demand for it, and (C) I have an itch to scatch to support
clients who simply want it.
So far Axis2 has no 'code generator to create these proxy classes' .
So how do we get there? Perhaps with JSR-109 - the 109 specification
now also supports JAX-WS which is a follow-on specification to
JAX-RPC - and the JAX-WS support in Axis2 recently, maybe that's the
way to go.
Comments?
Robert
http://www.braziloutsource.com/
On 6/18/06, Dennis Sosnoski [EMAIL PROTECTED] classesosnoski.com wrote:
Okay, so I guess what you're after is automatic deployment of EJBs as
web services. The alternative of making regular calls to the actual EJB
just involves using a proxy class which handles the EJB lookup and
forwards all calls on to the EJB. It should be fairly easy to just
write a code generator to create these proxy classes. Even without
automatic proxy generation it seems extreme to say that Axis2 is not an
option, though.
- Dennis
robert lazarski wrote:
On 6/16/06, *Dennis Sosnoski* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
robert lazarski wrote:
snip
Currently I'm integrating an EJB app with Axis2 - thankfully
as any
tomcat / servlet container web layer would. However, I came very
close
to having to implement these services as EJB, which would have
required either JAX-WS or Axis 1.x , as Axis2 just isn't an
option.
I'm puzzled by this statement, Robert. Why is Axis2 not an
option? You
just use the EJB interfaces to access the service classes, same as
any
other application using the EJBs.
- Dennis
I'm not 100% sure we are on the same page, so allow me to give an
example - in JBoss 4.0.x using JSWDP databinding and axis 1.x - a
strange hybrid but that's what JBoss supports:
enterprise-beans
session
ejb-nameMyWebService/ejb-name
ejb-classorg.MyWebService/ejb-class
session-typeStateless/session-type
ejb-ref
!-- SoapSession is a stateful session bean --
ejb-ref-nameejb/SoapSession/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homeorg.SoapSessionHome/home
remoteorg.SoapSession/remote
/ejb-ref
...
session
/enterprise-beans
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
public class MyWebService implements SessionBean {
private SessionContext ctx
Re: [SPAM] - Re: [AXIS2] J2EE Support - Message is from an unknown sender
I'm not actually the one concerned with exposing EJBs as web services. I agree that the proxy or wrapper class approach is the best way to approach the problem, though. - Dennis Dhakshinamoorthy, Hariharasudhan wrote: Dennis Sosnoski , Why do you want to expose ejb's as webservices directly ?not all methods in ejb has to be exposed as webservices operations right.In this case it better to right wrappers to the ejb methods and expose that wrappers class as webservice. Do you have any advantages exposing ejb to as webservices - was wondering why weblogic , jboss has such an option. -Original Message- From: Dennis Sosnoski [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 4:38 AM To: axis-user@ws.apache.org Subject: [SPAM] - Re: [AXIS2] J2EE Support - Message is from an unknown sender I think there are really two different approaches possible for handling EJB web services. The first is what I think you're focused on, automatic exposure of EJBs as web services using annotations or the like. AFAIKS, this really needs to be implemented by the app server framework because that controls both the class loading (you need hooks into the class loading to see the annotations in the first place) and the EJB deployment. The second is what I was suggesting, which is to have the service implementation basically function as a proxy to the actual EJB. This means that the service implementation is just another client of the service as far as the app server is concerned. The actual proxy code could be generated by an Axis2 add-on. If you run Axis2 inside the app server, the overhead of accessing the EJB in this way will be minimal; if you run it outside the app server you'll have more overhead (as with any EJB client), but you'll gain the flexibility of keeping your web services support on a standard servlet engine rather than an app server. Both these approaches work, but the first one (which includes JSR-109 support) can really only be implemented by the people running the app server. JAX-WS doesn't require an app server so can be integrated directly into Axis2 - but AFAIK it doesn't give you automatic EJB support. - Dennis Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 robert lazarski wrote: Well, so far in the developement of axis2 best as I can tell, for good reasons, there has not been a pragmatic discussion of Axis2 and pure EJB services, ie, a ServiceClass implementing SessionBean. I'd like to think what I was trying to imply was that currently (A) no one has a working case and documentation supporting it, (B) there is a corner case demand for it, and (C) I have an itch to scatch to support clients who simply want it. So far Axis2 has no 'code generator to create these proxy classes' . So how do we get there? Perhaps with JSR-109 - the 109 specification now also supports JAX-WS which is a follow-on specification to JAX-RPC - and the JAX-WS support in Axis2 recently, maybe that's the way to go. Comments? Robert http://www.braziloutsource.com/ On 6/18/06, Dennis Sosnoski [EMAIL PROTECTED] classesosnoski.com wrote: Okay, so I guess what you're after is automatic deployment of EJBs as web services. The alternative of making regular calls to the actual EJB just involves using a proxy class which handles the EJB lookup and forwards all calls on to the EJB. It should be fairly easy to just write a code generator to create these proxy classes. Even without automatic proxy generation it seems extreme to say that Axis2 is not an option, though. - Dennis robert lazarski wrote: On 6/16/06, *Dennis Sosnoski* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: robert lazarski wrote: snip Currently I'm integrating an EJB app with Axis2 - thankfully as any tomcat / servlet container web layer would. However, I came very close to having to implement these services as EJB, which would have required either JAX-WS or Axis 1.x , as Axis2 just isn't an option. I'm puzzled by this statement, Robert. Why is Axis2 not an option? You just use the EJB interfaces to access the service classes, same as any other application using the EJBs. - Dennis I'm not 100% sure we are on the same page, so allow me to give an example - in JBoss 4.0.x using JSWDP databinding and axis 1.x - a strange hybrid but that's what JBoss supports: enterprise-beans session ejb-nameMyWebService/ejb-name ejb-classorg.MyWebService/ejb-class session-typeStateless/session-type ejb-ref !-- SoapSession is a stateful session bean -- ejb-ref-nameejb/SoapSession/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homeorg.SoapSessionHome/home remoteorg.SoapSession/remote /ejb-ref
Re: [SPAM] - Re: [AXIS2] J2EE Support - Message is from an unknown sender
Exposing an EJB as a web service can have several advantages: - Less classes: exposure as a web service can be achieved by other methods than specific proxy classes, and this may lead to a smaller footprint. - Better integration with app server authentication and other mechanisms. You have to manually apply the correct handlers to add security, addressing, policy, transactions, etc, and program what to do on errors in each of these layers. An app server can automatically apply them when/where needed. - The flexibility of being able to put your web service proxies in a simpler servlet engine is often not a desired feature. In many cases it will be preferable to add a node to the app server cluster than wasting a machine with a servlet engine, that after all will also need to be replicated in order to maintain the same service level than EJBs have. Separating the proxies to a different machine adds costs in hardware and maintenance, and introduces additional connectivity errors. Having them in the same app server than EJBs removes these costs. - It gives you a reasonably easy way to access a J2EE server through firewalls that only allows HTTP/S connections, without having to spend time in an alternative interface. If you say this is not the right approach in the long term, I agree with you. I think web services are more effectively used when they are built from the ground, taking into account their specific characteristics. But if your EJBs already publish a reasonable API, this allows you to extend your J2EE services to other languages (almost) without extra effort/cost. Hope this helps, Rodrigo Ruiz Dhakshinamoorthy, Hariharasudhan wrote: Dennis Sosnoski , Why do you want to expose ejb's as webservices directly ?not all methods in ejb has to be exposed as webservices operations right.In this case it better to right wrappers to the ejb methods and expose that wrappers class as webservice. Do you have any advantages exposing ejb to as webservices - was wondering why weblogic , jboss has such an option. -Original Message- From: Dennis Sosnoski [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 4:38 AM To: axis-user@ws.apache.org Subject: [SPAM] - Re: [AXIS2] J2EE Support - Message is from an unknown sender I think there are really two different approaches possible for handling EJB web services. The first is what I think you're focused on, automatic exposure of EJBs as web services using annotations or the like. AFAIKS, this really needs to be implemented by the app server framework because that controls both the class loading (you need hooks into the class loading to see the annotations in the first place) and the EJB deployment. The second is what I was suggesting, which is to have the service implementation basically function as a proxy to the actual EJB. This means that the service implementation is just another client of the service as far as the app server is concerned. The actual proxy code could be generated by an Axis2 add-on. If you run Axis2 inside the app server, the overhead of accessing the EJB in this way will be minimal; if you run it outside the app server you'll have more overhead (as with any EJB client), but you'll gain the flexibility of keeping your web services support on a standard servlet engine rather than an app server. Both these approaches work, but the first one (which includes JSR-109 support) can really only be implemented by the people running the app server. JAX-WS doesn't require an app server so can be integrated directly into Axis2 - but AFAIK it doesn't give you automatic EJB support. - Dennis Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 robert lazarski wrote: Well, so far in the developement of axis2 best as I can tell, for good reasons, there has not been a pragmatic discussion of Axis2 and pure EJB services, ie, a ServiceClass implementing SessionBean. I'd like to think what I was trying to imply was that currently (A) no one has a working case and documentation supporting it, (B) there is a corner case demand for it, and (C) I have an itch to scatch to support clients who simply want it. So far Axis2 has no 'code generator to create these proxy classes' . So how do we get there? Perhaps with JSR-109 - the 109 specification now also supports JAX-WS which is a follow-on specification to JAX-RPC - and the JAX-WS support in Axis2 recently, maybe that's the way to go. Comments? Robert http://www.braziloutsource.com/ On 6/18/06, Dennis Sosnoski [EMAIL PROTECTED] classesosnoski.com wrote: Okay, so I guess what you're after is automatic deployment of EJBs as web services. The alternative of making regular calls to the actual EJB just involves using a proxy class which handles the EJB lookup and forwards all calls on to the EJB. It should be fairly easy
