Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Enterprise JavaBeans 3.0 What is EJB 3.0 -Reusable server-side component framework-technology -Designed to support building demanding enterprise – level solutions -EJB –standard defines many commonplace infrastructure services (a.k.a. Quality of Services, QOS ) -QOS’s are rendered to components hosted by Application Server (AS) -AS also provides running environment for EJB’s (along with QOS’s) -Frees application developers from re-inventing the wheel (in buggy way) and from many system level programming challenges, eg. Threading. Other Java EE – teknologies and EJB • Sun renamed J2EE to Java EE from version 5.0 (also J2SE -> Java SE from version 6.0) • EJB uses a lot of other existing Java teknologies • Most importants: JNDI, RMI, JMS, JTA, JDBC, Java persistence, JAAS How EJB works Picture 1 : Calling EJB Picture 2 : Various beans and clients Copyright Sriganesh, Brose, Silverman in Mastering EJB 3.0 Different EJB 3.0 bean types • Stateless bean is default choice always when program does not need to remember the state of the client conversation. • All info into stateless bean via parameters (or bean retrieves info eg. from DB) • Stateless bean example : Credit card verification component or video stream compressor engine • Statefull when program needs to remember the state of client conversation. • Eg. Web-bank or web-shop Different types of EJB 3.0 • Message-Driven Bean supports MOM –concept by taking advantage of JMS -standard • Entities are not Beans, but are replacing the former EntityBeans in 3.0 –standard • Other beans can use entities freely to get persistence services RelationShip of AppServer, Services and Beans Persistence • EJB 3.0 uses new persistence concept : entities • 3.0 also supports EntityBeans defined in previous EJB -standard version • Main motivation for new concept was performance issues with EntityBeans • Entities are defined in Java SE unifying persistence interfaces and programming • Java Persistence is based on Plain Old Java Objects (POJO) Transactions • Transaction support is key part of EJB • Programmer may choose (as with many services) explicit or implicit (declarative) transactions • EJB’s can also be part of client-controlled transaction • Support is based on Java Transaction Api (JTA) Security • Security support is another key part of EJB • Programmer may choose (as with many services) explicit or implicit (declarative) security • Support is based on Java Authentication and Authorization Service (JAAS) • Place for security–info may vary, eg. DB, files, specific third-party software • To protect data during transfer uses other standards, eg. SSL/TSL Timer service • Timer service may be used to automate clean up tasks • Bean may run any kind of code when called back by timer service • Not applicable for real-time operations • Statefull beans and entities cannot register into service Messaging service • Message-Driven Beans uses JMS –standard to support MOM –concept • JMS defines two interfaces : message-interface and messaging provider -interface • Bean Container will call MDB when message arrives • Supports both messaging –styles : point-to-point and puslish/subscribe Java EE Connector Architecture • Service to connect into legacy systems in a standard way • Defines many interfaces that programmer may / may not implement • Requires a specific resource –adapter for legacy system that implements the interfaces • Supports eg, incoming/outgoing transactions, security, threading,… Clustering • EJB –standard does not define clustering -service but every major Application Server implements it some way • Lack of standard leads into vendor-specific solutions • Typical solution is to use ”smart stubs” which requires vendor specific compiling tools and couples the code into vendor • Clustering is a common solution to get better performing and more robust service Conclusion • EJB is a good choice when • • • • • • Remoting is required Distributed transactions are required Security is required Persistence is required Integration with legacy apps is required Scalability is required Otherwise EJB may be overkill