A software component is code that implements a set of well-defined interfaces. It is a manageable, discrete chunk of logic.Components are not entire applications-they cannot run alone.Rather.they can be used as puzzle to solve pieces to solve some larger problem.a company can purchase a well defined module that solves a problem and combine it with other components to solve larger problems. For example, consider a software component that computes the price of goods. This pricing component will have all pricing information about a set of products and calculates the total price of the product. Now suppose we are using this pricing component when we are are buying computer parts. The pricing component may be calculating the price based some pricing rules such as base prices,quantity discounts, bundling discounts, preferred customer discounts, local discounts, locale discounts, overhead discounts.These pricing rules are not unique to ordering computer parts such as health care, appliances and others.It would be a huge waste of resources if each company that needed complex pricing had to write its own sophisticated engine. Thus,it makes sense for a vendor to provide a generic pricing component that can be reused over and again for different components. For example, the postal service can use it for computing shipping costs for mailing packages.An automobile manufacturer can use the pricing component to discriminate price for cars.An online grocery store can use it as a discrete part of a complete workflow solution. The advantages of reusable components are: 1.The IT shop needs less in-house expertise as it does not need experts in complex pricing algorithms. 2. The application is assembled faster. 3.There is lower total cost of ownership. Component Architectures To facilitate the component development process there should be a standardised way to build,manage and maintain components.This approach consists of the following: Tools for developing components- The process of building components should be streamlined,allowing the developer to focus on writing the core logic behind the component. This promotes rapid application development and is essential for any component standard to succeed.For example,an Integrated Development Environment(IDE), such as Sysmantec’s Visual Café, IBM’s Visual Age for Java, or Inprise’s Jbuilder 2,assists Java developers in rapidly building and debugging components.Other vendors such as Inline Software, provide EJB-specific development tools. 2. A container that manages your deployed components-This component container provides a run time environment for your components to play in. It also provides a set of common services that most components will need.For example,the container could automatically instantiate new components as necessary, thus removing that burden from the component developer. To combine any container with any component, you must have a well defined contract between containers and components. 3. Tools for deploying and maintaining components- When an organization purchases components from component vendors, there must be a set of tools to aid in the deployment and maintenance of those components. For example,there should be a way to customize the components for a particular environment.In our pricing component example,we could have a tool that assists in customising the products we are pricing Component Architectures in Java. Let us look at what component architecture exist in Java. The first one is JavaBeans. JavaBeans components are small grained application bits.You can use JavaBeans to assemble larger grained components or to build applications.JavaBeans however are deployment components and not deployable components.You typically do not deploy a JavaBean because a Javabean is not a complete application; rather,JavaBeans helps you construct a larger software that is deployable.And because they cannot be deployed JavaBeans do not need a runtime environment in which to live.JavaBeans do need a container to instantiate them, to destroy them and to provide other services to them because the application itself is made up of JavaBeans. Enterprise Javabeans satandard defines a component architecture for deployment components called enterprise beans.Enterprise beans are larger,coarser-grained application components that are ready to be deployed.They can be deployed as is,or they can be assembled with other components that are ready to be deployed . They can be deployed as is,or they can be assembled with other components into larger applications systems.Deployable components must be deployed in a container that provides runtime services to the components as needed.
J2EE simplifies many of the complexities surrounding the construction of a scalable,component-based server-side application and it is very analogous to Windows DNA.The most notable exception is that J2EE.The most notable exception is that J2EE is a specification whereas Windows DNA is a product.J2EE specifies the rules of engagement that people must agree on when writing enterprise software.Vendors then implement the J2EE specifications with their J2EE specifications with their J2EE –Compliant products.Because J2EE is a specification it is inherently not tied to one vendor ;it is inherently not tied to one vendor; it also supports cross-platform development.This encourages vendors to compete,yielding best of breed products. Why J2EE? After EJB 1.0 was finalized the first EJB-based application server began servers began to arrive on the market(BEA’s Weblogic was the first). These application servers took advantage of other Enterprise API’s as well, such as the ones for naming and lookup services,for transactions , and for database operations. The early application servers highlighted many problems with the Enterprise API’s.These include the following: Ambiguities:The unspecified sections of the Enterprise API’ s specifications hampered portability of component. This is unacceptable
JNDI’s architecture is somewhat like Java Database Connectivity package (JDBC): 1.In JDBC, there is uniform client API for performing database operations. In JNDI,naming and directory service client invoke a unified API for performing naming and directory operations. 2.IN JDBC, relational database vendors provide JDBC drivers to access their particular databases.In JNDI, directory vendors provide JDBC drivers to access their particular databases.In JNDI,directory vendors vendors provide service providers to access their specific directories.These providers are aware of specific directories. These providers are aware of specific directory protocols and they plug in to the JNDI SPI. For example, Sun Microsystems gives away an LDAP service provider for free. The LDAP service provider knows how to map a JNDI client API operation into an LDAP operation.It then executes the LDAP operation on an LDAP directory using the specific LDAP protocol.
A naming system is a connected set of contexts. For example, a branch of an LDAP tree could be considered a naming system,as could a folder tree in a file system, as could a folder tree in a file system. Unfortunately, naming systems each have a different syntax for accessing contexts.For example, in a LDAP tree, a compound name is identified by a string such as “cn=Ed Roman”, ou=people,o=Middleware-Company.com,c=us”,whereas a file system compound name might like “c:javalibclasses.zip” . Within a naming system a namespace is all the names contained within that naming system. The hard drive’s entire collection of filenames and directories or folders are the hard drive file system’s namespace. A composite is a name that spans multiple naming systems. For example on the Web, the URL http://java.sun.com/products/ejb/index.html is composed from the following namespaces: http comes from the URL scheme-id namespace.You can use other scheme-id’s such as ftp and telnet. This namespace defines the protocol you use to communicate. Java.sun uses the Domain Name Service(DNS) to translate machine names into IP addresses. Products and ejb and index.html are from the file system namespace on the Web server machine.
The above slide gives an explanation of java.rmi.registry package. This is a direct mapping of the student guide. The faculty can refer the student guide to give explanation about each of the interfaces and class. The Javasoft explanation of this package is given below: Provides a class and two interfaces for the RMI registry. A registry is a remote object that maps names to remote objects. A server registers its remote objects with the registry so that they can be looked up. When an object wants to invoke a method on a remote object, it must first lookup the remote object using its name. The registry returns to the calling object a reference to the remote object, using which a remote method can be invoked.
The above slide gives the definition of java.rmi.server package. This is a direct mapping of the student guide, so the faculty can refer the student guide to explain the classes and interfaces in the package. The Javasoft explanation of this package is given below: Provides classes and interfaces for supporting the server side of RMI. A group of classes are used by the stubs and skeletons generated by the rmic stub compiler. Another group of classes implements the RMI Transport protocol and HTTP tunneling. There are some more classes, interfaces and exceptions that thrown by the classes of this package. Explanation of the classes, interfaces and exceptions of the package is given below and as defined by Javasoft: The faculty can encourage interested students to gather more information on this. Interfaces LoaderHandler: Deprecated. no replacement RemoteCall: Deprecated. no replacement. RemoteRef: RemoteRef represents the handle for a remote object. RMIClientSocketFactory: An RMIClientSocketFactory instance is used by the RMI runtime in order to obtain client sockets for RMI calls. RMIFailureHandler: An RMIFailureHandler can be registered via the RMISocketFactory.setFailureHandler call. RMIServerSocketFactory: An RMIServerSocketFactory instance is used by the RMI runtime in order to obtain server sockets for RMI calls. ServerRef: A ServerRef represents the server-side handle for a remote object implementation. Unreferenced: A remote object implementation should implement the Unreferenced interface to receive notification when there are no more clients that reference that remote object. Classes LogStream: Deprecated. no replacement ObjID: An ObjID is used to identify remote objects uniquely in a VM over time. Operation: Deprecated. no replacement UID: Abstraction for creating identifiers that are unique with respect to the the host on which it is generated. Exceptions ExportException: An ExportException is a RemoteException thrown if an attempt to export a remote object fails. ServerCloneException: A ServerCloneException is thrown if a remote exception occurs during the cloning of a UnicastRemoteObject. ServerNotActiveException: An ServerNotActiveException is an Exception thrown during a call to RemoteServer.getClientHost if the getClientHost method is called outside of servicing a remote method call. SkeletonMismatchException: Deprecated. no replacement. SkeletonNotFoundException: Deprecated. no replacement. SocketSecurityException: A SocketSecurityException is thrown during remote object export if the code exporting the remote object (either by construction or by explicit call to the exportObject method of UnicastRemoteObject or java.rmi.activation.Activatable) does not have permission to create a java.net.ServerSocket on the port number specified during remote object export
Session 1 Tp1
Session 1 Introduction to Enterprise Java Beans
Component Architecture <ul><li>Components are building blocks of an application </li></ul><ul><li>Provides a set of services or functions, such that it can easily interact with other applications or components </li></ul><ul><li>Consists mainly of Web components, business logic components, and service components. </li></ul><ul><li>Web components consist mainly of JSP and Servlets, the business logic component consists of EJB and the services component primarily consists of JavaMail, JNDI, JMS, JTS, JDBC, and RMI-IIOP. </li></ul>
Evolution of Enterprise JavaBeans <ul><li>EJB was developed so that it would: </li></ul><ul><ul><ul><li>* Specialize in handling the business logic of an application </li></ul></ul></ul><ul><li>* Be robust </li></ul><ul><li>* Be secure so that it cannot be tampered. </li></ul><ul><li>EJB Component has been designed to encapsulate business logic. </li></ul>
Distributed Object Architecture Running HTML and Java Script
RMI Architecture <ul><li>RMI Application consists of </li></ul><ul><li>* Server </li></ul><ul><li>* Client </li></ul><ul><li>RMI defines two types of objects </li></ul><ul><li>* Stubs </li></ul><ul><li>* Skeletons </li></ul><ul><li>Marshalling - process of converting data or objects into a byte-stream . </li></ul><ul><li>Unmarshalling - reverse process of converting the byte-stream back to the original data or objects. </li></ul>
RMI Layered Architecture R E M O T E R E G I S T R Y Transport Layer Object A Remote Reference Layer Object A Stub Transport Layer Object B Remote Reference Layer Object B Skeleton Client Server
RMI Layers <ul><li>Stub and the Skeleton Layer </li></ul><ul><li>The stub forwards the request from the client to the remote reference layer and then to the skeleton through transport layer. </li></ul><ul><li>Remote Reference Layer </li></ul><ul><li>Responsible for unicast point-to-point method invocation. </li></ul><ul><li>Transport Layer </li></ul><ul><li>Uses TCP/IP for communication. </li></ul>
The Transport Layer Transport Layer Client Transport Layer Server TCP Protocol UDP Protocol Sockets
Remote Registry Remote Registry Registers Database of Objects SERVER
RMI over IIOP Client Client Client Server Server Server RMI (Java only) RMI (Java only) RMI-IIOP (Java) RMI-IIOP (Java) CORBA (Any Language) CORBA (Any Language) JRMP JRMP IIOP IIOP
Java Naming and Directory Interface <ul><li>Java Naming and Directory Interface provides the naming and directory functionality to Java applications. </li></ul><ul><li>Provides a standard interface to locate the components, users,networks, and services placed across the network. </li></ul><ul><li>Bridges the gap between directory services and makes it possible for the developer to write portable naming and directory services </li></ul>
The JNDI Architecture Client JNDI LDAP Service Provider NDS Service Provider RMI Application Service Provider Interface CORBA Application
Naming Concepts in JNDI Compound Composite Atomic The three types of names in JNDI
Steps in JNDI Programming Looking up the Component/Object Creating the Initial Context Importing the JNDI classes Catching the Naming Exception Running the program Compiling the Program
Initial Context Factory and the Directory Context <ul><li>Initial Context Factory is the point where all naming and directory operations are first performed. </li></ul><ul><li>When the initial context is acquired, all information pertaining to this must be provided to JNDI. </li></ul><ul><li>The directory context or directory object is another type of context. It is used to define methods for inspecting and modifying attributes associated with a directory object . </li></ul>
Initial Context Factory and the Directory Context Initial Context Factory Initial Context Context Naming System Binding Context
Java 2 Platform Enterprise Edition (J2EE) <ul><li>J2EE Technologies </li></ul><ul><li>* Java Servlets and Java Server Pages (JSP) </li></ul><ul><li>* Java IDL </li></ul><ul><li>* Java Mail </li></ul><ul><li>* Connectors </li></ul><ul><li>* Extensible Markup Language (XML) </li></ul>
New Features in EJB 2.0 <ul><li>Container-Managed Persistence </li></ul><ul><li>Container-Managed Relationships </li></ul><ul><li>Message-Driven Beans </li></ul><ul><li>Local Interface </li></ul><ul><li>Additional Methods on the Home-Interface </li></ul><ul><li>New Query Language (EJB QL) </li></ul>
Summary <ul><li>The multi-tier application model focuses on three important areas: </li></ul><ul><li>* Programming business logic </li></ul><ul><li>* Relying on backend services </li></ul><ul><li>* Providing user interaction using client-side applications </li></ul><ul><li>A software component is an individual unit of composition with no persistent state. </li></ul><ul><li>A software component can be deployed independently, and is subject to composition by third parties. </li></ul>
Summary - 2 <ul><li>A component in EJB is an object that is deployed on any EJB server. </li></ul><ul><li>In a distributed application, processing is distributed across multiple networked computers. </li></ul><ul><li>The J2EE Platform collects all the Enterprise APIs to form a total development platform that distributes object architectures. </li></ul>
Summary - 3 <ul><li>The RMI API has mainly 5 packages </li></ul><ul><li>* java.rmi * java.rmi.registry </li></ul><ul><li>* java.rmi.server * java.rmi.activation </li></ul><ul><li>* java.rmi.dgc </li></ul><ul><li>JNDI is used by Enterprise JavaBeans to perform a look-up to distribute objects in a network. </li></ul><ul><li>The point where all naming and directory operations are first performed is called the Initial Context Factory. </li></ul>