Great answer! Thank you very much... KJQ
-----Original Message----- From: [EMAIL PROTECTED] [mailto:Kevin.Bedell@;sunlife.com] Sent: Monday, October 21, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: RE: Q: Best Practices w/n Using Axis? What you've done, I think, is identify an appropriate method of building a Web Service using an EJB. Were I required to use EJB's for some reason, or if I thought the EJB's could be reused by local code (non-distributed code that was in the same J2EE container), then I would likely follow your approach. If having the EJB's added no additional value, then I would consider not using them. - Given that HTTP isn't a good protocol for managing transactions, I'm not sure if the transaction management pieces of EJB's would help you. They may, actually, help you roll-back partial changes or garbage that may result from an aborted HTTP request. I think this would be worth evaluating when making the decision. - You can probably use any resource pooling your container provides just as easily from classes in your web container, so there's little advantage there. I'd say if the transactional support of EJB's added no value, there was little chance of reuse and you had to build a lot of this by hand - then it's probably easier, faster (and therefore better) to use regular classes in your web container. "Quinn, Kim John" <[EMAIL PROTECTED]> on 10/21/2002 10:58:13 AM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Q: Best Practices w/n Using Axis? Hmm, well that is a nice feature of WebLogic but in a more general sense, let's say I dont have any tools and would like to generate WebServices that are less dependent on the AppServer would the following be a correct approach: 1) Develop the beans as needed (Session using EntityBeans) 2) Develop a Stateless session to proxy to the Session (if even needed) 3) Develop a WebService set that basically proxies to either the Stateless or the Stateful Session. 4) Interact as a true client to either the WebService (via something like .NET) or use the Beans as a true Java app. In #3, i would pretty much use the WebService similar to a EJB client, have it find the home and the bean and then delegate the operation as needed. I'm wondering though if this itself might be overkill or not? Does is make sense to use WebServices as wrapper or "clients" to the AppServer at all because all i would really be doing is wrapping the bean in it... One thing to note, is this would decouple me from using the EJBProvider and building my WebServices using a straight-forward approach which I assume will be easier for me to integrate with a variety of AppServers in the long run. Thanks. KJQ -----Original Message----- From: [EMAIL PROTECTED] [mailto:Kevin.Bedell@;sunlife.com] Sent: Monday, October 21, 2002 10:50 AM To: [EMAIL PROTECTED] Subject: RE: Q: Best Practices w/n Using Axis? If you're using weblogic then probably most of your work is building EJB's anyway, so it's not that big a deal. Especially given all the work it does for you if you follow their model. Creating an SSB then passing everything to the Ant task actually takes less time then other platforms. It handles deployment of the service as well. Downside is the types are pretty limited - we send DOM objects only. Everything we use via weblogic is embedded in an XML document. Also, client code needs to get an initial context from the WebLogic server and us some sort of a factory class to access the web service - meaning the client code (Java at least) is pretty dependent on WebLogic. It's posible to use other client code if you want to. It's just easier to use their stuff. The real value is that you just create the SSB and their build process takes care of everything else. "Volkmann, Mark" <[EMAIL PROTECTED]> on 10/21/2002 10:37:43 AM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Q: Best Practices w/n Using Axis? Isn't this approach overkill for many web services? What's the point in involving session beans in the picture if the capabilities they add beyond normal Java classes are not needed by a particular web service? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:Kevin.Bedell@;sunlife.com] > Sent: Monday, October 21, 2002 9:23 AM > To: [EMAIL PROTECTED] > Subject: Re: Q: Best Practices w/n Using Axis? > > This is how Weblogic works. BEA has chosen this approach for > making web > services available. > > With WebLogic you crete a stateless session bean and there is > an Ant task > (WSGEN) that inspects your session bean and then automatically creates > code, descriptors, etc plus a web applicaiton that acts as > ain interface to > it. It outputs an ear file. > > I'd recommend this as a good solution. > > Kevin > > > > > > > > "Quinn, Kim John" <[EMAIL PROTECTED]> on 10/19/2002 11:32:26 AM > > Please respond to [EMAIL PROTECTED] > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > Subject: Q: Best Practices w/n Using Axis? > > > Hello all, > > Been using Axis now for a bit and really find it to work > great. Now as I > start to really implement it I have a few questions about > best practices > when using it, specifically when using it with EntityBeans or > Sessions of > J2EE. > > What I have been doing is creating my beans as normal in J2EE > then building > a webservice that acts as a proxy to the bean as opposed to using the > EJBProvider itself. Is this an acceptable way of building a > webservice > that > needs to attach to a enterprise object? > > Any insight would be appreciated... > > Thanks. > > KJQ > > > > > > > -------------------------------------------------------------- > ------------- > This e-mail message (including attachments, if any) is > intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential > and exempt from > disclosure. If you are not the intended recipient, you are > notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication > in error, > please notify the sender and erase this e-mail message immediately. > -------------------------------------------------------------- > ------------- > > **************************************************************************** ******* WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. **************************************************************************** ******** --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --------------------------------------------------------------------------- --------------------------------------------------------------------------- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. ---------------------------------------------------------------------------
