CS590L Distributed Component Architecture

1
CS590L Distributed Component Architecture

• Yugi Lee
• STB 555
• [phone]
• leeyu_at_umkc.edu
• www.sice.umkc.edu/leeyu
• This presentation is designed based on Michael
  Stals COM, CORBA, EJB Presentations and Diego
  S. Ruiz http//www.ditec.um.es/dsevilla/ccm/

2
EJB 2.0 Message-driven Beans

• Properties of a Message-driven bean
• A message-driven bean is an asynchronous message
  consumer invoked as a result of an JMS message.
• Message-driven beans have no home or remote
  interface.
• Message-driven beans have no identity, they are
  anonymous.
• Message-driven bean created by container to
  handle incoming messages.

3
Message-driven Beans Client View

• A message-driven bean is simply a JMS message
  consumer.
• The client sends a message to a JMS destination
  (queue, topic) for which the bean is a
  MessageListener.
• From the client perspective the bean is
  completely hidden behind the JMS destination.

4
Message-driven Beans Component Contract

• Bean provider specifies in deployment descriptor
  whether bean is associated with a queue or a
  topic.
• For topics bean provider may specify durable or
  not durable topic subscriptions.
• Container controls life cycle of message-driven
  beans.
• Bean must implement javax.jms.MessageListener
  interface onMessage( javax. jms.Message)
• Container provides MessageDrivenContext
• setRollbackOnly, getRollbackOnly,
  getUserTransaction, getCallerPrincipal,
  isCallerInRole, getEJBHome

5
Message-driven Beans Responsibility

• Message-driven Bean class
• must be public, not abstract or final
• must provide a public constructor with no args
• must implement javax.ejb.MessageDrivenBean
  interface ejbCreate, ejbRemove
• must implement javax. jms. MessageListener
  interface onMessage

6
Container provider Responsibility

• Generate the implementation classes.
• Support deployment of a message-driven bean as
  the consumer of a JMS queue or topic.
• Ensure that only one thread can execute at any
  time.
• Follow the rules of transaction scoping, security
  checking, and exception handling.
• Handle message acknowledgement according to
  deployment descriptor settings.

7
Transaction Support

• Enterprise JavaBeans supports flat transactions
  (OMG OTS 1.2)
• Transactions are provided automatically by EJB,
  or bean managed transactions.
• EJB supports distributed transactions using a
  two-phase commit protocol

8
Transaction Support

• Relationship to JTA and JTS
• JTA (Java Transaction API) defines interfaces
  between a transaction manager and other parties.
  Must be implemented by EJB product.
• JTS (Java Transaction Service) is a binding of
  the CORBA OTS. Optional for EJB product.
• EJB requires a container to support the JTA
  interface javax.transaction. UserTransaction .

9
Transaction Support

• Possible scenarios
• EJB lets applications update data in multiple
  databases in a single transaction.
• It allows to updata data at multiple sites in one
  transaction.
• A client or non-transaction enterprise Bean may
  explicitely demarcate transaction boundaries.
• For other Beans the container exposes method
  invocations and controls demarcation.
• A container may allow connectivity to non-Java
  applications.

10
Transaction Support

• The Transaction attribute of a whole Bean or
  single method can be
• Supported, Never, Required, Supports,
  RequiresNew, Mandatory
• Message-driven beans can only use Required and
  NotSupported.
• EJB 2.0 entity beans with container managed
  persistence can use Required, RequiresNew,
  Mandatory.
• Stateful session beans that implement
  SessionSynchronization Required, RequiresNew,
  Mandatory.

11
Distribution and Interoperability

• CORBA (RMI- IIOP) is the standard way to access
  an enterprise Bean

12
Interoperability aspects

• Remote invocations interoperability via RMI- IIOP
• Transaction interoperability
• Transaction context transferred using OTS v1.2
• Common protocol used Two-Phase Commit
• Naming interoperability through CosNaming (CORBA
  Interoperable Name Service)
• Security Interoperability based on CORBA/ IIOP
  and CORBA Security Specification CSIv2

13
Security Management

• Callers have roles and identities.
• Bean can identify the caller using
  isCallerInRole() and getCallerPrincipal() .
• Run-as-identity may be specified by deployer.
• Container shield beans from specifics of
  underlying platform.

14
Deployment Descriptor

• The bean provider must supply information
• Bean name, bean class, home interface, remote
  interface
• Bean type (entity, session, message- driven)
• Re- entrancy (session/ message- driven beans are
  never re- entrant)
• State- management type for session beans
  (stateful, stateless)
• Transaction demarcation type for message- driven
  bean
• Persistence management (managed, container)
• Primary key class prim-key-class element.
  Bean-managed class name
• Abstract schema name (for cmp- version 2. x)
• cmp- fields, crm- relationships, dependent
  classes
• Finder/ select queries
• Environment entries, resource manager factory
  referencesm, resource env. References, EJB
  references, security role references, Message-
  bean destination, Message- selector, Message-
  acknowledgement mode

15
Deployment Descriptor

• The Application Assembler provides additional
  information
• Values of enviroment entries
• Descriptions
• Relationship names (if multiple ejb-jar files are
  merged, assembler must modify ejb-relationship-nam
  e elements).
• Optional binding of enterprise bean references,
  definition of security roles, method permissions,
  linking of security role references, security
  identity, transaction attributes, message- driven
  bean selector.

16
Conclusion

• EJB is a J2EE technology for building
  platform-independent middle-tier components in
  Java.
• It is based upon CORBA/ IIOP.
• With EJB 2.0 Java gets ready for distributed
  Enterprise Computing. Tool support for EJB is
  great. EJB 2.0 products will arrive very soon.
• There is space for improvements
• EJB is focused on business apps, not on systems
  with specific QoS requirements.
• EJB does not offer an event mechanism.

17
Modeling

• When to use Session Beans?
• Everytime, when you need to design processes,
  activities, that do not need recoverable state
• Everytime, when the server must have memory
  (conversational state), (Stateful Session Beans)
  to migrate logic at the middle tier

18
Modeling

• When to use Entity Beans?
• To design persistent business objects
• When you want to give clients access to remote
  data base tables
• but not to keep session specific data on the
  server, because Entity Beans are accessed by
  multiple clients
• Entity Beans should not be used by the client
  directly it is better if entity beans are only
  accessed by session beans.

19
Modeling

• When to use Message- driven Beans?
• To receive information asynchronously.
• To build JMS MessageListeners with better Quality
  of Service as well as robustness, security,
  transaction support.

20
Rule 1 Minimize communication overhead

• Do not define access methods ( setter/ getter)
  for single values, but introduce methods, that
  read or write multiple values at the same time.
• Reason You never get communication for free!
• Every remote method invocation leads to network
  communication (EJB are NOT JavaBeans)
• In general, minimize number of invocations!
• Transfer multiple data with each call!

21
The Wrong Way
22
The Right Way
23
Rule 2 Never transfer mass.data. Use lazy
evaluation.

• Avoid methods that provide mass data.
• Better define a kind of iterator to get data in
  smaller portions.
• Keep the state of the iterator in the server.

BookStore store String isbn String last
null do isbn store. listISBN( last)
if (isbn ! null) // Computation .
last isbn isbn.length- 1 while
(last ! null)
public interface BookStore String
listISBN( String last)
24
Rule 3 Clients should not access entity beans.

• Entity Beans should only be used by Session
  Beans, but not by clients.
• Reason Entity Beans are wrappers for database
  tables and cannot contain session specific
  information (similar to with 2-tier architectures)

25
EJBMetaData Interface

• EJBMetaData is used for type inquiry at run-time
• import java. rmi.
• public interface javax. ejb. EJBHome
• public javax.ejb.EJBHome getEJBHome()
• public java.lang.Class getHomeInterfaceClass()
• public java.lang.Class getPrimaryKeyClass()
• public java.lang.Class getPRemoteInterfaceClass()
  
• public boolean isStatelessSession()

26
EJBHome Interface

• EJBHome is the base class of all home interfaces
• import java. rmi.
• public interface javax. ejb.EJBHome extends
  java.rmi.Remote
• public EJBMetaData getEJBMetaData()
• throws RemoteException
• public void remove( Handle handle)
• throws RemoveException, RemoteException
• public void remove( Object primaryKey)
• throws RemoveException, RemoteException
• public javax.ejb.HomeHandle getHomeHandle()
• throws RemoteException

27
EJBObject Interface

• EJBObject is the base class of all remote EJB
  interfaces
• import java. rmi.
• public interface javax. ejb. EJBObject extends
  java. rmi. Remote
• public javax. ejb. EJBHome getEJBHome()
• throws RemoteException
• public java. lang. Object getPrimaryKey()
• throws RemoteException
• public void remove() throws RemoveException
• public javax. ejb. Handle getHandle() throws
  RemoteException
• public boolean isIdentical( javax. ejb.
  EJBObject)
• throws RemoteException

28
Messaging explained

• CORBA, RMI, DCOM offer synchronous requests
  Servers / Receivers must be online.
• Sometimes, store forward semantics is more
  appropriate Mobile users, Stock tickers, ...
• The JMS (Java Message Service) provides a way to
  create, send, receive, and read messages offline.

29
JMS

• JMS is an API to integrate existing MOM solutions
  (JMS Providers).
• Point to Point approaches are supported as well
  as Publish/ Subscribe (Message Listeners).
• Queues ( mailbox) and Topics ( newsgroup).
• Different kinds of message bodies are provided
  stream, text, serialized object, bytes, map.