Middleware Technology (Part VIII, Enterprise Java Middleware Technology (Part VIII, Enterprise Java

download Middleware Technology (Part VIII, Enterprise Java Middleware Technology (Part VIII, Enterprise Java

of 16

  • date post

    14-Jul-2020
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of Middleware Technology (Part VIII, Enterprise Java Middleware Technology (Part VIII, Enterprise Java

  • Middleware Technology (Part VIII, Enterprise Java

    Beans) Andrei Popovici

    Information and Communication Systems Research Group

    Department of Computer Science ETH Zürich

    popovici@inf.ethz.ch http://www.inf.ethz.ch/department/IS/iks/

  • 2A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    Outline

    ο EJB fundamentals: beans and containers ο Containers ο Beans

    • session beans • entity beans

    ο Example ο EJB Internals:

    ⇒ Persistence ⇒ Pooling ⇒ Transactions

    ο Conclusions and Outlook

  • 3A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    The EJB Component Model Ahead towards the ideal middleware system:

    ο portability ⇒ Java ⇒ components: pure application logic

    ο Interoperability ⇒ components have hooks to cooperate with the

    environment (container) • EJB API and coding conventions

    ο Integration ⇒ Naming services ⇒ Data Persistence ⇒ Transactions ⇒ Authentication & Authorization

  • 4A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    EJB: Beans and Containers Two main concepts dominate the EJB paradigm: ο Beans: fit together in a standard way

    ⇒ contain pure application logic and hooks

    ο Containers = middleware ο know how to communicate with the

    beans and with the clients ο know how to create and destroy

    beans ο implement services developers don’t

    want to worry about ο all messages go through the

    container

    CONTAINER

    clients

    Java Virtual Machine

    CONTAINER

  • 5A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    Containers ο A bean container is the server

    application on which the bean code runs. ⇒ container vendors: IBM,

    SUN, Oracle ο The container interposes itself

    between the client and the bean. Server Host

    ο Before a bean is able to live in a container, it has to be adapted to a specific container. This process is called deployment.

    ο Deployment is vendor specific... The client triggers the creation of beans inside the container,

    but does not directly access the methods of the beans it has created. Instead, the container exports a remote interface to the client.

  • 6A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    EJB: The Big Picture

    client

    = the XML-formatted file created by the deployer in which the type of the bean, its name, etc.. are specified Deployment

    descriptor

    CONTAINER

    deploy bean

    JNDI: ejb/beans/myBeanH = bean code (app.logic)

    Deployment descriptor

    = bean home, generated by the deployer, published as jndi:ejb/beans/myBeanH

    Step 1: install bean

    (create Bean)ask home for bean instance

    use bean

    Step 2: use bean

  • 7A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    Beans and Clients ο Beans are (independent) business objects. Some examples:

    ⇒ The small software piece behind a web site counter ⇒ A currency converter ⇒ A shopping cart in a web store may be implemented by a

    bean. The items inside may be other beans. ο Scenarios:

    ⇒ The bean is not influenced by what the client did before (e.g., currency converter)

    • Stateless session bean ⇒ The bean is influenced by what the client did (e.g.,

    shopping cart) • Stateful session bean

    ⇒ The bean has to survive a server crash (e.g., web site counter)

    • Stateful, entity bean. All entity beans are stateful.

  • 8A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    Bean Types ο Session Beans

    ⇒ are used by one client at a time ⇒ are lost in a server crash ⇒ Stateless: look the same to the client before and after the

    operation ⇒ Stateful: persistence

    ο Entity Beans ⇒ are the core business objects ⇒ represent shared data in a database ⇒ allow shared access from multiple clients ⇒ survive a server crash

  • 9A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    Example: Web Counter

    Web server = client role

    Page request

    container

    ο Developer:

    EJBObject

    Counter

    EntityBean

    CounterBeanCounterHome

    EJBHome

    int click() create() ejbCreate() int click()

    ο Deployer: ejb/beans/myBeanH CounterHome ...

    (1) Counter.xml:

    (2) bash$ deployejb counter.xml container

    ο Java client (code running in the web server):

    counterHome=ctx.lookup(“jndi:ejb/beans/myBeanH”); Counter c = counterHome.create();

    app. logic

    utility

    ctx: JNDI Context

  • 10A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    EJB and Persistence (1) ο Session beans have to use JDBC. Fortunately, beans do not

    have to bother with the JDBC driver setup, which is the main portability problem in Java applications which access a database. Instead, the database (data source) is published in the JNDI naming service. The beans just specify the SQL command for retrieving the data from a database: ⇒ Example stateless session bean:

    ⇒ Example stateful session bean:

    ejbCreate() { /* ask container for data source*/} ejbRemove() { /* tell container we’re finished */ }

    ejbCreate() {..} ejbRemove() {..} ejbActivate() { /* similar to ejbCreate */ } ejbPassivate() { /* similar to ejbRemove */}

    (code from CounterBean.java)

    (code from CounterBean.java)

  • 11A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    EJB and Persistence (2) ο Entity beans usually correspond to a record in a relational database.

    Therefore, it has a unique identifier which survives over time and over client accesses: the primary key (PK). The bean developer must create a special PK Java class.

    ο Clients get references to entity beans by specifying the PK ο The persistence of an entity bean may be:

    ⇒ bean managed (like in session beans, using JDBC). In this case, the bean developer has to provide the proper code for storing and retrieving the state of the bean (ejbLoad, ejbStore)

    ⇒ container managed: the container automatically stores in the database all attributes of an entity bean instance. Container managed persistence makes life easier (no SQL statements) for the developer. The developer still has to implement some special methods.

    ο What kind of persistence mechanisms the bean uses is specified in the deployment descriptor:

    container

  • 12A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    EJB and Pooling ο If a container has many clients, it cannot afford to keep all

    beans associated to the clients in the main memory. Therefore ⇒ it reuses the stateless session beans living in the

    container ⇒ it temporarily stores the data of a stateful session bean in

    persistent storage (activation and passivation) ο As a consequence, the developer of a bean has to implement

    methods like ejbActivate, ejbPassivate, ejbCreate, ejbRemove to react to the container’s decision about a bean.

    ο On the other hand, the container has to consistently call these methods every time it creates, destroys, or stores a bean.

  • 13A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    EJB and Transactions ο A business method implemented by a bean (e.g.

    ‘doReservation(hotel,flight)’ has to be executed atomically, like a transaction

    ο The deployer can specify this in the deployment descriptor,like this:

    ο The transaction management in EJB is based the JTA (Java Transaction API) ο The transaction management (like persistence) may be

    ⇒ implicit - container uses JTA, developer writes pure application logic

    ⇒ explicit - developer writes JTA and JDBC code

    doReservation required

  • 14A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    Practical Considerations ο Shall I choose Corba or EJB?

    ⇒ Corba provides at least the same services as EJB. ⇒ EJB application is easier to write and deploy. ⇒ The EJB framework is complex.

    ο Which container vendor shall I choose? ⇒ Sun’s specifications are ahead of the vendor’s

    implementation. ο Current trend: everybody is reshaping their applications

    towards EJB ο World Wide Web: Java Server Pages (JSP) or Servlets work

    well together with EJB ο Performance: Java is still slower its counterparts for WWW

    ⇒ however, EJB provides good scalability.

  • 15A. Popovici. Information and Communication Systems Research Group. ETH Zürich. Part VIII - EJB

    Conclusions and Outlook ο Enterprise Java Beans are easy to write ο But the EJB architecture is complex and is closely tied to

    other Java packages and specifications, like JNDI, JDBC, JTA or RMI. A bean developer will have to understand them as well.

    ο By separating deploy