SE 690 Research Seminar Enterprise JavaBeans

1

• SE 690 Research SeminarEnterprise
  JavaBeansEnterprise JavaBeans Query
  LanguageNafis PatelWinter 2001

2
Scope

• Scope of this report is to discuss Enterprise
  JavaBeans specifications 2.0 (draft)
• Entity Beans with Container Managed Persistence
• Changes in the specifications over previous
  release

3
Scope

• Scope (Cont)
• Enterprise JavaBeans Query Language (EJB QL)
• Commercial implementation of EJB QL

4
Organization
5
Software Components

• Software components are individual pieces of
  software which implements well defined set of
  interfaces. They are not application in
  themselves but they are different pieces which
  combine to make large application.

6
Enterprise JavaBeans

• Enterprise JavaBeans (EJB) is a server side
  component architecture that simplifies the
  development of enterprise class distributed
  applications in java.
• It allows developers to write scalable and
  reliable server side business logic components
  without worrying about the system level services
  like threading, persistence and transaction
  security.

7
Enterprise JavaBeans

• There are seven roles in EJB as defined by
  specifications
• Enterprise Bean Provider
• Application Assembler
• Deployer
• EJB Server Provider
• EJB Container Provider
• Persistence Manager Provider
• System Administrator

8
Enterprise JavaBeans

• The essential characteristics of EJB is as
  follows
• An enterprise bean typically contains business
  logic that operates on the enterprises data.
• An enterprise beans instances are created and
  managed at runtime by a Container.
• An enterprise bean can be customized at
  deployment time by editing its environment
  entries.

9
Enterprise JavaBeans

• The essential characteristics (Cont)
• Various services information, such as a
  transaction and security attributes, are separate
  from the enterprise bean class. This allows the
  services information to be managed by tools
  during application assembly and deployment.
• Client access is mediated by the Container in
  which the enterprise Bean is deployed.

10
Enterprise JavaBeans

• The essential characteristics (Cont)
• If an enterprise Bean uses only the services
  defined by the EJB specification, the enterprise
  bean can be deployed in any compliant EJB
  Container. Specialized containers can provide
  additional services beyond those defined by the
  EJB specification. An enterprise Bean that
  depends on such a service can be deployed only in
  a container that supports that service.

11
Enterprise JavaBeans

• There are three kinds of beans defined in the
  specifications
• Session Beans
• Entity Beans
• Message Driven Beans

12
Session Beans

• Session bean represents the method and process
  that is being performed for the client.
• They are business process objects which
  implements business logic, rules and work flow.
  They do not represent anything in the database
  although they may have some side effects in the
  database.
• They execute on behalf of single client.
• The lifespan is short.
• In event of container crash client has to
  reestablish the sessions object.

13
Session Beans

• There are two kinds of Session beans defined in
  the architecture
• Stateful Session bean
• Stateless Session bean

14
Message Driven Beans

• This is a new type of bean introduced in
  specifications 2.0 to handle incoming JMS
  messages.
• They execute on receipt of a single client
  message.
• They do not represent directly shared data in the
  database, although it may access and update such
  data.
• They are relatively short-lived and are
  stateless.
• They are removed when the EJB Container crashes.
  The container has to re-establish a new message
  driven object to continue computation.

15
Entity Beans

• Entity bean represents persistent data.
• Entity beans are business process components that
  manipulate data. They necessarily do not contain
  business process logic.
• Traditionally applications read and write data to
  the tables in database. Entity beans are object
  representation of this underlying data.
• They allow shared access from multiple clients.

16
Entity Beans

• Entity Beans(Cont)
• They enjoy long life cycle.
• The entity, its primary key, and its remote
  reference survive the crash of the EJB Container.
  If the state of an entity was being updated by a
  transaction at the time the container crashed,
  the entitys state is automatically reset to the
  state of the last committed transaction.

17
Entity Beans

• There are two types of Entity Beans
• Entity bean with Bean Managed Persistence (BMP).
• Entity bean with Container Managed Persistence
  (CMP).

18
Entity Beans with BMP

• In Entity bean with BMP, the code for persistence
  management is responsibility of bean developer.
• It gives the flexibility of how the beans state
  is maintained between bean instance and the
  database.
• When entity beans are required to work on
  different databases or legacy systems BMP is more
  useful.

19
Entity Beans with BMP

• There are some disadvantages in using Entity bean
  with BMP
• More work is required to define the bean.
• Bean developer has to understand structure of the
  database and will have to explicitly write
  database logic.
• It ties bean to the particular database. Any
  change in the database would require some changes
  in the beans code.

20
Pause
21
Remote Interface
22
Home Interface
23
Bean Class
24
Primary Key Class
25
Entity Beans with CMP

• With CMP, container manages beans persistence.
• Vendor supplies tools to map the beans
  persistence fields to database and no database
  logic is required inside the code.
• Container provider has to take care of all
  persistence needs of the entity bean.

26
Entity Beans with CMP

• In the current CMP model specified in
  specifications 1.1, there is no efficient way to
  persist Serializable dependent objects. Most
  often they are persisted as binary type.
• This problem becomes complex when there are more
  than one dependable objects, they cross reference
  each other and they represent more than one table
  in the database.

27
Entity Beans with CMP

• In the specifications 2.0, persistence is handled
  for entity beans with CMP by Persistence Manager.
• The entity Bean Provider must specify in the
  deployment descriptor those persistent fields and
  relationships for which the Persistence Manager
  Providers tools must generate data access calls.
  The Persistence Manager Providers tools are then
  used at the entity beans deployment time to
  generate the necessary database access calls.

28
Entity Beans with CMP

• This idea is introduced to separate container
  from Persistence Manager.
• There is a contract between the bean and
  Persistence manager which is manifested in the
  new abstract persistence schema.
• The schema is defined through a new set of XML
  elements in descriptor and set of code idioms in
  the CMP entity beans.
• Example

29
Entity Beans with CMP

• The CMP bean class is declared as an abstract and
  persistence fields and relationships fields are
  accessed using abstract accessor and mutator
  methods whose method signatures map to special
  elements in the XML deployment descriptor.
• At the deployment time, persistence manager tools
  will be used to implement the abstract classes.
  This will include the data access code.
• At runtime, container will use the subclasses
  generated by the persistence manager tools.

30
Entity Beans with CMP
31
Entity Beans with CMP

• The CMP entity bean classes and their dependent
  object classes follow the same abstract
  persistent schema
• Which means dependent object classes are also
  declared abstract and have same method idioms as
  in the entity bean class.
• Dependent object class are very tightly
  associated with entity bean class. Since they are
  not used in the method parameters of remote
  interface, client does not know anything about
  it.

32
Entity Beans with CMP

• Dependent object classes has same life cycle as
  the entity they are associated with. If the
  entity bean is removed then dependent is also
  removed from the database as in the cascading
  delete.
• Entity bean may have one-to-one, one-to-many or
  many-to-many relationship with the dependent
  object class.
• Dependent object classes are specified in
  deployment descriptor in ltdependentsgt element.
• As in the ltrelationshipsgtltejb-relationship-rolegt

33
EJB QL

• EJB specifications 1.1
• The home interface of the bean contains the
  find methods which are used to query EJB server
  for specific entity bean.
• These find methods are implemented by the
  container. Bean developer would specify in the
  descriptor how the particular find method
  should be executed.
• There is no standard query language defined for
  these methods.

34
EJB QL

• EJB specifications 2.0
• The home interface of the bean contains the
  find methods which are used to query EJB server
  for specific entity bean.
• These find methods are implemented by the
  persistence manager. Bean developer would specify
  in the descriptor how the particular find
  method should be executed.
• There is a standard query language defined for
  these methods.

35
EJB QL

• The Enterprise JavaBeans query language, EJB QL,
  is used to define queries for entity beans with
  container managed persistence. EJB QL lets the
  Bean Provider specify the semantics of query
  methods in a portable way.
• It is intended to be compiled to the target
  language of persistence data storage.
• It is based on the subset of SQL.

36
EJB QL

• The EJB QL uses the abstract persistence schemas
  of entity beans and dependent object classes,
  including their relationships, for its data
  model.
• Bean developer will use abstract persistence
  schema to write queries in EJB QL. It will use
  cmr-fields for the selection and navigation of
  the dependent object classes or other dependent
  beans. Bean developer can use the abstract schema
  type of other beans if they are declared in same
  deployment descriptor.

37
EJB QL

• EJB QL is intended to be used in two different
  ways.
• Queries for find methods -
• Queries for select methods
• For each type of above query, syntax differs
  slightly.

38
EJB QL

• EJB QL definition
• An EJB QL query is a string which may consist of
  the following three clauses
• a SELECT clause, which indicates the types of the
  objects or values to be selected.
• a FROM clause, which provides navigation
  declarations that designate the domain to which
  the conditional expression specified in the WHERE
  clause of the query applies.
• a WHERE clause, which restricts the results that
  are returned by the query.

39
EJB QL

• EJB QL definition (Cont)
• In BNF syntax, an EJB QL query is defined as
• EJB QL select_clause from_clause
  where_clause
• The constructs in are optional. FROM clause is
  always required for all the methods. SELECT
  clause is always required for the select
  methods.
• EJB QL are defined in ltejb-qlgt element of
  descriptor

40
EJB QL

• EJB QL definition (Cont)
• EJB QL is a typed expression language. Each query
  evaluates to the type.
• The type is based on the various factors like
• Abstract schema types of variables
• Relationship defined in the cmr-field
• cmp-field
• Type of expression and
• Type of literals

41
EJB QL

• EJB QL definition (Cont)
• find methods must return either remote object
  or collection of remote object representing the
  entity beans so they may not require the SELECT
  clause in the query.
• select methods are not exposed to the clients
  as they are intended to be used by entity object
  or dependent object class therefore there must be
  SELECT clause in the query for these methods.

42
EJB QL

• EJB QL queries uses abstract schema type entity
  beans that are local and remote types of the
  entity beans that are remote.
• There are recommendations for the Naming
  convention for the entity beans.
• ltnamegtEJB entity bean as a whole
• ltnamegtBean implementation class and
  abstract persistence schema

43
EJB QL

• FROM Clause
• FROM clause is required expression of query
  defined under EJB QL. It defines the scope of the
  query by declaring identification variables. The
  FROM clause designates the domain of the query,
  which may be constrained by path expressions.
• All the characters are allowed that returns true
  for isJavaIdentifierPart, except '?' as it is
  reserved for EJB QL. All the identifiers are case
  sensitive.

44
EJB QL

• FROM Clause
• Following identifiers are reserved for the use of
  EJB QL
• SELECT, FROM, WHERE, NULL, TRUE, FALSE, NOT,
  AND, OR, BETWEEN, LIKE, IN, AS, FROM, WHERE,
  UNKNOWN, EMPTY, and IS.
• Example

45
EJB QL

• WHERE Clause
• WHERE clause of the EJB QL is used to restrict
  the resultset of the query.
• WHERE clause supports following literals from
  Java
• Java String With same syntax as Java String
  and Unicode encoding.
• Java long With same syntax as Java integers
  
• Java double With same syntax as Java
  floating points.
• Java boolean They are TRUE and FALSE.
• Example

46
EJB QL

• SELECT Clause
• An EJB QL query string used for a select method
  requires a SELECT clause.
• The SELECT clause defines the types of values to
  be returned by the query.
• There are two types of select methods defined.
  ejbSelectltMETHODgt
• ejbSelectltMETHODgtInEntity
• They determine the return type for the query.
• Example

47
EJB QL SQL

• When query does not return anything its value is
  regarded as NULL.
• EJB QL does not support use of comments.
• Date and time values should use the standard Java
  long millisecond value.
• EJB QL does not support fixed decimal comparison.
• Inheritance is not supported in CMP model so
  comparison of that kind is illegal in EJB QL.

48
EJB QL in WebLogic 6.0

• WebLogic 6.0 claims to support EJB specifications
  2.0.
• Use of CDATA in the ejb-ql element
• ltejb-qlgtlt!CDATAWHERE accountType IN
  ('partners', 'channels')gtlt/ejb-qlgt
• Report
• Grammer

49
References

• Richard Manson-Haefels site book
• Mastering Enterprise JavaBeans and The Java 2
  Platform, Enterprise edition , book by Ed Roman
• Bea's WebLogic Server site.
• Enterprise JavaBeans homepage

50
Discussion

• Discussion