1 / 96

EJB Overview

EJB Overview. What is EJB? EJB Roles EJB Architecture EJB Services Building an EJB Application EJB & CORBA Summary. EJB in the n-Tier System. You Are Here. Browser. Client Applet. Database. Client Application. Legacy Systems. EJB Server. Clients. Application. Data.

Télécharger la présentation

EJB Overview

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. EJB Overview • What is EJB? • EJB Roles • EJB Architecture • EJB Services • Building an EJB Application • EJB & CORBA • Summary

  2. EJB in the n-Tier System You Are Here Browser Client Applet Database Client Application Legacy Systems EJB Server Clients Application Data

  3. What is EJB? • Specification for component based distributed computing framework using Java technology. • Enterprise JavaBeans Specification describes • roles and responsibilities for component-based software development of server-side applications. • an architecture including EJB Servers, Containers, and Beans. • a set of services including naming, transactions and security. • interoperability with database servers and CORBA applications.

  4. EJB Roles Bean Provider - Producer of enterprise beans. - Combines enterprise beans into larger deployable parts. - Deploys enterprise beans into a specific operational environment. - Container provider and server provider. - Configuration and administration of infrastructure. Application Assembler Application Development and Deployment Deployer Platform Provider System Admin.

  5. EJB Architecture The container is the platform. The component is your application. Picture provided by Sun Microsystems, Inc.

  6. EJB Platform Provide naming service using JNDI Provide OMG/OTS compliant transaction service Container EJB Server Manage EJ Bean life cycle Make EJ Bean Interfaces Available with JNDI Provide basic security services Persistence Management (DBMS and other) Manage transaction context

  7. Select EJB complaint platform for purchase (1.0 or 1.1). EJB Platform vendors supplement standard EJB with proprietary features. Current Vendors include BEA Systems - WebLogic Bluestone - Sapphire/Web IBM - WebSphere Inprise - Application Server Oracle - Oracle8i Persistence - PowerTier Sun/Netscape alliance - reference implementation EJB Platform Vendors

  8. Enterprise JavaBeans™ Component EJB Application Application consists of multiple beans Beans are “portable” across containers Beans can be purchased or constructed

  9. Types of Enterprise JavaBeans • Session Bean • Used for client interface • Not shared between clients • Two kinds of Session Bean: • stateless - common object identity • stateful - unique object identity • Entity Bean • Maps to data in database or application • Shared between clients • Persistent state • container managed - access defined at deployment • bean managed - access defined as part of bean • Support optional in 1.0 and mandatory in 1.1

  10. Mixing Beans • EJB applications use a combination of entity beans and session beans to implement business logic. PrefixBean Database Client EchoServiceBean SuffixBean Session Bean Entity Bean Application Server Application Server

  11. EJB Client Interfaces Factory Interface Finder Interface EJBHome EJBObject Remote Interface Contains bean services seen by clients

  12. EJB Architecture The purchased EJB server is the platform. The application consists of session and entity beans. Application interfaces are made available to clients at time of deployment. Picture provided by Sun Microsystems, Inc.

  13. Deployment descriptor Deployment Platform Specific Implementation of Bean • Deployment provides a mechanism for adapting a component for a specific runtime environment. • Deployment is an intermediate step between coding a bean and executing a bean. By using a deployment descriptor, some attributes of the bean implementation are specified by the deployer, and implemented by the platform provider. • Two kinds of information in a deployment descriptor • Enterprise beans’ structural information - can’t change • Application assembly information - can change Bean Deploy +

  14. EJB Overview • What is EJB? • EJB Roles • EJB Architecture • EJB Services • Building an EJB Application • EJB & CORBA • Summary

  15. EJB Services • Standard EJB services allow application developers to • focus on business logic rather than infrastructure • defer responsibility for common services to the EJB platform • create “portable” applications that can be reused • support a component marketplace • Standard EJB services include • Persistence • Naming • Transactions • Security

  16. Persistence • EJB Definition • “The data access protocol for transferring the state of the entity between the enterprise bean instance and the underlying database is referred to as object persistence.” • Two types of persistence • bean-managed - persistence logic implemented directly inside the enterprise bean class. • container-managed - persistence logic delegated to container. • The underlying data source may be an existing application rather than a database.

  17. Bean-Managed Persistence • EntityBean • SQL code • persistence logic • Enterprise bean provider writes database access calls (using JDBC or SQLJ) directly in the entity bean. • Entity bean is tied to the data source in which the entity is stored. • More portable across EJB platforms than container-managed entity bean. Deploy • Bean • SQL code • persistence logic + Deployment Descriptor persistence-type

  18. Container-Managed Persistence EntityBean • Data access components (like JSBC and SQLJ calls) are generated at deployment time by container tool. • Entity bean is independent from the data source in which the entity is stored. • Less development effort for bean provider. Deploy + • Bean • generated SQL code • generated persistence logic Deployment Descriptor persistence-type cmp-fields

  19. Name Service - Deployment • Benefits • EJB server has built-in name server. • Service name of bean is assigned at deployment time, not compile time. • Some EJB servers support enterprise bean replication. Deploy Deployment Descriptor bean home name

  20. Name Service - Lookup • Benefits • JNDI allows clients to use one interface for locating CORBA, LDAP, NDS, and file objects. • Allows management of enterprise wide services using naming hierarchy. MyClient Context ct= getInitialContext(…) ct.lookup(“EchoService”) Runtime

  21. Transactions • Benefits • EJB applications can defer transaction logic to EJB server and container. • Distributed transactions. Picture provided by Sun Microsystems, Inc.

  22. Security • Benefits • Permissions specified for each bean service at deployment time. • Builds on security of JDK. Detailed discussion by Robert Seacord. Deploy Deployment Descriptor security roles ... • Generated Bean Code • security logic

  23. Building an EJB Application How do we build an EJB application? Client Database Application Server

  24. Step 1: Create Interfaces EJB Server Specifies the life cycle interfaces public interface AccountHome extends EJBHome{ public create(…) public findByPrimaryKey(..) Home I/F Client Database Specifies the interface provided to bean clients public interface Account extends EJBObject{ public getName(…) public setName(…) Remote I/F EJB specification This is generated You write this

  25. Step 2: Create Implementation EJB Server Home I/F Client Database Account implements EntityBean Implements bean interfaces public class AccountBean implements EntityBean { public void ejbActivate(...) {………} public void ejbPassivate(…) {……….} public getName(…) {……..} public setName(…) {…….. } Remote I/F EJB specification This is generated You write this

  26. Deployment descriptor Step 3: Deployment Descriptor EJB Server Home I/F Client Database Account implements EntityBean “Tells” the container how to deploy the bean (how to do DBMS access, transactions, security, naming, etc.) Remote I/F EJB specification This is generated You write this

  27. Deployment descriptor Step 4: Deploy EJB Server Home obj implements Home I/F Client Database Account implements EntityBean delegates Remote obj implements Remote I/F EJB specification This is generated You write this

  28. Entity Bean Inheritance - 1 Java.rmi.Remote Java.io.Serializable JDK EJBMetaData EnterpriseBean EJBObject EJB Spec EJBHome EntityBean Bean Provider (Wombat) Container Provider (Acme) Produced by Acme tools Extends or implements interface Extends implementation, code generation or delegation

  29. Entity Bean Inheritance - 2 Java.rmi.Remote Java.io.Serializable JDK EJBMetaData EnterpriseBean EJBObject EJB Spec EJBHome EntityBean Bean Provider (Wombat) AccountHome Account AccountBean Container Provider (Acme) Produced by Acme tools Extends or implements interface Extends implementation, code generation or delegation

  30. Entity Bean Inheritance - 3 Java.rmi.Remote Java.io.Serializable JDK EJBMetaData EnterpriseBean EJBObject EJB Spec EJBHome EntityBean Bean Provider (Wombat) AccountHome Account AccountBean AcmeRemote Container Provider (Acme) AcmeMetaData AcmeHome AcmeBean AcmeAccountHome AcmeRemoteAccount Produced by Acme tools AcmeAccountMetaData AcmeAccountBean Extends or implements interface Extends implementation, code generation or delegation

  31. EJB & CORBA • EJB and CORBA are complimentary standards. • EJB uses CORBA for • Enabling non-Java clients to access EJB applications. • Interoperability for EJB environments that include systems from multiple vendors. • EJB-to-CORBA mapping (separate specification) • Mapping of EJB interfaces to RMI-IIOP. • Propagating transaction context. • Propagating security context. • Interoperable naming service.

  32. Summary • The EJB architecture simplifies distributed application development by • providing pre-integrated solution framework • separating the business logic from distributed system services • providing standard services, including naming, transactions, and security • managing life cycle functions

  33. EJB Security Management

  34. Security Management Overview • The enterprise bean class provider should not hard-code security policies and mechanisms into the business methods • allows appropriate deployment for the operational environment of the enterprise • The application assembler may define • security roles for an application • semantic grouping of permissions • method permissions for each security role • permission to invoke a specified group of methods

  35. System Admins Application Assembler Bean Provider Deployer E J B Groups Security Management Overview - 2 Method Permissions Security Roles Users

  36. Bean Provider’s Responsibilities • The bean provider should not implement security mechanisms or security policies in the enterprise beans’ business methods • rely instead on the security mechanisms provided by the EJB Container • It is possible, however, to programmatically access a Caller’s Security Context...

  37. Programmatically Accessing a Caller’s Security Context • Two methods allow the bean provider to access security information about the enterprise • bean’s caller • getCallerPrincipal • isCallerInRole • In general, security management should be enforced by the container • the security API should is used infrequently

  38. Declaring Security Roles • Security roles are declared in the deployment descriptor • ... • <enterprise-beans> • <entity> • <ejb-name>WombatPayroll</ejb-name> • <ejb-class>com.wombat.PayrollBean</ejb-class> • <security-role-ref> • <description> • This security role should be assigned to the employees allowed to update employees’ salaries. • </description> • <role-name>payroll</role-name> • </security-role-ref> • </entity> • </enterprise-beans> • …

  39. Application Assembler’s Responsibilities • Define security roles in the deployment descriptor <security-role> <role-name> employee <description> allow employees to access their own data • Specify the methods of the remote and home interface that each security role is allowed to invoke <method-permission> <role-name> employee <ejb-name> WombatPayroll <method-name> getEmployeeInfo • Link declared security role references to security roles <role-link> payroll-department (add to bean description)

  40. Deployer’s Responsibilities • Ensures that an application is secure after it has been deployed in the operational environment • Assigns principals and/or groups of principals used for managing security in the operational environment to defined security roles • not specified in the EJB architecture! • specific to that operational environment • Can use the security view defined in the deployment descriptor merely as “hints”

  41. EJB Container Provider’s Responsibilities • The EJB container provider provides the implementation of the security infrastructure • A security domain can be implemented, managed, and administered by the EJB Server • e.g., the EJB Server may store X509 certificates • The EJB specification does not define the scope of the security domain • the scope may be defined by the boundaries of the application, EJB Server, operating system, network, or enterprise

  42. System Administrator’s Responsibilities • Typically responsible for • creating a new user account • adding a user to a user group • removing a user from a user group • removing or freezing a user account • Security domain administration is beyond the scope of the EJB specification...

  43. Proceed with Caution… EJB Server Vendor EJB Specification EIS Insecure Secure Threats

  44. Summary • The EJB architecture does not specify how an enterprise should implement its security architecture • assignment of security roles to the operational environment’s security concepts is specific to the operational environment • identification and authentication left to EJB Server vendor’s • Security will be vendor specific for some time • no plans to address problem in EJB 2.0

  45. EJB Transactions

  46. Distributed Transactions • EJB allows application developers to write applications that atomically update data in multiple databases • may be distributed across multiple sites • sites may use EJB Servers from different vendors • The enterprise Bean Provider and the client application programmer are not exposed to the complexity of distributed transactions.

  47. ACID Properties • Atomicity. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. • Consistency. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started. • Isolation. A transaction in process and not yet committed must remain isolated from any other transaction. • Durability. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state.

  48. Programmatic vs. Declarative Transaction Demarcation • Bean-managed transaction demarcation • enterprise bean code demarcates transactions using javax.transaction.UserTransaction • accesses between UserTransaction.begin and UserTransaction.commit calls are part of a transaction • Container-managed transaction demarcation • container demarcates transactions per instructions provided by the Application Assembler in the deployment descriptor

  49. Container-Managed Transaction Demarcation • NotSupported - container invokes enterprise Bean method with an unspecified transaction context • Required - container invokes enterprise Bean method with a valid transaction context • Supports • If the client calls with a transaction context, same as Required • If the client calls without a transaction context, same as NotSupported

  50. Container-Managed Transaction Demarcation - 2 • RequiresNew - container invokes enterprise Bean method with a new transaction context • Mandatory - container invokes enterprise Bean method with the client’s transaction context • Never - container invokes an enterprise Bean method without a transaction context • client is required to call without a transaction context

More Related