1 / 21

Enterprise Java Beans

Enterprise Java Beans. CS-422. Application Servers. In the late 1980s and though the mid 1990s a number of corporations (Broadvision, Netscape…) marketed a class of server products to enable the creation of highly scaleable applications.

psyche
Télécharger la présentation

Enterprise Java Beans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enterprise Java Beans CS-422

  2. Application Servers • In the late 1980s and though the mid 1990s a number of corporations (Broadvision, Netscape…) marketed a class of server products to enable the creation of highly scaleable applications. • Used proprietary interfaces to OLTP (On-line Transaction Processing) tools like BEA Tuxedo and IBM TXSeries • APIs are are not standardized • Applications developed on one application server were not portable to another application server • every application ended up being custom written • once one vendor‘s application server was installed, you were stuck with it and at the mercy of that vendor • vendor’s did a good job of convincing you how easy it was to use their product but were really trying to sell customization and consulting services

  3. WORA • Java’s “Write Once, Run Anywhere” philosophy allows Java applications to be written once and then run anywhere there is a JVM • Java 2 Enterprise Edition (J2EE) allows WORA to be applied to application server technology and server-side components to provide an application server that will allow application portability • Java 2 APIs are platform independent and vendor neutral • each API provides a common programming interface to a generic type of infrastructure service • Java 2 APIs have the goal of extending Microsoft’s ODBC philosophy a step further to include all infrastructure services

  4. J2EE Industry Acceptance • To be successful J2EE must have wide industry acceptance • APIs would be useless if infrastructure vendors don’t implement support for the J2EE APIs • Sun made alliances with many Industry leaders to insure the success of J2EE • Transaction Management • IBM, Compaq/Tandem, BEA Systems • Persistence Management • Oracle, Sybase, Informix • Directory Services • HP, Netscape, IBM

  5. J2EE APIs • Enterprise Java Bean (EJB) API • Java Naming and Directory Interface (JNDI) • Remote Method Invocation/Internet Inter-ORB Protocol • Java IDL • Servlets and JSP • Java Messaging Service (JMS) • Java Transaction Service JTS) • Java Transaction API (JTA) • Java Database Connectivity (JDBC)

  6. EJB API • The EJB API defines a server component model • provides portability across application servers • implements automatic services on behalf of the application components

  7. JNDI API • Provides access to naming and directory services • DNS, NDS, NIS+, LDAP, COS • used to look up interfaces used to create EJBs, JDBC connections and other things

  8. RMI/IIOP • Allows the creation of remote interfaces for distributed computing • default protocol (JRMP, Java Remote Method Protocol) is proprietary, based on Java’s serialization APIs • RMI-IIOP a JDK 1.3 extension of RMI that allows the use of IIOP (Internet Inter ORB Protocol) for RMI communication. J2EE Spec requires this as the standard protocol for communications between the different tiers of the J2EE architecture.

  9. Java IDL • Creates remote interfaces to support CORBA communications in the Java platform • includes IDL compiler and a lightweight ORB • allows the integration of non-Java based components

  10. Servlets and JSP • Used for creation of thin client interfaces for the presentation of information and collection of user inputs • Support the dynamic HTML generation and session management for browser based clients

  11. JMS • Used for asynchronous communication between distributed objects • Supports asynchronous communications through various messaging systems, such as reliable queueing and publish-and-subscribe services

  12. JTA • Provides a transaction demarcation API • provides the infrastructure for transaction management • open, committ, roll back • if the transaction spans multiple beans deployed on the same server or on widely dispersed servers, the server vendor is responsible for proper implementation od transaction control • transactions spanning multiple servers require the propigation of transaction context between servers over IIOP

  13. JTS API • Defines a distributed transaction management service based on CORBA’s Object Transaction Service

  14. JDBC • Provides uniform access to relational databases such as DB2, Oracle, SQL Server and Sybase • Provides provides interfaces to RDBMs both for data definition and query/insert/update/delete • latest version provides for database connection pooling

  15. Where we stand on J2EE... • In CS-328 we covered the following APIs: • JDBC • RMI • JavaIDL • HTTP and the Web • JNDI • In CS-422 we’ve covered: • Servlets and JSP • What’s left: • JMS (to be covered in CS-328) • JTA (some day) • JTS (some day) • EJB

  16. What is Enterprise Java Beans • Defines a model for the development and deployment of reusable Java server components • Components are pre-developed pieces of applications code that can be assembled into working application systems • The EJB Architecture logically extends the Java Beans component model to support server components • Server components run in an application server • A Java application server provides an optimized execution environment for server-side Java application components • by combining traditional OLTP (On-line Transaction Processing) technologies with a Java application server delivers a high performance, highly scalable, robust execution environment specifically suited to support Internet enabled application systems

  17. Containers • J2EE doesn’t specify how a J2EE runtime should be built, but instead provides an abstraction of the runtime infrastructure as a “container” • Component contract • Container Service APIs • Declaritive services • Other container services • The EJB Specification defines 4 types of containers: • an applet container to run applets • an application-client container for running standard Java application clients • a Web Container for hosting Java servlets and JSPs • an EJB Container for hosting Enterprise Java Beans

  18. RMI/IIOP RMI/IIOP JNDI JNDI JTA JTA JDBC JDBC JMS JMS JMS JDBC JavaMail JavaMail JAF JAF J2EE Container Architecture Web Container Applet Container EJB Container Java Servlets Applet EJBs JSP Pages Application Client Container J2EE Applicatiuon Server App.Client Databases and Other Resources

  19. The EJB Container • An EJB server must provide one or more EJB containers which provide homes for the enterprise beans • The EJB container manages the beans housed in it • responsible of registering the bean • providing a remote interface for it • creating and destroying object instances • checking security • coordinate distributed trancactions • can optionally manage persistent data within the object • any number of EJB claees can be installed in a particular conrainer but each class can only be assigned to a particular container

  20. EJB Container The EJB Object interface intercepts all method calls and implements transactions, state management, persistence,and security services for the bean based on deployment descriptor settings Deployment Descriptor EJB Object (Client view) Client Enterprise Bean EJB Home (bean identifier) Environment The EJB Home interface is accessible through JNDI and implements all lifecycle services for the bean.

  21. Transient and Persistent Objects • Session Beans (transient object) • session beans are created and exist usually for a single user session • performs operations on behalf of the client • may be transactional but are not usually recoverable after a system crash • can be stateless or can maintain conversational state across methods and transactions • container manages the conversational state of a session bean if it needs to be evicted from memory • must manage its own persistent data • Entity Bean (persistent object) • an object representation of persistent data that are maintained in a permanent data store (like a database) • a primary key identifies each instance of the entity bean • are transactional and are recoverable following a system crash

More Related