Session 1 Tp1

Editor's Notes

• #5: 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.
• #12: 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
• #13: h
• #14: 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.
• #15: 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.
• #19: 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.
• #20: 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