I was doing some reading up on building a soap service using jax-ws as part of java 6. I read that the operations that can be invoked by a client can be defined in the SEI, or Service Endpoint Interface. These operations can be implemented by a SIB, aka "Service Implementation Bean". The part that troubles me, is that this SIB "can either be a POJO or a Stateless Session EJB" according to page 4 of this book. The same definition applies on wikipedia. However, I read that a POJO (according to wikipedia) is "an ordinary Java Object, not a special object, which does not follow any of the major Java object models, conventions, or frameworks such as EJB". Thus follows my question, how can I know that my SIB is a POJO? Additionally, what is the difference between implementing my web service operations via a POJO or a stateless session EJB?
EJB 3.0 introduced annotations that allow any POJO to become a stateless session bean. Therefore the sentence "[a SIB] can either be a POJO or a Stateless Session EJB" applies to stateless session beans pre-EJB 3.0 (such as EJB 2.1). You can now write your SIB as a POJO - that is, without extending any other class or implementing any special interface that you didn't write yourself. You will still need an EJB container, though, such as WebLogic Server, IBM WAS or jBoss if you want to use EJBs.
In my point of view the biggest advantages for a ejb over POJO distrubution capacities of ejb there is plenty features exists for ejbs like CMP.
The other part any class you writed in java is a POJO in another words if your implemantion is a java class then it is a POJO.
POJO term came out for indicating that there is no need for special class type which is a need for java EE world because there is plenty special classes in java EE.
For one of advantages of ejb over POJO you can read this documentation: http://lass.cs.umass.edu/~shenoy/courses/spring11/lectures/Lec24.pdf
Related
I'm new to Java EE and got confused about EJB.
As I understand #remote EJBs are using RMI and JNDI for communication.
Before EJB3.0 beans needed to implement Remote interface through EJBHome interface - that way I understand how RMI was used.
But now I only need to put #remote annotation, which can be substituted by properties in ejb-jar.xml.
So, the question is: how is it possible to use JNDI without Serializible interface and RMI without Remote interface?
Please correct me if some of my assumptions are wrong.
EJB3 still uses RMI underneath except the application container will take care of generating and using RMI stubs and remote interfaces automatically for you and map them to your EJB3 classes.
You are still required to use Serializible in certain cases. See this:
Clustered Session Beans (SLSB & SFSB)
First of all, clustered EJB3
SLSBs or SFSBs do not need to implement Serializable. In fact, it's
recommended that they don't. In the case of clustered SLSBs, no state
replication occurs, so their instance variables do not even need to be
Serializable. With clustered SFSBs though, the same serialization
rules used for SFSB passivation apply to SFSB state replication. In
other words, all non-transient instance variables that are not
references to beans, sessions contexts or user transactions must be
serializable, or null at replication time. For further information on
the SFSB passivation (and by extension replication because in both
cases the SFSB bean context needs to be serialized), please check
section 4.2.1 of the EJB3 core specification.
Clustered Entity Beans
These only need to be marked Serializable if
the clustered entity instances are to be passed by value as a detached
object (e.g., through a remote interface). Otherwise, there's no need
to mark them as Serializable.
EJB uses RMI, but it's not exactly equal to RMI. The container generates classes and interfaces at runtime that conform to the RMI spec, and hide them from you. This is why in a EJB project your remote client usually needs to include in its classpath a bunch of libraries specific to the container.
In this regard, EJB 2.0 was more transparent to the fact that it uses RMI under the hood, and thus, more complicated.
Coming from plain old DI of Spring I can't figure out how to choose scopes properly while writing with CDI.
In Spring all my services have singleton scope by default, which I suppose maps to application scope in CDI (or even #Singleton). I know for e.g. logged in user information I need to use Session scope and for e.g. form params I need request scope.
Say I have a bean that hides external service API calls. It is completely stateless. Should I put it as #Singleton or simply application scoped? Or let it be created on every request (possibly bad option).
Is this correct to inject everything everywhere? In Spring I create my data objects by new. Should I do the same in CDI or simply #Inject them?
Are you only using CDI? or a Java EE 6 container? If you have a stateless class that is used for service calls, then I would recommend using #Stateless, which is from the EJB spec (so you would need a Java EE 6 container) It isn't a singleton, but it doesn't get created on each request either. I believe it is more closely bound to the session, but since it is stateless, instances can be pooled and shared. If you are only dealing with CDI, I believe Singleton matches more directly to Spring's singleton, but I would recommend using ApplicationScoped because it provides a proxy which makes serialization of beans that use it easier.
#Service
#Scope("prototype")
public class CustomerService
{
......
}
Just add #Scope("prototype") annotation to your component.
Is there a reason you would need the bean to remember it's state? If you are using something like a web client, that is a better place to store state in say, session scoped managed beans (assuming jsf), or whatever equivalent for your case. On the back end server side your EJB's would be better kept as #stateless to keep overhead to a minimum and help with the 'keep it simple s..." paradigm. And in case this works, just declare #Stateless on your bean. Unless there is a reason to use a singleton, again it is better to use a stateless bean if you want to go with a Java EE container for your services.
Stateless beans are not really being recreated with every request. That is the purpose of the pool. The app server keeps a ready supply of stateless beans on hand, and if it gets busy, it will make more, and if it quiets down, it will empty some out.
I am attempting to read method annotations in my web layer that are defined on classes in my EJB3 layer.
The object I am working with is a JPA defined entity on my EJB layer that is being fetched with a local ejb lookup to my client layer. When I attempt to read the annotations on the methods they are missing. It appears that all of the annotations are being stripped off of the objects that are being passed from the EJB layer to the Client layer.
The annotation I would like to read is not one of the EJB or JPA annotations but something to drive the processing of the class on the web tier.
If this is typical behavior of the servers then I can write the process differently, annotating the class was the simplest solution.
Thanks
-Scott
OK, the ease of EJB 3 tripped me up here.
In the client of an EJB app I am not looking at an instance of the Class from the EJB tier but a generated instance based on a generated interface from the EJB layer. Therefore the annotations defined on the EJB layer class are not present in the client layer of the application.
I read Beginning Java EE 6 platform with GlassFish 3 from Antonio Goncalves.
In chapter about EJBs he wrote that some features of EJB may be deprecated in next releases of Java EE.
None of the following features is actually removed from EJB 3.1, but
the next version will have to either remove or retain some of them:
JAX-RPC-based web service endpoints
But I not understand what he mean here. He wrote about classes annotated with #Stateless and #WebService? i.e.
#Stateless
#WebService
public class MyService {
}
So it is bad practice to annotate one class with this both annotations? It is better to separate classes? Create one to act only as EJB, and create another class to act only as as WebService (which delegates method invocation to EJB defined as class-member)?
Both #Stateless and #WebService are not part of JAX-RPC. They belong to EJB3 and JAX-WS. They will not be deprecated.
JAX-RPC 2.0 was renamed JAX-WS 2.0 in 2005.
I'm just getting started with JPA, creating stateless session beans from the JPA entities, then accessing the beans through a web service. While I have a lot of experience developing database backed web services "the old way", I have some questions about what's going on behind the scenes with this new "annotation driven approach".
What I see is, NetBeans sort of directs you to build applications in this manner though their wizards.
Create an Enterprise Application with EJB and Web Application modules.
Create Entity classes. I created mine from an existing database.
Create session beans from the entity class.
Create Web services from the session bean.
It all looks pretty simple, but what's going on behind the scenes? Specifically:
I see that the web service (created with the #WebService annotation) references my stateless session bean (using the #EJB reference).
What happens here? Does it just grab an instance of the EJB from the application server's EJB pool?
Nevermind. I was thinking of an instance where there was more than 1 table - meaning more than 1 type of Entity class and more than 1 type of EJB. I was looking at the web service and just seeing the #EJB reference and didn't understand who it was getting the bean type from that annotation. Just below that however, it the reference to the local bean interface - so that's that.
If there is more than 1 type of EJB deployed to the server, how does it know which one to grab?
The EJB is defined via the #Stateless and #Local annotations. The bean implementation references an EnityManager via the #PersistenceContext annotation.
Where is the jndi lookup to the database done (maybe in the persistence.xml file)?
Do all of the EJBs share a common EntityManager (assuming the EntityManager is thread safe)? If not, I know that the EnityManager utilizes a second level cache to help reduce trips to the database, are these caches somehow kept in sync?
I know this is a lot of questions, but they're all sort of related and there seem to be a lot of complicated concepts for something that's so easy to build through the wizards. I want to make sure I understand what's all going on here.
Thanks in advance!
What happens here? Does it just grab an instance of the EJB from the application server's EJB pool?
A JAX-WS web component endpoint (as opposed to a JAX-WS EJB endpoint) follows the typical servlet threading model, which means that typically there is one instance that is executed concurrently for each client. JAX-WS implementations are free to leverage pools of bean instances to handle a request in a fashion similar to stateless session EJB components. (source: Developing Applications for the JavaTM EE Platform FJ-310).
In all cases, it is fine to inject/look-up stateless beans because the container guarantees that the beans will always be thread safe. In affect, the container automatically serializes clients calls but uses instance pooling to make sure you still get concurrency benefits.
If there is more than 1 EJB deployed to the server, how does it know which one to grab?
Hmm... I didn't get this one. Can you clarify what you mean exactly? Why would there be any ambiguity?
Where is the jndi lookup to the database done (maybe in the persistence.xml file)?
In a Java EE environment, you specify your data source in a <jta-data-source> element in each persistence unit of the persistence.xml file (which can contain several persistence units) and the data source will be obtained by the EntityManager (only when needed, i.e. only if a data access is really needed).
Do all of the EJBs share a common EntityManager?
No. The EntityManager is a non-thread-safe object that should be used once, for a single business process, a single unit of work, and then discarded. In a Java EE environment using EJB 3, the default pattern is "entitymanager-per-request". A request from the client is send to the EJB 3 persistence layer, a new EntityManager is opened, and all database operations are executed in this unit of work. Once the work has been completed (and the response for the client has been prepared), the persistence context is flushed and closed, as well as the entity manager object. (source: Chapter 4. Transactions and Concurrency).