Overview of EJB’s Software Architecture
|
Overview of EJB’s Software Architecture
The diagram presents a high-level view of the EJB architecture, showing the various relationships between the various components.
|
|
This illustrates the Key Features of the EJB Architecture
|
EJB Logical Architecture
|
EJB Logical Architecture |
|
· A EJB system is logically a three-tier system · The three tiers are as follows: a) The Client b) The EJB Server c) The Database (or other persistent store) · This is a logical architecture because these tiers don’t necessarily have to reside on three different machines. · For example, a) The EJB server and the database might reside on the same machine, when the EJB server includes built-in functionalities for persistent storage. b) The client and the EJB server might reside on the same machine, when an EJB bean makes a call to another bean in the same container. The caller bean is acting as a client here. c) These two cases can be combined to have all the tiers in a single machine. · EJB’s role in each of these tiers are: a) A program on the client side makes call to remote EJBs. The client needs to know how to find the EJB server and how to interact with the objects that reside on the EJB server. b) The EJB components live in the middle tier. The EJB objects reside inside an EJB container, which in turn resides in an EJB server. c) EJB can access the database themselves, typically via Java Database connecting (JDBC), or they can allow the container to handle their data storage needs for them.
|
EJB’s Role
|
EJB’s Role |
|
1. EJB Specifies an execution environment · The container is responsible for providing services to EJB. · An EJB is a Java class that implements either the Session Bean or the Entity Bean Interface. · The container provides services such as support for transactions, support for persistence, and management of multiple instances of a given bean. · The container does not allow the bean to be accessed directly from the client; rather, the container provides a proxy object for each bean. · This approach gives the container a high degree of freedom in managing the beans and insulates the bean themselves from the outside world. |
|
2. EJB exists in the middle-tier · EJB, like other middle-tier components are used to encapsulate business rules. · A typical EJB consists of methods that encapsulate business logic. · A remote client can invoke these methods, which typically result in the updating of a database. |
|
3. EJB supports transaction processing · An EJB container must support transactions · When the bean is deployed, the container reads this information and provides necessary support. · Possible types of transaction support: i. Requiring that the client provide an open transaction context. ii. Requiring that the container start a new transaction when the bean is invoked. iii. Requiring that the bean be allowed to manage its own transaction. |
|
4. EJB can maintain state · CGI scripts are handy because they work against a well-defined interface. · A CGI application has no built-in mechanism to store state information. · Each invocation of a CGI application is therefore a fresh start. · If the developer would like to build an application with several screens that handles complex input, CGI is not suitable. · EJB can maintain state across several method invocations. · The EJB container keeps track of any state information that a bean needs. · Stateless bean can also be created.
|
|
5. EJB can maintain state · CGI scripts are handy because they work against a well-defined interface. · A CGI application has no built-in mechanism to store state information. · Each invocation of a CGI application is therefore a fresh start. · If the developer would like to build an application with several screens that handles complex input, CGI is not suitable. · EJB can maintain state across several method invocations. · The EJB container keeps track of any state information that a bean needs. · Stateless bean can also be created. |
|
6. EJB is simple · The EJB container handles all the responsibilities and runs on the server environment. So, developer work load is much reduced. · Even the developer need not worry about the multithreaded code, because the container handles concurrent requests. · Because the bean is a middle-tier object, an EJB developer does not need to create any user interface logic. · The developer must write only the code necessary to implement the application’s business rules and manage its data. · EJB brings together several trends in computing: i. Transaction processing ii. Persistent storage of objects iii. Platform independence iv. Multithreaded architecture · EJB provides all of these features in a straight forward, portable, easy-to-use framework. · Because an EJB bean can run in any EJB container, the potential exists for a new market in business-logic middleware. · Write Once, Run Anywhere.
|
Component Requirements
|
Component Requirements |
|
The advantage of using components result directly from their ability to dynamically plug into and unplug from an application. In order to achieve this capability , components must meet two requirements. 1. Components must link dynamically 2. Components must hide (or encapsulate) the details of how they were implemented. 1. Dynamic Linking · The ultimate goal of this is to have an end user replace components in an application while that application is running. · Support for changing components at run time requires the ability of dynamically link components together. · In distributed environment there is no assurance that the component will be idle for modification. So, components should have facility to update or replace them while it is used by other system in the network. 2. Encapsulation · A program or a component that uses another component is called the client. A client is connected to a component through an interface. · If the component changes without changing the interface, the client doesn’t have to change. Similarly, if the client changes without changing the interface, the component doesn’t have to change. · However, if changing either the component or the client changes the interface, the other side of the interface must also change. · Therefore, to take advantage of dynamic linking, components and clients must strive not to change their interfaces. They must be encapsulated. · The more the interface is isolated from implementation details, the less likely the interface will change as a result of changing the client or the component. · If the interface doesn’t change, changing a component will have little effect on the rest of the application. Isolating the client from the component’s implementation puts some important constraints on the component. The following is a list of these constraints. 1. The component must hide the computer language used for its implementation. Exposing the implementation language creates new dependencies between the client and the component. 2. Components must be shipped in a binary form. If components are to hide their implementation language, they must be shipped already compiled, linked and ready to use. 3. Components must be upgradable without breaking existing users. New versions of a component should work with both old and new clients. 4. Components must be transparently relocatable on a network. A component and the program that uses it should be able to run in the same process, in different processes, or on different machines. The client should be able to treat a remote component the same way it treats a local component. |
COM : Fundamentals
COM
- COM is a specification
- It specifies how to build components that can be dynamically interchanged.
- COM provides the standard that components and clients follow to ensure that they can operate together.
- The COM specification is a document that sets the standard for the component architecture.
What are COM Components?
- COM component consists of executable code distributed either as Win32 dynamic link libraries (DLLs) or as executables (EXEs).
- Components written to the COM standard meet all requirements for component architecture.
- COM components link dynamically using DLLs.
- COM components can be encapsulated easily because:
o COM components are fully language independent. They can be developed using almost any procedural language Ada to C to Java to Modula-3 to Oberon to Pascal.
o Any language can be modified to use COM components, including Smalltalk and Visual Basic.
o COM components can be shipped in binary form.
o COM components can be upgraded without breaking old clients. Because it provides a standard way to implement different versions of a component.
o COM components can be transparently relocated on a network. A component on a remote system is treated the same as a component on the local system.
- COM components announce their existence in a standard way. Using COM’s publication scheme, clients can dynamically find the components they need to use.
- COM components are a great way to provide object-oriented APIs or services to other applications.
- COM components are also great for building language-independent component libraries from which applications can be rapidly built.
COM is not…
- COM is not a computer language.
- COM does not compete with computer languages.
- COM tells how to write components.
- COM also does not compete with or replace DLLs.
- COM uses DLLs to provide components with the ability to dynamically link.
- COM is not primarily an API or a set of functions like the Win32 API.
- COM does not provide services such as MoveWindow or the like.
- COM is not a C++ class library like the Microsoft Foundation Classes (MFC).
- COM provides a way to develop language-independent component libraries, but COM does not provide any implementation.
The COM Library
- COM has an API, the COM library, which provides component management services that are useful for all clients and components.
- Most of the functions in the API are not too difficult to implement when developing COM-style components on a non-Windows system.
- The COM library was written to guarantee that the most important operations are done in the same way for all components.
- The COM library also saves developers time implementing their own components and clients.
- Most of the code in the COM library is support for distributed or networked components.
- The Distributed COM (DCOM) implementation on Windows System provides the code needed to communicate with components over a network.
- This reduces to write the networking code.
November/December 2007 Question Paper
MAY/JUNE 2007 Question Paper
COM and CORBA Side by Side
.
|
Trait |
Similarities |
Differences |
|
Interfaces |
Each uses their own IDL to describe interfaces. |
CORBA IDL is simpler an elegant than COM IDL COM has better tool support for creating and managing IDL than CORBA |
|
Datatypes |
Both support a rich set of data types Both also support constants, enumerated types, structures and arrays. |
COM has automation types. Automation compatible interfaces are supported in more client environments than non-compatible interfaces. Because the non-compatible interfaces are not guaranteed to work other than C++. Any CORBA interface can be used from any CORBA client |
|
Proxies, Stubs & Skeletons |
COM and CORBA rely on client stubs and server stubs to handle remoting issues. COM & CORBA generate client stubs and server stubs from IDL. |
COM client & server stubs are called as Proxy & Stub and in CORBA called as Stub & Skeleton. COM proxy-stub DLLs are used by all language environments. In CORBA, a separate stub-skeleton must be generated for each ORB/language combination. |
|
Marshaling & Unmarshaling |
COM and CORBA handle marshaling in client stubs and server stubs. Users do not need to worry about marshaling. |
COM allows automation-compatible interfaces to use type library marshaling, thus eliminating the need for customized stubs. |
|
Object Handles |
COM & CORBA support reference counted handles on object instances. |
COM calls object handles as interface pointers and CORBA calls as object references. CORBA supports multiple inheritance in the interface hierarchy. COM supports single inheritance only; however a COM object supports more than one distinct interface. |
|
Object Creation |
Both use factories to create objects instances. |
COM has a standard factory interface called IClassFactory CORBA factories are customized persistent CORBA objects. |
|
Object Invocation |
Both allow for method invocation similar to native environment method invocation. |
COM’s error-handling mechanism is based on HRESULT return values. CORBA supports user-defined exception types in IDL. |
|
Object Destruction |
COM and CORBA rely on reference counting to determine when an object can be destroyed |
COM supports distributed reference counting and garbage collection. CORBA reference counts are maintained separately in the client and server. |
