450 likes | 538 Vues
Quontra Solutions is leading provider of IT career advice, Training and consulting services for IT Professional and corporates across USA. We train individuals or Corporate via online or class Room training in all IT tools and Technologies. We always strive to bring out innovative methods along with the traditional teaching techniques which enhance the overall experience of the students and teachers to extract the return on Investments, high efficiency and scalability. The company’s architecture is based on the insights from the marketplace, business analytics and strategies keeping intact the fundamental principles in mind, helps us to compete and win in today’s environment without changing any quality in training. The support, service and training provided by Quontra solutions for various customers assures a “stay up to date” easy transition from previous to current in terms of technology. Our advertisers and promoters are none other than the clients you have been associated with us for their training needs. We improve our training programs from the feedback from the students. Email Id : info@quontrasolutions.co.uk Website: http://www.quontrasolutions.co.uk
E N D
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Enterprise Java Beans An Overview of Enterprise Bean World info@quontrasolutions.co.uk
www.quontrasolutions.co.uk info@quontrasolutions.co.uk EJB Introduction • The EJB component are server-side components that encapsulate application behavior such as business logic and persistence code. • There are three types of EJB components: session beans, message-driven beans, and entities. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk • Session beans and message-driven beans are used to implement business logic in an EJB application, while entities are used for persistence. • EJB components reside inside the EJB container. • Together, the components, or EJBs, and the container can be viewed as a framework providing services. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB with Annotations • Metadata annotations are used to preconfigure the EJBs by specifying the type of services to add when the container deploys the EJBs. • Annotations are used to specify the type of the EJB component and to specify the services. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Layered architectures and EJB • In a layered architecture, components are grouped into tiers. • Each tier in the application has a well-defined purpose. • Each layer delegates the work to a layer underneath it. • EJB allows to build applications using two different layered architectures: the traditional four-tier architecture and domain-driven design (DDD). info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Traditional four-tier layered architecture
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Traditional four-tier layered architecture • The presentation layer is responsible for rendering the graphical user interface (GUI) and handling user input. • The presentation layer passes down each request for application functionality to the business logic layer. • The business logic layer is the heart of the application and contains workflow and processing logic. • It models the distinct actions or processes the application performs. • The business logic layer retrieves data from and saves data into the database by utilizing the persistence tier. • The persistence layer provides a high-level object-oriented (OO) abstraction over the database layer which typically consists of a relational database management system (RDBMS).
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Traditional four-tier layered architecture • EJB provides support for implementing the business logic and persistence layers. • Session beans and message-driven beans (MDBs) reside in and use the services in the business logic tier while entities reside in and use services in the persistence tier. • The traditional architecture undermines the OO ideal of modeling the business domain as objects that encapsulate both data and behavior. • It focuses on modeling business processes instead of the domain tending the business logic to look more like a database-driven procedural application than an OO one. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Domain-driven design (DDD) • DDD emphasizes that domain objects should contain business logic and should not just be a dumb replica of database records. • The domain objects are known as entities in EJB 3. • The entities defined by EJB 3 Java Persistence API (JPA) support OO features, such as inheritance or polymorphism. • Entities are used to model domain objects, including modeling state and behavior. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB3 Features • Ease of use: It doesn’t demand that to understand the theoretical intricacies. • Integrated solution stack: It offers seamless integration with other J2ee technolgies and a complete stack of server solutions, including persistence, messaging, lightweight scheduling, remoting, web services, dependency injection (DI), and interceptors. • Open Java EE standard: EJB 3 has an open, public API specification and is developed by the Java Community Process (JCP).
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB3 Features • Broad vendor support: EJB is supported by a large and diverse variety of independent organizations. • Stable, high-quality code base: a relatively stable code base that has lived through some of the most demanding enterprise environments. • Clustering, load balancing, and failover: EJB application servers have a proven track record of supporting some of the largest high-performance computing environments. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB Types • Each bean type serves a purpose and can use a specific subset of EJB services. • The purpose of bean types is to safeguard against overloading them with services that cross wires. • Session beans and message-driven beans (MDBs) live and managed by the container, and are used to build business logic. • Entities are used to model the persistence part of an application and persistence provider manages entities. • A persistence provider is pluggable within the container and is abstracted behind the Java Persistence API (JPA).
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB3 API Organization info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Session Beans • A session bean is invoked by a client to perform a specific business operation. • A session bean instance is available only for the duration of a “unit of work” and does not survive a server crash or shutdown. • There are two types of session beans: statefuland stateless. • A stateful session bean automatically saves bean state between client invocations. • A stateless session bean does not maintain any state and models the application services that can be completed in a single client invocation. • A session bean can be invoked either locally or remotely using Java RMI. • A stateless session bean can be exposed as a web service.
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Message-driven beans (MDB) • MDBs process the business logic. • Clients never invoke MDB methods directly. • MDBs are triggered by messages sent to a messaging server, which enables sending asynchronous messages between system components. • MDBs are typically used for robust system integration or asynchronous processing. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Entities • Entities are the Java objects that are persisted into the database. • Entities model lower-level application concepts that high-level business processes manipulate. • Entities are OO representations of the application data stored in the database and hence survives container crashes and shutdown. • JPA entities support OO capabilities, including relationships between entities, inheritance, and polymorphism. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk The EntityManager • The JPA EntityManager interface manages entities in terms of actually providing persistence services. • The EntityManager interface reads the ORM metadata for an entity and performs persistence operations. • The EntityManager knows how to add entities to the database, update stored entities, and delete and retrieve entities from the database. • JPA provides the ability to handle lifecycle management, performance tuning, caching, and transaction management. • JPA provides a specialized SQL-like query language called the Java Persistence Query Language (JPQL) to search for entities saved into the database.
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Java EE container with EJB info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB container & Persistence Provider • The EJB container: The EJB container transparently provides EJB component services such as transactions, security management, remoting, and web services support. • In EJB 3, the container provides services applicable to session beans and MDBs only. • The persistence provider: JPA provides persistence services such as retrieving, adding, modifying, and deleting JPA entities when you explicitly ask for them by invoking EntityManager API methods. info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB services
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Hello World in EJB3 • package ejb3inaction.example; • public interface HelloUser { • public void sayHello(String name); • } • package ejb3inaction.example; • import javax.ejb.Stateless; • @Stateless • public class HelloUserBean implements HelloUser { • public void sayHello(String name) { • System.out.println("Hello " + name + " welcome to EJB 3!"); • } • } info@quontrasolutions.co.uk
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Features of EJB3 • Simplified programming model: EJB 3 enables to develop an EJB component using POJOs and POJIs that know nothing about platform services. • Annotations instead of deployment descriptors: EJB 3 allows us to use metadata annotations to configure a component instead of using XML deployment descriptors • Dependency injection vs. JNDI lookup: JNDI lookups have been turned into simple configuration using metadata-based dependency injection (DI). E.g. @EJB annotation injects EJB into the annotated variable. • Unit-testable POJO components: EJB 3 components are POJOs, and can be easily be executed outside the container using testing frameworks such as JUnit or TestNG.
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Simplified persistence API • EJB 3 manipulates metadata-based POJOs through the EntityManager interface and avoids carrying burden of remote access. • Standardized persistence: EJB 3 solidifies automated persistence with JPA providing robust ORM configuration, JPQL standardizing divergent OR query technologies and EntityManager API standardizing ORM CRUD operations. • The cleanly separated Java Persistence API: JPA a cleanly separated API running outside EJB container. • Better persistence-tier OO support: EJB 3 entities have robust OO support as they are POJOs and JPA ORM mapping scheme is designed with OO, JPQL supporting OO as well.
info@quontrasolutions.co.uk www.quontrasolutions.co.uk EJB 3 Metadata Annotations • Annotations “attach” additional information (attributes) to a Java class, interface, method, or variable. • An annotation is a special kind of interface, it must be imported from where it is defined. • EJB 3 allows to override annotations with XML deployment descriptors where appropriate. • A deployment descriptor is simply an XML file that contains application configuration information. • Deployment descriptor entries override configuration values hard-coded using annotations into EJB components.
info@quontrasolutions.co.uk www.quontrasolutions.co.uk Common metadata annotations
Dependency Injection • Goal of dependency injection (DI) is to make component interdependencies as loosely coupled as possible. • One component calls another component or resource only through an interface. • The DI is JNDI lookup model reversed. • In previous JNDI lookup model, the bean explicitly retrieves the resources and components which are hard-coded in the bean. • In DI, the container reads the target bean configuration and gets the beans and resources needed by bean and injects them into the bean at runtime. • It lets the container deal with the complexities of service or resource instantiation, initialization, sequencing, and supplies the service or resource references to the clients as required.
Using Stateless Session Beans • Stateless session beans are used to model actions or processes that can be done in one shot. • @Stateless—The @Stateless annotation tells the EJB container that declared Bean is a stateless session bean. The container automatically provides such services to the bean as automatic concurrency control, thread safety, pooling, and transaction management. • @Local—The @Local annotation on the interface tells the container that the implementing EJB can be accessed locally through the interface. Alternatively, when marked with @Remote annotation, remote access through the @Remote annotation is provided under the hood by Java Remote Method Invocation (RMI).
Stateless session bean sample code • import javax.ejb.Stateless; • import ejb3inaction.example.persistence.Bid; • @Stateless • public class PlaceBidBean implements PlaceBid { • public PlaceBidBean() {} • public Bid addBid(Bid bid) { • System.out.println("Adding bid, bidder ID=" + bid.getBidderID() • + ", item ID=" + bid.getItemID() + ", bid amount=" • + bid.getBidAmount() + "."); • return save(bid); • } …. • } • ... • import javax.ejb.Local; • import ejb3inaction.example.persistence.Bid; • @Local • public interface PlaceBid { Bid addBid(Bid bid); }
Stateless Bean Client • public class PlaceBidServlet extends HttpServlet { • @EJB • private PlaceBidplaceBid; • public void service(….) { • Bid bid = new Bid(); • bid.setBidderID(bidderID); …….. • placeBid.addBid(bid); • } • } • When the servlet container sees the @EJB annotation as servlet is first loaded, it looks up the PlaceBid EJB behind the scenes and sets the placeBid variable to the retrieved EJB reference. • If necessary, the container will look up the EJB remotely over RMI by running the client in the application client container. • The application client container is a mini Java EE container that can be run from the command line
EJB 3 dependency injection Vs JNDI • The @EJB annotation makes the container “instantiate” the placeBid variable with the EJB named PlaceBid before the variable is available for use. • JNDI is the container registry that holds references to all container-managed resources such as EJBs. • Clients gain access to session beans like the PlaceBid EJB directly or indirectly through JNDI as follows: • Object ejbHome = new InitialContext().lookup("java:comp/env/PlaceBid"); • PlaceBidHomeplaceBidHome = (PlaceBidHome) • PortableRemoteObject.narrow(ejbHome, PlaceBidHome.class); • PlaceBidplaceBid = placeBidHome.create();
Using stateful beans • Stateful session beans guarantee that a client can expect to set the internal state of a bean and count on the state being maintained between any number of method calls. • The container ensures that a client can reach a bean dedicated to it across more than one method invocation. • The container ensures that bean instance variable values are maintained for the duration of a session without your having to write any session maintenance code. • In a stateful bean, the data the user enters at each step can be cached into bean variables until the workflow completes.
Statefulsession bean sample code • import javax.ejb.*; • @Stateful • public class PlaceOrderBean implements PlaceOrder { • private Long bidderID; • private List<Long> items; • private ShippingInfoshippingInfo; • private BillingInfobillingInfo; • public PlaceOrderBean () { items = new ArrayList<Long>(); } • public void setBidderID(Long bidderId) { this.bidderId = bidderId; } • public void addItem(Long itemId) { items.add(itemId); } • ….. • @Remove • public Long confirmOrder() { • Order order = new Order(); order.setBidderId(bidderId); • order.setItems(items); order.setShippingInfo(shippingInfo); • order.setBillingInfo(billingInfo); saveOrder(order); • billOrder(order); return order.getOrderId(); • }
Remove Annotation • The @Remove annotation marks the end of the workflow modeled by a stateful bean. • The container is told that there is no longer a need to maintain the bean’s session with the client after the confirmOrder method is invoked. • If the container is never told what method invocation marks the end of the workflow, the container could wait for a long time until it could safely time-out the session. • Since stateful beans are guaranteed to be dedicated to a client for the duration of a session, a lot of “orphaned” state data is consuming the precious server resources for long periods of time.
Beans producing JMS Message • @Stateful • public class PlaceOrderBean implements PlaceOrder { • @Resource(name="jms/QueueConnectionFactory") • private ConnectionFactoryconnectionFactory; • @Resource(name="jms/OrderBillingQueue") • private Destination billingQueue; • @Remove • public Long confirmOrder() { • Order order = new Order(); • order.setBidderId(bidderId); • order.setItems(items); • saveOrder(order); • billOrder(order); • return order.getOrderId(); • }
Beans producing JMS Message • private billOrder(Order order) { • try { • Connection connection = connectionFactory.createConnection(); • Session session = connection.createSession(false, • Session.AUTO_ACKNOWLEDGE); • MessageProducer producer = • session.createProducer(billingQueue); • ObjectMessage message = session.createObjectMessage(); • message.setObject(order); • producer.send(message); • producer.close(); • session.close(); • connection.close(); • } catch(Exception e){ e.printStackTrace(); }
Beans producing JMS Message • The @Resource annotation is much more general purpose and can be used to inject anything that the container knows about. • The name parameter values specify what resources are bound to the EJB’s environment naming context.
Message-Driven Beans • @MessageDriven( activationConfig = { • @ActivationConfigProperty( • propertyName="destinationName", • propertyValue="jms/OrderBillingQueue") } ) • public class OrderBillingMDB implements MessageListener { • public void onMessage(Message message) { • try { • ObjectMessageobjectMessage = (ObjectMessage) message; • Order order = (Order) objectMessage.getObject(); • try { • bill(order); notifyBillingSuccess(order); • order.setStatus(OrderStatus.COMPLETE); • } catch (BillingException be) { • notifyBillingFailure(be, order); • order.setStatus(OrderStatus.BILLING_FAILED); • } finally { update(order); } • } catch (Exception e) { e.printStackTrace(); } • }
Message-Driven Beans • MDBs are not guaranteed to maintain state. • The @MessageDriven annotation makes the container transparently provide messaging and other EJB services into a POJO. • The activation configuration properties nested inside the @MessageDriven annotation informs MDB about the JMS destination to receive messages. • MDBs implement the javax.jms.MessageListener interface which is used by container to invoke the MDB. • The onMessage method defined by the interface has a single javax.jms.Message parameter that the container uses to pass(forward) a received message to the MDB.
EJB3 using JPA • The JPA EntityManager interface defines the API for persistence while JPA entities specify how application data is mapped to a relational database. • The @Entity annotation signifies the fact that the Class is a JPA entity. • The @Table annotation tells JPA that the JPA entity is mapped to the corresponding SQL table • The @Column annotations indicate which Entity properties map to which SQL table fields. • The field mappings could have been placed directly onto member variables exposed through nonprivate access modifiers. • The @Id annotation marks the corresponding property as the primary key for the Bid entity. • The @GeneratedValue allows to automatically generate the primary key when the entity is saved into the database.
JPA Entity • @Entity • @Table(name="BIDS") • public class Bid implements Serializable { • private Long bidID; • private Long itemID; • @Id • @GeneratedValue(strategy=GenerationType.AUTO) • @Column(name="BID_ID") • public Long getBidID() { return bidID; } • public void setBidID(Long bidID) { this.bidID = bidID; } • @Column(name="ITEM_ID") • public Long getItemID() { return itemID; } • public void setItemID(Long itemID) { this.itemID = itemID; }
Using the EntityManager • The JPA EntityManager performs saving of the entity into the database by reading ORM configuration and providing entity persistence services through an API-based interface. • The manager reads the ORM mapping annotations like @Table and @Column on the entity and figures out how to save the entity into the database. • The EntityManager is injected into the PlaceBid bean through the @PersistenceContext annotation. • The unitName parameter of the @PersistenceContext annotation points to the persistence unit of application. • A persistence unit is a group of entities packaged together in an application module.
Using the EntityManager • The save method of EntityManagerpresists the data into the database issuing an SQL statement to insert a record in DB. • public class PlaceBidBean implements PlaceBid { • @PersistenceContext(unitName="actionBazaar") • private EntityManagerentityManager; • ….. • private Bid save(Bid bid) { • entityManager.persist(bid); • return bid; • } • }
info@quontrasolutions.co.uk www.quontrasolutions.co.uk For More Details Contact us Quontra Solutions Visit: http://www.quontrasolutions.co.uk/ Email: info@quontrasolutions.co.uk Call Now : 20-3734-1498 info@quontrasolutions.co.uk