WLS10.x - Using a stateless EJB as WebService implementation - weblogic.developer.interest.webservices.general(Archived)

Hi all
instead as a POJO implementation I use an EJB as WebService implementation (taking advantage of the security and transactional features of EJB). It's a great thing and it works brilliantly as WebService. Now, I also have some RMI/T3s client which should also use the same service: I assumed that adding the #Remote annotation, would have made the EJB remotly available, but this is not the case: the EJB is not remotely available. Is it a bug or a feature?
ciao
carlo
P.S: to test it, simply change the "SimpleEjbImpl.java" class (under examples\webservices\jaxws\java2wsdl) adding the #Remote annotation. Some stuff is available in the JNDI tree of the hosting instance, but it is not remotely available as EJB :-( 

ok, I've got a potty example to run.
The problem now is, that as soon as the dataTypes used in the interface are no primitives, then I get an NotSerializableException, while the data types are not implementing java.io.Serializable... Any suggestion?

Related

DataControl: toplink mapping or ejb?

We started developing an application several months ago, using a DataControl over the TopLink mappings, without an EJB. Is there something wrong about that? Should we recode the app using an EJB DataControl? Or maybe it's not so important, and we can keep our old code?
Any advice?
Thanks in advance
RuBeck 
Hi RuBeck,
Using a Data Control over TopLink Mappings is fine as long as it suits your needs. Oracle recommends using a SessionBean as facade in front of you TopLink Mappings as the preferred architecture since it is the most flexible and extensible. If you find the basic CRUD operations provided by the TopLink Data Control are not sufficient, that would be a good time to consider migrating to the EJB DataControl and making use of a SessionBean facade.
In case you don't have them already, here is a link to Oracle's ADF development guide resources that cover in detail using a SessionBean facade and EJB Data Control along with your TopLink Mappings:
http://www.oracle.com/technology/obe/ADF_tutorial_1013/index.htm
Let me know if you need additional information.
Thanks,
John Bracken 
Hi John,
I'm working with Rubeck in the same project. We started working now with a Session Bean as a facade to TopLink. But we have already built many pages using the TopLink DataControl, and we would like to keep them, we don't want to recode them. I suppose we can have both the TopLink DataControl and the Session Bean DataControl (and probably more than one Session Bean DataControl) in the same application, but we want to be sure about that. Is there any problem in having different DataControl's in the same app?
Thanks in advance
Juan

JPA and Tomcat - Design Patterns

I plan on using Toplink/JPA with Tomcat without EJBs. I'm trying to determine the best way to handle the EntityManagerFactory and EntityManager objects. Should they be defined locally inside my servlet and passed to the beans themselves? Pooled by an object factory? Stored in session attributes? I'm new to JPA (as you can probably tell) and would appreciate any thoughts on this subject.
Thanks! 
I would recommend starting with the jpa-jsf example:
http://www.oracle.com/technology/products/ias/toplink/jpa/examples/jsf-jpa-example.html
It documents packaging and deployment in Tomcat.
Doug 
Thanks - that gave me a decent starting point.
In that approach they seem to 'cache' the entity manager factory and not the Entity Manager. I'm not using JSF so I think my approach would be different than the example.
I'll probably have 3 or 4 servlets each making calls to handles about 10 different entities. So from what I'm seeing I could create an application level attribute to store the EMF and then in the doPost/doGet of each servlet retrieve that attribute and call .createEntityManager() and pass that as neccessary. Does that make sense?

Getting Document in an  Entity EJB  via HTTP vs. Web Services

Dear developers and architects:
There is Entity Bean's persistenced via JDBC . Each of them has an attribute holding a document. This document can be accessed either via HTTP or Web Services (WS) on an other Application Server (AS) . There is some questions concerning architect:
1. Is it recommended / allowed to write the HTTP or WS client code within the EJB ? If not, what kind of design is recommended ?
2. If both AS's reside within an Intranet (DMZ), shoud be preferred the HTTP solution ?
I'm very thankful for any suggestion. 
I'm not sure I understand. Are some of the entity bean's fields in the database and another field is a document that is fetched via HTTP?
-- Rob
WLS Blog http://dev2dev.bea.com/blog/rwoollen/ 
Rob:
exactly. The entity bean represents a post item. All the fields are stored in the database, except the attachment. This is stored in an archive. This archiv can be accessed via HTTP or WebServices. The esaiest way will be to write the client code within the EJB. But I'm not sure, that it is o.k.
Laszlo 
I'd probably write the HTTP or WS client in a plain java class. That'll allow you to unit test it easily, and you can call it from your EJB or wherever you choose.
-- Rob
WLS Blog http://dev2dev.bea.com/blog/rwoollen/ 
As I take it it's not a good practice to write a client code within Entity EJB.
Use the Entity bean for the DB and a custom java class or control for the Archive and to encapsulate the logic use Session Bean (or JPF with Custom Control). But it’s in my opinion. Cheers!

switching between EJB andJavaBeans

Hi,
Im new to EJB. When designing my business objects, my first thought
was that really the business objects should be able to run in an EJB
container but also be available as Java Beans. This thought must
surely occur to other developers. It gets tricky as soon as you want
to swith from 'EJB calling EJB' to 'JavaBean calling JavaBean'. If
this is a not something you should hope to achieve and misses the
point etc etc ... then let me know!
If not ... maybe Im missing the obvious but I can't see an elogant way
of doing this. The main problem is that the EJB remote interface
methods throw RemoteException which clearly a JavaBean does not do, so
I cannot define an interface which the EJB remote interface extends
and the Java Bean implements, and then have a wrapper class which
makes calls on the interface (hence not caring whether the
implementation is a JavaBean or EJB). The only way I can see of doing
it is by having switch statements in my wrapper class to determine
whether in EJB or JB mode and then calling the remote interface or
javabean respectively, which doesn't seem like a good idea.
Can anyone recommend a way of doing this or is it something you just
dont do?
Dear Moo-Moo Podengopoppy ;)
The Business Delegate design pattern seems well-suited for this requirement
of yours.
http://developer.java.sun.com/developer/restricted/patterns/BusinessDelegate
.html
The Business Delegate pattern hides the implementation details (e.g. using
EJBs vs. using JavaBeans). You may then switch implementation and only the
Business Delegate object changes. It's a kind of Proxy or Adapter. In this
link you have all the details plus an example.
Emmanuel
"moo moo" <podengopoppy#hotmail.com> wrote in message
news:ec21589b.0204300736.300ef795#posting.google.com...
Hi,
Im new to EJB. When designing my business objects, my first thought
was that really the business objects should be able to run in an EJB
container but also be available as Java Beans. This thought must
surely occur to other developers. It gets tricky as soon as you want
to swith from 'EJB calling EJB' to 'JavaBean calling JavaBean'. If
this is a not something you should hope to achieve and misses the
point etc etc ... then let me know!
If not ... maybe Im missing the obvious but I can't see an elogant way
of doing this. The main problem is that the EJB remote interface
methods throw RemoteException which clearly a JavaBean does not do, so
I cannot define an interface which the EJB remote interface extends
and the Java Bean implements, and then have a wrapper class which
makes calls on the interface (hence not caring whether the
implementation is a JavaBean or EJB). The only way I can see of doing
it is by having switch statements in my wrapper class to determine
whether in EJB or JB mode and then calling the remote interface or
javabean respectively, which doesn't seem like a good idea.
Can anyone recommend a way of doing this or is it something you just
dont do?

Generic EJB - Advantage or Disadvantage?

Hello all,
I am currently developing a Generic EJB that Servlets would access only for Transaction management. All persistence logic is coded into individual JavaBean classes which implement a common interface exposing persistence methods for Insert, Update, Delete and Select. This generic EJB is always passed an object (JavaBean) that implements this common interface and all the EJB has to do is call the appropriate methods in the interface within its callback methods.
For eg: Lets say there is an interface:
Interface: CommonBean
Methods:
--insertData()
--updateData()
--deleteData()
--loadData()
EJB: GenericEJB
Methods:
--ejbCreate(CommonBean) //pass the JavaBean
calls CommonBean.insertData()
--ejbLoad()
Pk = ctx.getPrimaryKey()
calls CommonBean.loadData(Pk);
etc...etc...
This way I can use just one EJB and pass in Custom Persistence aware JavaBeans to this EJB.
I immediately see one advantage - my app. is EJB independent, tomorrow if it is decided not to use the EJB framework then I can do away with the EJB and use the individual JavaBeans to persist data.
Any thoughts anyone?
Regards,
Ashish. 
Hi,
If I am right the design pattern you have mentioned resembles to the Data Access Object (DAO).This technique has been specified in the EJB Blue print.
The advantage they have mentioned is that, it makes your EJB code cleaner, i.e., you delegate the JDBC logic to your bean.
However, in my opinion removing the Generic EJB logic will not help, because you would be losing out on the implicit Transactional services provided by the EJB container for the same.
If you happen to remove the EJB and only use Java Beans, you would need to code the transactional logic in the client (JSP/Servlets) or in the bean itself.You may use implicit RDBMS Transactional Management, but what will happen, if you have mutiple databases i.e. distributed databases? Also, another disadvantage is that it would make your Client coarse-grained.
Remember, the trend now-a-days is to keep the client as fine-grained as possible, and provide the coarse-grained feature in the middle-ware Application servers, as they are more suited for it.
Hope this helps
-- Sandeep
null

Categories

Resources