Full HTML for
Given by H. Timucin Ozdemir at CPS714 Computational Science Information Track on June 16 99. Foils prepared July 6 99
Outside Index
Summary of Material
Denote Foils where Image Critical
Denote Foils where Image has important information
Denote Foils where HTML is sufficient
Distributed Web Object Computing: Component Technologies
Software Components
Software Components - II
Software Components - III
Infrastructure
Challenges
Example Systems
Enterprise Java Beans (EJB) 1.1
EJB 1.1 - II
EJB Component Types - I
Session Beans
EJB Component Types - II
Client-Component Interactions
Client-View - I
Client-View - II
Component-View / Bean Developer Responsibilities
Component-View / Container Responsibilities
Deployment Descriptor - Structural
Deployment Descriptor - Assembly Descriptor
Session and Entity Beans
Session Beans
Session Beans - Home Interaface
Session Beans - II
Session Beans - III
Session Beans - Passivation&Activation
Session Beans - SessionContext Interface
Session Beans - Lifecycle
Session Beans - Lifecycle
Entity Beans
Entity Beans - Container
Entity Beans - Look Up
Entity Beans - Home
Entity Beans - EJB Object
Entity Beans / Handle - I
Entity Beans / Handle - II
Entity Beans / Persistence - I
Entity Beans / Persistence - II
Bean-managed Persistence
Container-managed Persistence
Entity Bean Lifecycle - I
Entity Bean Lifecycle - II
Entity Bean Lifecycle - III
Entity Bean Lifecycle - IV
Entity Beans / Callbacks - I
Entity Beans / Callbacks - II
Entity Beans / Callbacks - III
Entity Beans / Container Perspective - I
Entity Beans / Container Perspective - II
Entity Beans / Container Perspective - III
Entity Beans / Container Perspective - IV
Entity Beans / Bean Developer
Entity Beans / Container Responsibility
Entity Beans / Container Responsibility
Container-Managed Persistence - I
Container-Managed Persistence - II
Container-Managed Persistence - III
Container-Managed Persistence - IV
Transaction Processing - I
Transaction Processing - II
Transaction Processing - III
Transaction Processing - IV
Transaction Processing - V
Transaction Processing - VI
Transaction Attribute
Bean-Managed Transaction
Transaction Attribute - I
Transaction Attribute - II
Customization
Customization - II
Customization - III
Customization / Environment Variable
Customization / EJB Reference - I
Customization / EJB Reference - II
Resource Factory Reference
Security
Security - II
Security - III
Security - IV
Security - V
Security - VI
Method Permission
Security - VII
Packaging
Structural Definition - I
Structural Definition - II
Application Assembler
EJB Classes
Interfaces and Implementation
Finding Home Implementation
Stateful vs Stateless
Using Handle Object
Using Environment Entries
Method Selection Pattern
CORBA Components
Facets - I
Facets - II
Facets - III
Receptacles - I
Receptacles - II
Event Sinks
Event Sources
Generic Events Interface
Home Interface - I
Home Interface - II
HomeFinder
Component Configuration - I
Component Configuration - II
Container Model - I
Container Model - II
Container Model - III
Container Model - IV
Container Model - V
Servant Policies
Transaction Policies
Security Policies
Persistence
Component Types - I
Component Types - II
Server Programming interfaces
Interfaces common for all Container Types
Common Interfaces - II
Common Interfaces - III
Common Interfaces - IV
Common Interfaces - V
Interfaces for Transient Container Type - I
Interfaces for Transient Container Type - II
Interfaces for Persistent Container Type - I
Interfaces for Persistent Container Type - II
Persistence
Persistence - II
Packaging and Deployment - I
Packaging and Deployment - II
CORBA Software Descriptor
Component descriptor
Component Assembly Packaging
Component Assembly Descriptor
Deployment - I
Deployment - II
Deployment - III
Deployment - IV
POA based Container Architecture
Microsoft Transaction Server (MTS - Viper)
MTS - II
MTS - III
MTS - IV
MTS - V
MTS - VI
MTS - VII
MTS - VIII
State Information
IObjectContext - I
IObjectContext - II
Packaging - I
Packaging - II
Deployment - I
Deployment - II
Context Wrapper
Lifecycle - I
Lifecycle - II
Security
Security - II
Security - III
Programmatic Security
Transaction Processing
Transaction Processing - II
CORBAComponents vs. EJB 1.1
CORBAComponents vs. EJB 1.1
CORBAComponents vs. EJB 1.1
CORBAComponents vs. EJB 1.1
CORBAComponents vs. EJB 1.1
ACID
Two Phase Commit Protocol
Outside Index
Summary of Material
HTML version of Basic Foils prepared July 6 99 
Full HTML Index
| H. Timucin Ozdemir |
| June 16, 1999 |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
A software component:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A business component represents the software implementation of an autonomous business concept or business process. It consists of the software artifacts necessary to express, implement, and deploy the concept as a reusable element of a larger business system. (Wojtek Kozaczynski, SSA) |
A common characteristics drawn from these definitions are:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Advantages of component based software engineering (CBSE) is: reuse, upgrade, adopt new technologies, and utilizes distributed resources. |
Component model address the semantics of
|
| Attribute-based (declarative) programming supports dynamic configuration of components for security, transaction, persistence, and lifecycle. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Components require an infrastructure which leverages the following services:
|
| In general this model defines three roles: clients, component managers (containers), and components. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Component based software engineering requires:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| OMG's CORBA Components |
| Sun's Enterprise JavaBeans |
| Microsoft's DNA |
| IBM's SanFrancisco and Component Broker |
| BEA's M3 |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Enterprise Java Beans (EJB) defines a Java based component model. |
| Enterprise beans are deployed into EJB Containers and defines their transaction and security needs in another file with the component meta-data. |
| The implementation and meta-data files are deployed within the ejb-jar file for the assembly and deployment agents. |
| Enterprise Bean encapsulates the business logic. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Enterprise bean is created and managed by a Container. Clients never sees the actual bean instance. |
| Enterprise bean can be customized during deployment time. |
| Transaction and security attributes are separated from the bean implementation so that they can be described in metadata with various settings. |
| Enterprise Beans can be re-assembled to build more sophisticated components without any source code changes. |
| Default protocol is JRMP (Java RMI Protocol). |
| CORBA mapping is defined by RMI-IIOP mapping. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
EJB defines three types of components:
|
| Stateless components refer to services that do not require any previous state information (Stateless Session Bean). |
| Conversational components refer to object that maintain their state across multiple client method invocations and it finishes off as soon as client finishes with the client (Stateful Session Bean). |
HTML version of Basic Foils prepared July 6 99 
Full HTML Index
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Persistent components refer to object that can be shared among multiple clients and live even the container crashes for a while (Entity Bean). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Development and usage of beans are based on contracts between client and container (client-view) and component and container (component-view). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Client expects to get the handle of the following objects to interact with the beans:
|
| Home interface defines a factory and finder pattern to create, remove, and find EJB objects. Bean developer provides the description of this interface and container (deployment tool) creates the necessary implementation based on this description. Home interface extends from javax.ejb.EJBHome interface. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Remote interface defines the business logic for the bean and container (deployment tool) provides an implementation of EJB Object implementing the remote interface and extending from javax.ejb.EJBObject. Client uses EJBObject to obtain the identity of the bean and create a persistent handle for the object. |
| Identity of a bean is unique in its home. |
| Metadata interface can be used by clients to perform dynamic invocation. |
| Component-view requires some responsibility from the bean implementation and the container. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
The responsibilities of bean developer are:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
The responsibilities of container are:
|
| Beans are packaged and deployed with an ejb-jar file. This file includes class files for the implementation, remote interfaces and home interfaces. An ejb-jar file includes XML deployment descriptor defining the structural and application assembly information about the beans in the file. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| <ejb-jar> |
| ..... |
| <enterprise-bean> |
| <session> |
| <ejb-name>..</ejb-name> |
| <ejb-class>npac.StudentImpl</ejb-class> |
| <env-entry> |
| <description>...</description> |
| <env-entry-name>ejb/myString</env-entry-name> |
| <env-entry-type>java.lang.String</env-entry-type> |
| <env-entry-value>"Hello"</env-entry-value> |
| </env-entry> |
| ..... |
| </session> |
| ...... |
| </enterprise-bean> |
| .... |
| </ejb-jar> |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| <ejb-jar> |
| ..... |
| <assembly-descriptor> |
| ... |
| <container-transaction> |
| <method>....</method> |
| <trans-attribute>Required</trans-attribute> |
| </container-transaction> |
| ..... |
| </assembly-descriptor> |
| </ejb-jar> |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| EJB architecture defines two types of enterprise beans: session and entity. |
| Session beans execute on behalf of a single client, can be transaction-aware, updates the shared data in database, is relatively short-lived, and is removed when the EJB container crashes. |
| Entity beans provide an object view of transactional data in the database, allow shared access from multiple clients, can be long-lived and survive when the EJB Container crashes. |
| Entity beans have its primary key therefore it is still accessible after the container crashes and restarts. When the EJB Container restarts, the entity bean restarts from its last saved state. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Session bean represents a non-persistent object implementing some business logic running on the server side as an extension of client's application. |
| Beans are accessible with EJB Objects implementing the remote interface and additional services for client and container. |
| EJB Object lives in a container from its creation to desruction. |
| A container can contain multiple EJB classes. |
| An EJB container implements the home interface of each installed enterprise bean. |
| Container makes home interfaces available through JNDI when the container deploys the bean. |
| Client obtains the reference of home object using JNDI. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Home interface
|
| EJB Object delegates the remote interface calls to the enterprise bean implementation. |
| EJB Object additionally provides operations to get the home's reference, object's handle, test whether two EJB Objects are identical, and remove the object. |
| Session beans are created for the requesting client therefore they have no identity and their home interface does not define finder pattern. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Because of scalability reasons, container keeps some objects as active while passivating some of them. The passivation process takes place if the bean is not in a transaction. To help the container's management of resources, EJB specifies two kinds of session beans: stateless and stateful. |
| Stateless session beans contain no conversational state and any bean instance can be used for any client invocation since there is no state information between method calls. |
| Stateful session bean contains conversational state across method invocations and transactions. |
| A state of a conversational bean is defined by its field values and transitive closure of the objects from the session bean's fields by following the object references. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Stateful session EJB Object has a unique identity that is assigned by container at creation time. All EJB Objects of the same stateless session bean have the same identity assigned by the container. |
| A Handle of a session EJB Object can be serialized and used later to connect to the same EJB Object but it is not guaranteed that the object stays alive. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Since a bean can be using some resources such as socket or database cursor and a container can not retain such resources, EJB defines two callback methods on the object to inform that it is about to be passivated (ejbPassivate()) or activated (ejbActivate()). The implementation of bean is responsible for releasing and obtaining those external resources within these methods. |
| Container invokes ejbPassivate() method on the bean and then serialize all its fields by using Java serialization. |
| Container invokes a setSessionContext() method on the EJB session bean to give the a handle to its context where a bean can access its context maintained by the container. Container uses a SessionContext for session beans. |
HTML version of Basic Foils prepared July 6 99 
Full HTML Index
SessionContext interface contains the following methods:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Since container provides the implementation for the Home interface defined by the bean developer, container expects the similar methods from the bean implementation. |
| Home interface contains various create() methods therefore container expects that the bean implementation defines the ejbCreate() methods matching with the parameters in the defined create() methods. |
| When container needs to create a bean instance, it calls a newInstance() method on the bean therefore bean implementation has to have a public constructor without any parameter. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Container sets the context of the bean by calling the setSessionContext() method and calls the proper ejbCreate() method based on the create() method call by passing all the parameters. |
| Container serializes all method calls (client or container started) to the bean. Furthermore, container throws an exception if a client call arrives during the execution of a business method. |
| Container invokes the ejbRemove() method when the client invokes remove() on the EJB Object or the container decides to remove the instance. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| An entity bean is an object representing an object view of an entity stored in a persistent storage (data base). |
| Multiple clients can access an entity object concurrently. |
| Container properly synchronizes access to the entity state using transactions. |
| Entity beans have a persistent identity which will survive after server crashes. This identity is assigned by the container. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Container
|
Home Interface
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Entity Beans' home interface defines finder methods to look up an EJB Object or a collection of EJB Objects. The name of each finder method should be prefixed with "finder". |
| The return type of this methods is the Remote interface or a collection of EJB Objects (Enumeration in JDK 1.1 and Collection in JDK 1.2) |
| Entity Beans' home interface includes a findByPrimaryKey(primaryKey) method to look up an EJB Object with a primary Key. The return value of findByPrimaryKey() method is the Remote interface. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Entity Beans' home interface also includes two remove method with Handle and Object parameter, respectively. |
| The identity of an entity bean is determined by the EJB Object's Home and primary key. |
| The Primary Key class is any class that is a legal Value Type in RMI-IIOP. Each enterprise bean class defines its own primary key class. |
| getPrimaryKey() method of EJB Object returns the unique identity of the bean in its home context. |
| Equality of two EJB Object references can be tested by using isIdentical(Object) method of EJB Object or comparing primary key values of those references if EJB Objects are obtained from the same home. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
EJB Object supports the following methods in addition to the Remote interface:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| getHandle() method of EJB Object returns a Handle object identifying the corresponding EJB Object. |
| A Handle object is serializable (java.io.Serializable) so that a client may save this value and use it to obtain a reference to the same EJB Object from a different process or even system by passing this value to another client on another system. |
| The life time of Handle object is generally outlives the life time of the container since it generally refers a key representation in the persistent storage. For example employee records stay in this storage couple of years while server might observe crash every week or so. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A Home interface's Handle can be used to obtain reference to this interface when the Home interface is in the stable store. This approach frees the client to know the JNDI name of the Home interface to be able to connect to it. |
| Entity bean implements an object view of an entity in the underlying persistent storage. |
| The state of an entity is transferred between persistent storage and the bean instance and this data access protocol is known as object persistence. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| There are two approaches: bean-managed and container-managed. |
| Bean-managed persistence when a bean supports its persistence protocol, it is called bean-managed. |
| When a container provides the persistence protocol, it is called container-managed persistence. |
| When a component is in the memory, it is called that the component is active or in active state. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| When the component is not in memory while its reference is active (meaning that it is not totally vanished from the persistent storage, like employee left the company), then the component is passive or in passive state. |
| The container swaps the components between active and passive states to utilize the server resources much like page swapping in virtual memory management. |
| During this process, container informs the component about its intention to change the state of the component via callback methods. |
| These callback methods give the component to a chance to take the necessary actions for state transition. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| In bean-managed persistence model, a bean developer should write the database access calls (by using JDBC or SQLJ, etc.) into the bean implementation. |
| This kind of coupling puts extra deployment restrictions on the bean since it requires a specific data access protocol support from the container server. Portability can be an issue since this may cause difficulties to deploy the bean with a different type of database. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| In container-managed persistence model, a container (deployment tool) generates the database access calls at the deployment time. This model requires the bean provider to specify the list of fields constituting the state of this bean in the deployment descriptor. |
| The container can produce the necessary data access calls for those fields (can do caching, connection pooling, etc). |
| This model de-couples the bean from its data access calls while it introduces a challenge to the container (deployment tool) developer to deal with the possible mapping problems between the fields and data source (no-free-lunch). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The Container invokes newInstance() method on the bean's class to obtain a an instance. The container invokes setEntityContext() method on the instance to pass the context information to the instance. |
| The instance is in semi-active state at this point because find<METHOD>() methods can be invoked by the container but no client call (except the finder operations) can cause any method call on the instance. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The instance becomes active when the container associates an EJB Object with the bean instance. |
| A container invokes ejbCreate() and ejbPostCreate() methods to inform the bean that it should be ready to receive method invocations. |
| After this point container delivers business and state synchronization calls (ejbLoad() and ejbStore()). |
| ejbLoad() callback informs bean to load its state from the data store and ejbStore() informs the bean to store its state to the data store so that the possibly cached information in the bean's fields is transferred to the stable storage. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The container invokes ejbRemove() method on the instance when it wants to remove the instance or a client invokes a remove method on the EJB Object or bean's Home interface. A bean implementation is expected to remove its entity presence from the data store (removing a row from table). |
| The container might want to passivate the instance to utilize the system resources in that case the container invokes ejbPassivate() method on the instance and disassociates the EJB Object from the instance. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The instance can be recycled even though an ejbRemove() method is invoked since its fields can be loaded from another persistent object. |
| The container calls unsetEntityContext() method on the instance when it really removes the instance from memory for good. |
| Multiple client access to the entity beans from different transactions are synchronized by the container either serializing the calls to the bean or creating per transaction copy of the same entity bean and delegating the synchronization process to the data store. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| setEntityContext() method can be used by an instance to allocate any resource that is going to be used during the life time of this instance. |
| unsetEntityContext() method should be used by an instance to release any resources that has been used by the instance. |
| ejbCreate() inserts a record representing the entity into the database. It returns a primary key for this entity. |
| For each ejbCreate() method, a bean has to implement ejbPostCreate() method with the same input parameters , and void return type instead of primary key. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| ejbPostCreate() method is invoked by the container after ejbCreate() method invocation on the instance. |
| ejbActivate() method invocation informs the instance that an EJB Object is associated with this instance and it can expect business method calls. |
| ejbPassivate() method invocation informs the instance that an EJB Object is disassociated. |
| ejbRemove() method is invoked by the container upon receiving a remove() request from the client. The bean implementation should remove its entity representation from the database. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| ejbLoad() method invoked by the container to inform the bean instance that it must synchronize its state from the database. This method is only invoked as long as there is an associated EJB Object with this instance. |
| If the bean instance using its fields to cache the state of the entity, it should not use this values and loads them from the database. |
| ejbStore() method invoked by the container to inform the bean instance that it is time to synchronize its state with database by updating the entity record. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| find<METHOD>() method definitions are declared by the bean provider therefore the bean implementation should contain matching ejbFind<METHOD>() methods so that the container can invoke the corresponding find operation. |
| setEntityContext() method is invoked by the container after the creation of the instance. |
| unsetEntityContext() method is invoked by the container to inform the bean instance that it reached the end of its existence. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| When container receives a create() request from the client, it invokes matching ejbCreate() method on the bean instance (assuming that there is already available one instance). |
| A container creates an EJB Object reference for the primary key returned from the ejbCreate() method and invokes ejbPostCreate() on the instance. |
| After the successful completion of this call, the container returns the reference of EJB Object to the client. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| ejbActivate() method is invoked by the container to inform the bean instance that an EJB Object is associated with this instance. The container will deliver business calls after it invokes the ejbLoad() to make sure that the instance is synchronized with database. |
| ejbPassivate() method is invoked by the container to inform the bean instance that the associated EJB Object is about to be disassociated from this instance. Container calls ejbStore() method before calling this method to make sure that the bean instance updates its possibly cached state to the database. |
| ejbRemove() method is invoked by the container to inform the instance that the EJB Object will be removed. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| ejbLoad() method is invoked by the container before the first business call within a transaction to make sure that the instance will be in correct state. |
| ejbStore() method is used to synchronize the state of an entity with the database and in general this invocation occurs at the end of transactions. |
| The container can also use this method to make sure that the state is saved before the passivation of the entity or transfer this state to another instance via the database ( can occur for the distributed transaction in a multi-process server). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Bean provider should give the following class files:
|
| Bean class should only implement the business calls, ejbCreate(), ejbPostCreate(), and ejbFind<METHOD>() calls while leaving empty the methods defined n javax.ejb.EJBObject,i.e., the bean class implementation is an abstract class. |
| Primary key class must provide an implementation of hashCode() and equals() methods. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The deployment tools provide the class definition for the bean's home interface and bean's remote interface. |
| Home interface implementation calls ejbCreate() and ejbPostCreate() in the create() method calls. |
| In the remove() call, the implementation activates the object if it is not active and invokes the ejbRemove() on the instance. |
| For finder methods, it invokes the proper ejbFind() method on the instance, creates an EJB Object associated with the primary key returned from ejbFind() method call, returns the reference of EJB Object to the client. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| If the finder method returning a collection of primary keys, then the implementation creates an EJB Object for each one and returns the set of EJB Object references. |
| The implementation of EJB Object for the bean provides the support for javax.ejb.EJBObject methods (not implemented by the bean class provider) and activates the instance before calling any business methods or ejbRemove() method on the bean. |
| Deployment tool provides the implementation of Handle object for enterprise bean and its home. |
| Deployment tool provides the implementation for meta data object implementing javax.ejb.EJBMetaData interface. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| When container-managed persistence is in use, there are some changes since the generated objects also implements the creation, removal, and look up of the entity in the underlying database. |
| First, the fields of bean class is described in the deployment descriptor with cmp-field tags so that the container can figure out the entity fields to prepare necessary data access protocol calls. |
| Second, the semantic of ejbCreate(), ejbRemove(), ejbLoad(), and ejbStore() methods changes since the bean is no longer responsible for synchronization of its state with the data store. Also, the implementation of finder methods are provided by the container since the bean class is de-coupled from the data store. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Container performs the database insert after ejbCreate() method completes. |
| Since the bean provider does not know the primary key class, it returns null from ejbCreate() method. Container defines a primary key for this entity and associates an EJB Object before it calls the ejbPostCreate() method on the instance. |
| ejbRemove() method is invoked in respond to client-initiated remove() operation. Container removes the entity from data store after the completion of ejbRemove() call. |
| ejbLoad() method is called after the container synchronizes the fields in the instance from the data base. ejbStore() method is called by the container and it saves the fields of the instance after the completion of this call. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Since finder methods require the knowledge for the data store, a bean provider can not produce necessary codes for this operations. The deployment tool provides the finder operations. |
| The bean provider provides a description for finder methods so that the deployment tool produce the necessary implementation for the finder method. EJB Spec does not specifies any format description of these methods. |
| Primary Key class implementation is also provided by the deployment tool. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Bean provider gives the field of the bean class containing the primary key with "primkey-field" tag in the deployment descriptor. Bean provider does not have to define a primary key in that case the deployment tool decides on this. But the bean class implementation should not be rely on any specific type of primary key accept that it will be java.lang.Object type. |
| Bean provider must specify this. |
| Bean must implement javax.ejb.EntityBean interface. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| EJB supports programmatic transaction and declarative transaction handling. |
| If the programmatic transaction is preferred (bean-managed transaction), then the bean itself interacts with the transaction servers. |
| If the container-managed transaction is used, then the container handles the transaction related operations. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Transactions can be local or global. |
| A local transaction is managed by the resource manager while a global transaction is managed by a global transaction manager. |
| A global transaction in general interacts with more than one resource managers. |
| EJB spec only defines a flat transaction (not nested). |
| EJB requires that the EJB container supports the javax.transaction.UserTransaction interface defined in the Java Transaction API (JTA) for distributed transaction processing. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| In the EJB transaction processing there are roles who might want to interact with the transaction manager: client, container, and bean. |
| A client might need to demarcate the transaction boundaries therefore it needs to access he javax.transaction.UserTransaction interface. |
| A client can obtain a reference to this interface from JNDI according to the JTA specification. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Container needs to demarcate the transaction boundaries or provide support for UserTransaction interface. |
| Bean needs to demarcate the transaction boundaries when the bean-managed transactions is in use. Bean obtains the reference of javax.transaction.UserTransaction interface from the context object given by the container. |
| Session bean can be declared as bean-managed or container-managed transaction. |
| Entity bean always declared with container-managed transaction. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A local transaction is managed by the resource manager itself therefore it can not ensure the atomicity of operations onto multiple resources. A local transaction uses the API provided by the resource. |
| A global transactions are handled by a transaction manager that executes the two-phase commit protocol on multiple resource managers. A global transaction uses the javax.transaction.UserTransaction interface. |
| Bean-managed transactions can use local and global transactions without any overlap. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Only session bean can use this. |
| Container-managed transaction requires that the bean implementation does not use any resource specific transaction management since the container is in charge of defining transaction boundaries. |
| The transaction type is only relevant for session beans therefore the deployment descriptor of session bean should specify which protocol it needs to use with transaction-type tag. |
| Container obtains the required transaction support from the transaction attributes defined in the deployment descriptor. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The transaction attribute is defined per method basis. The deployment descriptor should contain those description for business methods. |
| A session bean description should not specify anything for remove() and create() methods |
| An entity bean description should define transaction attributes for remove, create, and find methods. |
| In the deployment descriptor, container-transaction tag is used to give the transaction attributes. In this tag each trans-attribute element associates a transaction attribute with the included methods. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| In bean-managed transaction mode, a container suspends any transaction associated with the client's request before invoking any remote method call on the bean instance. |
| If the instance is associated with a global transaction, container invokes the client request with this transaction context. When the bean uses javax.transaction.UserTransaction interface, container enlists all the resources used by the instance and coordinates the global transaction commit when the instance commits the transaction. |
| The stateful session bean can start the transaction in one business method and commit in another business method. In those cases, the container keeps the association information between the transaction and the instance and uses this transaction context for the following business calls until the transaction is ended (committed or rolled back). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A transaction attribute can have the following values: |
| NotSupported: Container invokes this method without a global transaction context. If a client invokes the call with a transaction context, the container suspends this transaction until the method call completes. |
| Required: method is invoked with a global transaction context. If the client's request is associated with a transaction context,, then this context is used. Otherwise, container starts a new transaction, enlists all the resources, invokes the method with this transaction context, and commits the transaction as soon as the method call completes. |
| Supports : method is invoked with a transaction context if the client's request is associated with one. Otherwise, the method is invoked without any transaction context. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| RequiredNew : Container always starts a new transaction, enlists the resources and commits the transaction as soon as the method call completes. If the client's request is associated with a transaction context, this will be suspended until the container commits the transaction. |
| Mandatory : method is invoked within a transaction context with that the client request is associated. If the client's request is not associated with any transaction, then the container throws an exception. |
| Never : method is invoked if the client's request is not associated with any transaction. The container throws an exception if the client's request is associated with one. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Customization of components makes the components reusable without the source code. |
| There are two phases where these customization can occur: assembly and deployment. |
| Assembly process takes the various components and defines a various connection between them and initial values. |
| Deployment process takes the output of assembly and updates the some values if necessary for deployment (mapping for security, initialize unset values,etc.). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| When the re usability is desired, the implementation of the bean class should be able to obtain the customization values. |
| EJB uses JNDI (in jndi:/comp/env context ) for storing and obtaining environment values. |
Environment values (entries) can be
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The environment is set up by the container through the JNDI interface and its scope is defined by the home instance. |
| If a container deploys a multiple home instances for the same bean class, each one of them can be deployed with different environment settings. The bean instances that belongs to the same home shares the same customization. |
| Each bean deployment descriptor contains the declaration about the environment variables |
| The value of environment variables are read-only for enterprise beans. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Environment variables (entries) are defined with ent-entry tag. |
| ent-entry tag contains an (optional) description element, the entry name relative to the jndi:/comp/env context, Java type of the entry value, and (optional) default value for this entry. |
| The value must be a valid literal for Java assignment ("value1", true, false, 12, ..). |
| Application assembler can modify and set the unset environment values. |
| Deployment tool can modify the environment values and must set the unspecified values. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| EJB references are used to obtain the reference of the other bean's home interface. |
| The deployment tool is responsible for proper binding in the JNDI context (might use LinkRef). |
| Application assembler tools can link an EJB reference declared in one enterprise bean to another bean in the same or different ejb-jar file. This gives an instruction to the Deployment tool to do the proper binding. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
EJB references are declared with ejb-ref tag in the deployment descriptor. ejb-ref tag contains
|
| Application assembler tool can use the ejb-link element in ejb-ref to link EJB reference to a target enterprise bean. |
| Deployment tool creates entries in JNDI context for those variables. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Resource factories represents the resources used by the bean such as JDBC. |
| A bean obtain the reference to these factories by using resource factory references in the deployment descriptor and looking up the environment variable from the JNDI entries during the runtime. |
Resource factory references defined with resource-ref tag. resource-ref tag contains
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Security Management
|
| The Application Assembler may define security roles for an application. |
| A security role describes the logical grouping of users who has permission to use the application. |
| The application assembler can define method permissions for each security role. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Deployer maps the principals or group of principals to the defined security roles. |
| The deployer tool defines the principal for inter-bean calls and resource manager access. |
| At runtime, each client is associated with a principal. If the client's principal role has a permission to invoke method, then it can be invoked otherwise the request will be denied. |
| Container is responsible for enforcing the security restrictions at runtime. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The bean provider and application assembler describes the caller's principal management of inter-enterprise bean invocations in the deployment descriptor. If nothing is specified, the principal associated with the client is propagated. |
| Even though the bean implementation should not contain any hard-coded security restrictions, it might want to obtain the caller's role to fulfill the required security in case it is not possible to describe in the deployment descriptor. Or it may use this information for other purposes such as sale representative performance screening. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
javax.ejb.EJBContext interface supports two methods:
|
| This approach allows beans implementation to enforce further security restrictions. Assume that all the sales personnel has a permission to execute the same method but each one of them might have different limits. Defining a sub-roles based on this functional difference explodes the number of roles. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Security roles are defined in the deployment descriptor and the deployer actually maps the principal or principal groups to those roles. |
| Bean provider declares the security roles with security-role-ref elements in the deployment descriptor. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Application assembler or Deployer links those names to the roles by using security-role elements. |
| security-role-ref contains a the name of security role (role-name element) and (optional) description element. |
| Application assembler defines security roles and method permissions for each role. Security roles are defined by security-role element. |
| security-role element contains the name of security role (role-name) and (optional) description element. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Method permissions are defined by method-permission element. |
| Each method-permission element defines many-to-many relationship between security-roles to methods. |
method-permission element contains the following elements:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| If the application assembler defines security roles, then it is also responsible for assigning security-role elements to the security-role-ref elements described by the bean provider. |
| security-role-ref element contains (optional) description element, and the name of role that is used in isCallerInRole() calls. Assembler adds a role-link element containing the name of the security role defined in security-role element. |
| Deployment tool assigns the security roles to the principals and/or group of principals (individual users or user groups). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| ejb-jar file is used to package un-assembled enterprise beans and assembled applications. |
| ejb-jar file contains the enterprise bean class implementation, bean's remote interface, bean's home interface and primary key class, and the META-INF/ejb-jar.xml file for the deployment descriptor. |
| The deployment descriptor defines a contract between ejb-jar file producers and consumers. |
| Deployment descriptor file uses XML syntax. |
| The structural declarations are given with enterprise-bean element. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The bean provider gives the structural representation of beans and application assembler may take these definitions and add/change additional information to describe the application. The output of this process is in ejb-jar file ready for the deployment tool. |
| The bean provider gives the structural definition of enterprise bean. |
| enterprise-bean element contains the following tags: |
| ejb-name (mandatory) : a logical name of the enterprise bean. This name can be used to access this bean through JNDI context. |
| ejb-class (mandatory) : the name of Java class implementing the remote interface. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| home (mandatory) : the fully-qualified name of the enterprise bean's home interface. |
| remote (mandatory): the fully-qualified name of the enterprise bean's remote interface. |
| Bean's type is defined with session or entity element. |
session element contains the following tags;
|
entity element has:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| env-entry: environment variables |
| resource-ref : resource factory definitions. |
| ejb-ref : EJB reference |
| security-role-ref : security role ref |
| Application assembler can change ejb-name, the value of environment entries, and description elements. |
| AA may also provide a definition for |
| ejb-link and role-link elements and additional assembly-descriptor element to define the security roles (security-role), method permissions (method-permission) and transaction attributes (container-transaction). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Public interface BookReservationHome extends javax.ejb.EJBHome { |
| BookReservation create(String libName) |
| throws RemoteException, BadLibNameException, CreateException; |
| } |
| public interface BookReservation extends javax.ejb.EJBObject { |
| void addReservationItem(String aStr); |
| void reserveAll(); |
| } |
| public interface BookReservation extends javax.ejb.EJBObject { |
| void reserve(String aStr); |
| } |
| public class BookReservationImpl implements SessionBean { |
| } |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Context initialContext = new InitialContext(); |
| StudentHome stHome = (StudentHome) javax.rmi.PortableRemoteObject.narrow( |
| initialContext.lookup("myejbs/school/studentHome", StudentHome.class); |
| public interface StudentHome extends javax.ejb.EJBHome { |
| Student create(String stName, String stId) throws RemoteException, BadStudentIdException, CreateException; |
| } |
| Student astudent = stHome.create("alex","3142"); |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| // Stateful Session Bean |
| BookReservation br = bReserveHome.create("Moon"); |
| br.addReservationItem("..."); |
| br.addReservationItem("..."); |
| br.reserveAll(); |
| br.addReservationItem(" ...."); |
| ...... |
| // Stateless Session Bean |
| BookReservation br = bReserveHome.create("Moon"); |
| br.reserve("..."); |
| br=bReserveHome.create("Moon"); |
| br. reserve(); |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Handle moonLibHandle = br.getHandle(); |
| ObjectOutputStream ostream = ... |
| ostream.writeObject(moonLibHandle); |
| ...... |
| ObjectInputStream istream = ... |
| Handle aMoonLibHandle = (Handle) istream.readObject(aMoonLibHandle); |
| BookReservation br2 = (BookReservation) javax.rmi.PortableRemoteObject.narrow(aMoonLibHandle.getEJBObject(),BookReservation.class); |
| br2. |
| br2. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Context initialContext = new InitialContext(); |
| Object result = initialContext.lookup("java:comp/env/ejb/myString"); |
| System.out.println(" myString :"+(String)result); |
| // prints: myString :Hello |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| <method> // selects all the methods |
| <ejb-name>BookReservation</ejb-name> |
| <method-name>*</method-name> |
| </method> |
| <method> // selects the given method |
| <ejb-name>BookReservation</ejb-name> |
| <method-name>reserveAll</method-name> |
| </method> |
| <method> // in case of overloading, specifies the method signature |
| <ejb-name>BookReservation</ejb-name> |
| <method-name>xxxx</method-name> |
| <method-params>java.lang.Interger</method-params> |
| <method-params>java.lang.String</method-params> |
| </method> |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Component type is specified in IDL and represented in the Interface Repository. Components are identified by a component references. |
Component type is specified with an IDL definition and the visible type description is called as the "surface" of the component through which clients and authoring applications can interact with the component. These surface features are called as ports and model introduces the following port types:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Facets represent a CORBA interface. |
| A component can support multiple interfaces. Clients of a component can navigate through these facets. |
| Components can be associated with values called primary key value identifying the instance of the component in its home context. |
| Association between primary key value and component instance is kept by the home. |
| Component Home is a manager for a specific component type to support life cycle and keep the association information about primary key value and the component instance, each home only manages one type of component. |
| IDL description of the component defines the supported interfaces. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Each component type description introduces a naming scope in which all the port descriptions related to the specified component is placed. |
| Component Implementation Definition Language (CIDL) is a declarative language for describing the structure and state of component implementations. |
| CIDL constructs: component, provides (interface declaration), uses (receptacle declarations), emits/publishes (event source), consumes (event sink), and attribute (attribute declarations). |
| Each provides keyword describes a provide_XX() selector method to obtain the reference to a specific facet. Component developer provides the implementation for these methods. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Navigation interface allows client to go from facet reference to the component reference, component reference to a facet reference, and gets the list of supported references by the component. |
| Component types only supports single inheritance. |
| When the component inherits from another component, it should also support all the interfaces supported by the base component. |
| Methods of any supported interface can be directly invoked on the specific facet reference as well as the component reference . |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A Use relation between two objects can be realized by using connection operation where a reference of one object is passed to its user |
| The user gets service from the object. This relationship is expressed with Receptacle concept. |
| Receptacle description is given in CIDL definition as well as the number of object references, 1:1 or 1:N. The description also contains the interface type of the connectable objects. This definitions produces connect_XX(), disconnect_XX(), and get_connections_XX() methods. |
| For example, |
| uses Multiplier mult; |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
definition produces:
|
| multConnection denotes a sequence of object reference and Cookie pair. |
| Cookie object represents the identifier for the connected object and is used for disconnection when the 1:N receptacle is in use. |
| Component's base interface also defines a generic Receptacle interface which supports the same operations without the specific names or interface types. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Component description specifies the event types that the component can consume via consumes keyword |
| The container is responsible for providing event service or notification service and encapsulates those events in Any type. |
| Event model is based on push model and components do not know the source of the event unless it has been designed by the component developer. |
| push_event() method is defined in EventConsumerBase interface. |
| A type specific event consumer interfaces are derived from EventConsumerBase interface with push_XX() methods exposing the specified event type. |
| consumes keyword produces: get_consumer_XX() and push() operations. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Event sources are defined with publishes or emitter keywords. |
| An emitter can be connected to at most one consumer. |
| A publishes can be connected to a number of customers (the upper limit can be enforced). |
| Container provides the necessary event channels for publish-kind events and consumer produces an event and hands it over to container to handle the broadcasting. |
| Emit-kind events do not require such broadcast service from the container instead the component directly executes the necessary method call on the consumer. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| publishes keyword description produces: subscribe_XX(), unsubscribe_XX(), and push() operations. |
| emits keyword produces: connect_XX(), disconnect_XX(), and push() operations. |
| A generic Events interface defines operations for general sink and source operations such as get_consumer(), subscribe(), unsubscribe(), connect_consumer(), and disconnect_consumer(). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A home description describes an interface for managing instance of a specified component type. |
| A Home definition may specify a primary key identifying component instances managed by a particular home. |
| Home definition supports single inheritance. |
| A home description contains the home type, inherited base home type (if any), managed component type, and primary key (if any). |
| Each produced Home definition describes the same operations specialized with the managed component type and the primary key type (if it is given). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| When the primary key is specified, then the specialized create(), find(), destroy() and get_primary_key() operations are defined. |
| Primary key value uniquely identifies a component instance in the context of the home. The implementation of Home keeps the association between the primary key value and the component instance. |
| create() operation creates a component instance. |
| home definition can also contain factory and finder definitions to specify a factory and finder operations. These descriptions contain the name and parameters of the operation. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| HomeFinder interface is defined to obtain the reference of the component's home interface. The implementation of HomeFinder interface is obtained from the ORB through resolve_initial_references("ComponentHomeFinder") call. |
HomeFinder interface supports the following operations:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A lifecycle of a component starts with the configuration phase and after the completion of this phase the component can be operational. To distinguish the phase transition configuration_complete() method is defined so that the agent can figure out whether the component is ready to serve or not as a result of this call on the component. |
| The configuration process uses attributes defined with attribute keyword in CIDL. |
| Configurator interface is defined for executing a set of attribute update operations on the target component. |
| configure() method executes the set of operations on the given target component. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A StandardConfiguration interface is derived from Configurator defines a set of operations to add a set of configuration values with set_configuration() method. |
| set_configuration() method accepts a sequence of name-value pairs where name denotes the attribute name and the value represents its value. |
| Home objects are configurable through HomeConfiguration interface allowing the caller to provide a Configurator object and/or a set of configuration values to be applied to instances created by the factory operations. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The container is the server's runtime support for a CORBA component implementation. |
| The container defines a set of interfaces available to a component client (external types), an API for the component developer (container type), a set of interactions between the container and the rest of CORBA such as POA, ORB and services (container implementation type). |
| Client's view of the component is described by Component IDL (CIDL) such as Home. These objects are stored in IR. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Container type defines a framework for a component developer. These interfaces are not CORBA objects therefore distinguished as local objects. |
| Container implementation type specifies the interaction pattern with the POA and CORBA services based on policies. |
| These descriptions are given in a component descriptor (XML). |
| These descriptions are used by the container factory to create a POA when the container is defined. |
| External types: Home interface and the application interfaces. Home interface contains factories for creating new objects and finders for existing objects. (EJBHome+EJBObject). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Container type
|
Container implementation type
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Component categories
|
| Component implementation is distributed with a deployment descriptor specifying the required CORBA services such as transaction, security, notification and persistence. |
| Container supports interfaces to the component to provide required services. |
| A container integrates transaction, security, events and persistence into a component's behavior at runtime. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Components and homes are deployed into containers by using configuration and deployment metadata. |
| Container communicates with the component a set of callback interfaces similar to SessionBean and EntityBean. |
| Components communicates with the container a set of internal interfaces similar to the EJBContext. |
| Transient objects are created but they do not need a finder pattern. |
| Persistent objects support either the factory or finder pattern based on component category. |
| CORBA components support single (serialize) and multiple threading. Component deployment descriptor specifies the threading model. EJB has a single thread model. |
| ORB->POA->Container->Component |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| In the EJB model, operations are invoked on the EJBObject while in the CORBA model the POA provides the necessary support to intercept the method dispatches. |
POA uses a Servant object to dispatch the incoming call to the object. Servant's lifetime policies are:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Transaction policies are also defined in the component's deployment description. Based on the policy, the container makes the proper Transaction service calls. The supported transaction policies are:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Security policies are defined in the component description. |
| The container enforces the necessary credential checking on the current client before executing the method. |
| Support for events are provided by the container and container manages the event channels and sets the filters on them. |
| The quality of service requirements are defined by the component's deployment description. |
| Quality of service enforces that the events should be emitted or consumed within a transaction (transactional), with a transaction if one exists (default), and outside of the transaction (normal). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Persistence support handled by the container (container-managed) or the component itself (component-managed). |
| When the container-managed persistence is in use, the component only defines what the state of a component is (storage in CIDL) and the container saves and restores the state of the component. |
| When the component-managed persistence is in use, the container invokes the callback operations on the component to save and load itself therefore it is component's responsibility to handle those persistency related operations. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Component types are service, session, process and entity. |
| Service components : the lifetime of the service component is limited to the lifetime of the method invocation therefore it has no state and identity. |
| Session component : the life span of the session component described in the servant-lifetime description. These components has transient state living through the lifetime of the client interaction and non-persistent identity. This matches with SessionBean in EJB. Stateless Session Beans is a Session component with method servant lifetime policy and Stateful Session Beans is a Session component with transaction or container servant lifetime policy. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Process component : the component has a persistent state which is not directly visible to the client unless the component provides other methods to expose it. Since it has a persistent state, it also has a persistent identity. This component type is suitable for representing business process such as creating an order. Process component can implement the Stateful SessionBeans when its behavior is non-transactional. |
| Entity components : This component has a persistent state and its behavior may be transactional. The identity of the component is visible to its clients through primary key so that the persistent state is made visible to clients. This component can implement the EntityBean in EJB. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
The APIs for interactions between a component and container are called as Server Programming interfaces. The container exposes the following interfaces in addition to the component type specific interfaces.
|
| All the mentioned interfaces are provided through EJBContext in EJB. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| ComponentContext provides an accessor operations for a component to obtain the references to various service interfaces. This interface is aligned with the EJBContext interface except that EJBContext interface contains the operations related to various services while ComponentContex only returns a reference for various service provider interfaces. |
| EJBContext is specialized to SessionContext for SessionBeans and EntityContext for EntityBeans based on component type while the CORBA model provides the necessary context interfaces based on the container type. |
| ComponentContext interface is used to get the reference to Home, BaseOrigin, Transaction, HomeRegistration, Security, and Events interfaces. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Home interface supports factory and finder patterns for a component and described in home CIDL keyword. |
| BaseOrigin defines an operation (req_passivate()) to be invoked by the component to declare that it wants to be passivated. (Handle in EJB and Monikers in COM) |
| Transaction interface provides a functionality for transaction services. |
| The transaction policy can be set by the component deployment descriptor like MTS and EJB or component developer makes direct use of transaction service. When the component uses the transaction service functionality, there might be some restrictions since the component has to interact with the current transaction that the container and the client also interact with. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Transaction interface supports begin(), commit(), rollback(), get_rollback_only(), set_rollback_only(), suspend(), resume(), get_status(), and set_timeout() operations. This interface is equivalent to the UserTransaction in EJB with additional get_rollback_only(), suspend(), and resume() operations. |
| HomeRegistration interface is used by component to register its Home interface. |
| HomeRegistration interface contains register_home() and unregister_home() operations. |
| The clients find the Home interface of a component from HomeFinder interface which is obtained from the ORB with resolve_initial_references("ComponentHomeFinder") call. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| HomeRegistration interface registers the Home interface in the local ORB where the component lives. It is also possible to register a Home interface which leaves in another ORB through RemoteHomeRegistration interface. |
| Security interface allows the component to get the credentials associated with the operation (set by the client and the container based on the deployment descriptor) and the caller. |
| There are two operations get_caller_identity() and is_caller_in_role(). EJBContext interface contains similar operations. (programmatic security). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Events interface provides operations for emitting and publishing events as well as subscribing to events produced by other sources. (EJB does not have one yet. But JMS most likely will be combined with EJB for this purpose). |
| All components implement EnterpriseComponent interface containing no operation. This interface is equivalent to EnterpriseBean interface in EJB. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| TransientContext is derived from ComponentContext interface and contains get_transient_origin() operation to obtain a reference to a TransientOrigin interface. |
| TransientOrigin is derived from BaseOrigin and contains an operation (create_ref()) to create references for components deployed in a transient container type. |
| ServiceComponent is derived from EnterpriseComponent and defines an operation (set_transient_context()) called by the container after the instantiation of the component outside of any transaction. |
| SessionComponent is derived from ServiceComponent and defines operations to remove the component from a context (remove()), activate the servant (activate()) and passivate the servant (passivate()). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| activate() method is called by the container to notify that it has been activated. |
| passivate() is called by the container to notify that it has been deactivated and expected to release any resource held by the component instance. |
| remove() is called by the container t notify the component instance that the servant is about to be destroyed so that it will to. |
| Synchronization interface is defined to notify the component instance about the transaction boundaries (before_completion() and after_completion()). (SessionSynchronization in EJB) SessionSynchronization also contains after_begin() call to notify the beginning of a transaction. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
PersistentContext is derived from ComponentContext and provides operations to obtain the reference for
|
| EntityContext in EJB supports the similar services. |
| ComponentId interface provides operations to locate a component's persistent state in a persistent storage. |
| PersistentOrigin interface is derived from BaseOrigin and provides operations to create and obtain object references. |
| Storage interface defines operations to access the CORBA persistence service. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| PersistentComponent interface is used by container as a callback interface for component instance. |
| PersistentComponent contains operations related to management of persistent state. PersistentComponent is equivalent to EntityBean in EJB. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A storage keyword defines the abstract state of an executor (i.e., a component implementation) |
| Component can also manage their storage types. |
| A storage object associates an identity (Persistent ID or PID) with a state information. A PID value uniquely identifies a storage object in the persistent store. |
| A storage object is created and managed by a persistent store through the agency of a storage home. |
| A persistent store is a primary point of contact between the application and the storage mechanism. |
| A persistent store manages storage homes through which component implementations can create, incarnate, and destroy storage objects. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A storage home defines an interface for managing instances of a specified storage type. |
| A storage home definitions can introduce a primary key definition. This produces a factory, finder, and destructor operations related to this primary key definition. |
| A storage home interface includes operations to create storage objects, find incarnations of storage objects, and destroy instances of the storage type associated with the manager. |
| A storage home is responsible for maintaining mapping between primary key values and storage objects. |
| On creation of a storage object, storage home assigns a persistent id (unique into Persistent Store) and StorageHomeBase. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Package and deployment specification describes the software components, their connections, deployment placement, and component customization. |
| CORBA Component packaging and deployment descriptions are extended from the Open Software Description (OSD) proposal by Marimba and Microsoft. |
| OSD proposes an XML DTD to describe software packages and their dependencies. |
| A component package describes one component. |
| A component assembly package contains a set of component packages, and an assembly descriptor. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| An assembly descriptor specifies the components partition (deployment) constraints and their connections. |
| Connections are between provides and uses ports and emits an consumes ports. |
| A deployment tool deploys each component, customize (if necessary), and establishes necessary connections between them. |
| All these files can be placed in a ZIP archive file with ".car" extension. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| CORBA Software Descriptor is placed in a file with ".csd" extension and extracted into meta-inf directory when the archive file is unzipped. |
| A software package descriptor keeps a general information about the software such as name, version, author, codebase, company, compiler, dependency, licence, operating system,..etc.). |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Component descriptor specifies the characteristics of a component to be used at assembly and deployment time. |
| Component descriptor gives the interfaces supported by the component and its base component type and the ports. |
| Ports are defined as interfaces that the component uses and provides. |
| Event that the component emits and consumes. |
| Component descriptor is placed in file with ".ccd" extension because of CORBA Component Descriptor. |
| The component descriptor is used to decide the type of container in which the component needs to be installed. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Component Assembly Packaging describes the deployment of interrelated components. |
| Component Assembly Archive file (with ".aar" extension) contains a component assembly descriptor, a set of component archive files (component packages), and (optional) a set of property files. |
| The component assembly descriptor describes which components make up the assembly, how those components are partitioned, and how they are connected to each other. |
| An assembly is normally created with a visual design tool. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Component Assembly Descriptor is defined in XML and the file extension is ".cad". |
| CAD contains the components, connection information, and partition information. |
| Connections are between provides and uses interfaces and emits and consumes event types. |
| Partition information defines whether two component should be co-located or not. |
| CAD file is also opens into "meta-inf" directory. |
| Property File Descriptor is in XML format and ".cpf" extension. PFD specifies property (attribute) settings related to component and its home. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| At deployment time, a configurator sets component and component's home attributes based on the PFD definition. |
| Deployment process initializes components (on target hosts) and its homes, then it establishes connections between components. |
| Deployment information is obtained from an individual component file and an assembly file. |
Deployment process goes through the following steps:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Deployment process uses various helper objects to carry out this complicated process. |
| After the component implementations are installed, the deployment application uses the Installation object to make sure that the component implementation is available on the host. |
| The deployment application creates an Assembly object for coordinating the creation and destruction of component assemblies. Assembly objects are created from AssemblyFactory object. |
| AssemblyFactory interface operation accepts the name of an assembly descriptor file and initialize the Assembly object based on the settings. Assembly object handles the rest of the deployment process. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Assembly object calls the ServerActivator object on the target host to create a component server (create_component_server()). Each host has only one ServerActivator object. |
| Create_component_server() returns a reference to ComponentServer containing nothing yet. |
| Assembly object calls create_container() with a container identifier or attributes on the ComponentServer to create a proper container for the component. |
| Create_container() call returns a Container object. |
| Container interface is used to install the home interface into the container. Assembly object invokes install_home() with a component id parameter on the Container interface to obtain a reference to the component's home interface. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Container object uses Installation object to obtain the component's implementation specifics (get_implementation()) and loads DLL, or shared object library, or necessary .class files. |
| Assembly object uses component's home object to create a component instance (create_component()). |
| Create_component() call returns a reference to ComponentBase interface and Assembly object applies Configurator on this object to configure the component. |
| After Assembly object instantiates all the necessary components, it starts connection process by calling receptacle connect operation on the proper ComponentBase references. |
| After Assembly object completes the connection process, it calls configuration_complete() method on all the ComponentBase references. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The container is a server-side framework built on the ORB, the Portable Object Adaptor (POA), and a set of CORBA services which provides the runtime environment for a CORBA component. |
| The type of container describes the interaction with the POA on the ORB. |
| ContainerManager object is a factory pattern for containers. ContainerManager uses the container specification to set up the POA with proper policies and a set of CORBA service bindings for container usage. |
| Creating a container involves the creation of POA. This approach uses SevantLocator since its ServantManager interface allow a container to intercept all requests to a component. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Microsoft Transaction Server (formely known as Viper) is available since Microsoft windows NT version 4.0 Service Pack 4. |
| Microsoft Transaction Server (MTS) defines a set of COM interfaces for developing distributed components and an infrastructure for deploying and administering three-tier solutions. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Microsoft Transaction Server (MTS) provides a DLL surrogate (mtx.exe) along with the MTS Executive (mtxex.exe). mtx.exe DLL surrogate can be seen as the ultimate surrogate for DLLs. |
| EXE-based components are not supported since they cannot be loaded into the address space of MTS. |
| MTS manages transactions, and provides an object manager functionality, a thread pool management, a security management model to define a basis for distributed application framework leading to a COM+ framework. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS acts as a transaction processing monitor for online transaction processing (OLTP). |
| MTS uses the Microsoft Distributed Transaction Coordinator (MS DTC) which is originally developed for Microsoft SQL Server. |
| MS DTC supports two-phase commit protocol and provides an implementation for four interfaces: ITransaction, ITransactionDispenser, ITransactionOptions, and ITransactionOutcomeEvents. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
MTS requires the following features from the component to give its services:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS supports an just-in-time activation by late object creation and early object deactivation. |
| MTS tries to utilize the resources of server so that servers can be more scalable than it would be. |
| The real activation of an object is delayed until client invokes the first function call on the interface. |
| The deactivation of an object does not wait until the reference counts drops to zero, MTS can deallocate the object while some client still has the valid reference to this object. In a case a client wants to use the same interface again then MTS recreates the copy of the object and client never knows which object is in use. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS introduces two interfaces: IObjectControl and IObjectContext to do this magic. |
| IObjectControl interface has three functions: Activate(), Deactivate() and CanBePooled(). |
| MTS queries the IObjectControl interface when it instantiates the object. If this interface is supported, then MTS can use Activate() function before the instantiation of the object and Deactivate() function before the deactivation of the object. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| CanBePooled() function returns whether an object is recyclable. If object can be recycled, then this means that this object can be used by another client who would like to use an object to this same interface. |
| MTS tries to address the recycling issue by introducing a distinction between the state of the object and the its code (behavior). |
| MTS provides several hooks to save the state information for later reincarnation of the object. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
The state information can be kept in:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS defines an implementation of IObjectContext interface for each running object in the server. |
| IObjectContext interface contains CreateInstance() function and extends from IUnknown interface. |
| GetObjectContext() function in MTS gets the pointer to the IObjectContext interface if object defines this interface, then MTS does not need to provide a default one. Under the control of MTS, instantiation of an object should be done with CreateInstance function of IObjectContext interface instead of CoCreateInstance function since an object created from IObjectContext interface can inherit the activity, transaction, and security identities from the creator's context object. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
IObjectContext also defines the following functions:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| All MTS components are distributed in packages that is a named unit of deployment. |
| A package in MTS contains one or more components and each component can contain one more classes, called as MTS Object. |
| Each package is assigned a unique GUID and a profile in the catalog that contains a set of properties. |
| Configuration information of components and packages running on MTS stored in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TransactioServer tree. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| A server package provides a surrogate process for running MTS objects. |
| MTS allows only a single instance of any package to run on a machine at a time therefore it does not allow launching user as a security principal. |
| Each MTS component has associated class identifier (CLSID) registered under HKEY_LOCAL_MACHINE\CLSID tree. |
| MTS Explorer is the main configuration utility and changes the Registry for each registered component to be able to launch mtx.exe. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| The LocalServer32 subkey of the registered MTS component contains the following setting: |
| \System32\mtx.exe /p:{'package-identifier-number'} |
| mtx.exe process is created for each package if the package is not running already. |
| A library package is loaded into the client's address space. |
| A library package provides a support for sharing component code. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS Executive is implemented in mtxex.dll and the main controller for objects in MTS. |
| MTS Executive is a control freak object, therefore it likes to intercept every call made on the objects living in MTS environment. MTS Executive intercepts the request coming from SCM to create a new object. MTS Executive defines a wrapper object called context wrapper (IObjectContext) to monitor all the incoming and outgoing calls from object (call-by-call basis continuous monitoring). |
| The MTS Executive and the application DLLs (MTS components) are loaded into the surrogate called mtx.exe. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Context wrapper places itself between the object and the stub. |
| MTS fully takes advantage of interceptor concept since context wrapper intercepts before every function call. |
| Context wrapper object stores the state information about object and its creator (security credentials). Because of strong control on MTS Objects, MTS can postpone actual activation of an MTS object until the first function call is made on the object. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS defines four states in the lifecycle of any MTS object: creation, activation, deactivation, and destruction. |
| Creation refers that the context wrapper object is created. |
| Activation refers that the object kept in the context wrapper is realy activated and running. |
| Deactivation refers the state that the object is released from memory but the context wrapper is still available. |
| Destruction refers that the context wrapper for the object is also released. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| IObjectControl interface is used by MTS to inform the server object about the state changes of an object. |
| MTS defines a new concurrency abstraction called an activity. An activity is a logical thread of execution created on behalf of a single base client. Activity represent a set of objects that belong to a single user. MTS creates a new STA for each new activity until the STA pool reaches its limit (100). After the limit, MTS starts starting multiple activities to each STA. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS introduces a new security model called declarative security. |
| In this concept, users and/or groups are collected into a named sets called role which is an abstraction defining a logical group of users. These roles are unique in each MTS package (collection of MTS components) and central to the MTS security model. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Administrator defines which NT user groups and accounts (individual user) are associated with each role by using MTS Explorer. This allow MTS to enforce security restrictions per interface level since a mapping between roles and components defines which roles can access which components. |
| A role defines a set of users who have access to components in that package. |
| MTS Explorer is used for defining associations between roles and components in MTS environment. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| With the introduction of role concept, components are detached from the real users. |
| Components uses the caller's or launching user's credentials for security purposes. |
| MTS defines an account for each package called identity and components can use this identity to act on the original user's behalf. |
| MTS defines a special package named System for administrative access to MTS Explorer. By including roles in System package it is possible to restrict the administrative access to particular accounts. Each component within a package checks the validity of each user against a set of roles defined for that package. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| MTS can query the role of the caller and verifies its credentials by using IsCallerInRole() function in IObjectContext interface. |
| The same function can be used to enforce programmatic security in case the role based security is not enough. |
| Some functions might want to allow a certain functionality to the some roles (such as amount of order). Instead of defining a different interface for the same functionality, developer can get the role information and changes the behaviour of the process according to the callee's role. |
| Before using IsCallerInRole() function, it is recommended to see whether some security restrictions are applied to the component. IsSecurityEnabled() function in IObjectContext interface returns FALSE, if the component is installed in in-process server. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| In transactional environment, servers should get resources (database connection) as late as possible and give them up as soon as possible. |
| SetComplete() function should be called as often as possible so that MTS keeps less object around and it helps scalability. |
| MTS introduces a concept called resource dispenser. |
| Resource Dispenser interface abstracts any resource from the actual implementation and allows developer to manage the resources properly such as caching. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
| Caching and resource pooling requirement raised in the database access services since the connection to database takes some time. For example, a resource dispenser can cache ODBC connections to database and recycles them. |
| Transaction Attributes: |
| Requires : either uses a new transaction or client's transaction. |
| Requires new : a new transaction is created for the object. |
| Supports : it can run with/without a transaction context. |
| Not support: it should be run without a transaction context. |
| MTS Explorer is used to set the transaction attribute. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Services:
|
| Both service requirements can be defined within the deployment descriptors. |
Persistence
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Component types:
|
Threading model:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Metadata about the components:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Home and Finder Interfaces
|
How these interfaces are obtained by the client:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
Multiple interfaces
|
Uses Relationship:
|
| CORBA Component model introduces an event model and components can be connected to each other with these event channels. EJB most likely will promote JMS in this area. But there is no specific design for event based connection of components. |
HTML version of Basic Foils prepared July 6 99
Full HTML Index
ACID stands for:
|
ACID provides:
|
HTML version of Basic Foils prepared July 6 99
Full HTML Index
OSI TP is defined in December 1992 specifies the two-phase commit protocol with the following steps:
|