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: [email protected] 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-name>MyWebService</ejb-name> >> > <ejb-class>org.MyWebService</ejb-class> >> > <session-type>Stateless</session-type> >> > <ejb-ref> >> > <!-- SoapSession is a stateful session bean --> >> > <ejb-ref-name>ejb/SoapSession</ejb-ref-name> >> > <ejb-ref-type>Session</ejb-ref-type> >> > <home>org.SoapSessionHome</home> >> > <remote>org.SoapSession</remote> >> > </ejb-ref> >> > ... >> > <session> >> > </enterprise-beans> >> > >> > import javax.ejb.SessionBean; >> > import javax.ejb.SessionContext; >> > >> > public class MyWebService implements SessionBean { >> > >> > private SessionContext ctx; >> > >> > public ReturnWeb_Login web_Login( >> > String user_name, >> > String user_password) throws RemoteException { >> > >> > Integer successErrorCode = Messages_Codes.FAILURE; >> > String soap_session_id = null; >> > Connection con = null; >> > >> > try { >> > con = getConnection(); >> > successErrorCode = >> CallCentreDAO.login(con,orner >> > call_centre_id, >> > user_name, user_password, this); >> > >> > if(Messages_Codes.SUCCESS == >> successErrorCode) { >> > SoapSession soapSession = >> > serviceLocator.getSoapSessionHome().create(); >> > soapSession.setTimestamp( >> > Calendar.getInstance() ); >> > soap_session_id = >> > serviceLocator.getSoapSession_Id(soapSession); >> > >> > } else { >> > successErrorCode = >> > Messages_Codes.AuthorizationFailed; >> > } >> > } catch(Exception ex) { >> > ctx.setRollbackOnly(); >> > successErrorCode = Messages_Codes.FAILURE; >> > } finally { >> > if(con!=null) >> > try{con.close();}catch(SQLException >> ex){}; >> > } >> > >> > return new ReturnWeb_Login ( >> > Messages_Codes.get(successErrorCode), successErrorCode.intValue(), >> > soap_session_id, user_name); >> > } >> > >> > So what this does is allow EJB transactions in a web service - notice >> > ctx.setRollbackOnly() , and a soap session managed by the EJB >> > container via a stateful session bean. >> > >> > OK, so why can you _not_ do this with Axis2 ? >> > >> > 1) JBoss modified axis 1.x to support ejb transactions: >> > >> > http://wiki.jboss.org/wiki/Wiki.jsp?page=WebServiceStacks >> > >> > JBossWS4EE <http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossWS4EE> is >> > J2EE-1.4 compliant and available starting from jboss-4.0.0. It relies >> > on a modified version of axis-1.1. This stack should no longer be >> used. >> > >> > 2) JBoss now is pushing JBossWS, based seemingly largely - but not >> > entirely - on JAX-WS. Its spec support and completion status are here: >> > >> > http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossWSSpecStatus >> > >> > 3) Most importantly: "Any stack not listed above is *not supported*." >> > >> > So just to be clear: You can use Axis2 with EJB just fine as long as >> > you do not want to have the ServiceClass implement SessionBean - this >> > is at least true for JBoss. I think everyone agrees you can invoke an >> > EJB anywhere anytime in any container as any web layer class would. >> > >> > Now it would be interesting to try to implement the scenerio above >> > with JBoss and Axis2 since the sources are open. However, (A) It'd be >> > a labor of love and I just don't see feel it (B) JBoss is GPL and >> > axis2 is Apache licenesed of course, and (C) It'd be unsupported by >> > JBoss and even if it did work, the sanity of such a scenerio is >> > rightfully questioned by sanjiva and many others. >> > >> > Cheers, >> > Robert >> > http://www.braziloutsource.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ____________________________________________ Confidential: This electronic message and all contents contain information from Syntel, Inc. which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender immediately and destroy the original message and all copies. Confidential: This electronic message and all contents contain information from Syntel, Inc. which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have recieved this electronic message in error, please notify the sender immediately and destroy the original message and all copies. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
