[attachment=10434]
ABSTRACT
System power control allows the network administrator manages the network easily and effectively while the network administration is one of the most complex works in the field of computer science or information technology. The main aim of the application is to control the system by shutdown, restart, logoff, etc for a remote server system to conserver to power consumption of the network elements. It is highly hectic process to control energy in the large scale lab over hundreds of system in use and manual shutdown of ever system in a large scale network is impossible so we propose an application that does the operation in orderly manner in a network. Our application server user interface in the server machine every client is installed with our client application but it doesn’t have any user interface it just receives the command and executes in the local machine. Network administrator can shut down the specific system by selecting the system in the application and hit the shutdown button. This done transfer of control object from server application to client system subsequently the client executes the object received
CHAPTER-1
INTRODUCTION
1.1 ABOUT TRANSFER OF CONTROL OBJECT
System power control has a strategic approach towards the manipulation control system over the client in huge network architecture is achieved by the framework, which has many application in the real time world that could be useful many of the transfer application in the large network application like intrusion detection system and some more in the LAN and WAN. The distribution of the control object may end in a serious block over the network by collapsing the entire packet transfer in the IP (Internet Protocol) network which also contains some of the complications over the detection of the specific system in the remote location over the configuration of the association or cluster of receiver in the collection of networks
1.2 PROBLEMS
Java 2 Platform, Enterprise Edition (J2EE) applications implement server-side business components as session beans and entity beans. Some methods exposed by the business components return data to the client. Often, the client invokes a business object's get methods multiple times until it obtains all the attribute values.
Session beans represent the business services and are not shared between users. A session bean provides coarse-grained service methods when implemented per the Session Facade pattern.
Entity beans, on the other hand, are multi-user, transactional objects representing persistent data. An entity bean exposes the values of attributes by providing an accessor method (also referred to as a getter or get method) for each attribute it wishes to expose.
Every method call made to the business service object, be it an entity bean or a session bean, is potentially remote. Thus, in an Enterprise JavaBeans (EJB) application such remote invocations use the network layer regardless of the proximity of the client to the bean, creating a network overhead. Enterprise bean method calls may permeate the network layers of the system even if the client and the EJB container holding the entity bean are both running in the same JVM, OS, or physical machine. Some vendors may implement mechanisms to reduce this overhead by using a more direct access approach and bypassing the network.
As the usage of these remote methods increases, application performance can significantly degrade. Therefore, using multiple calls to get methods that return single attribute values is inefficient for obtaining data values from an enterprise bean.
1.3 SOLUTIONS
Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
Clients usually require more than one value from an enterprise bean. To reduce the number of remote calls and to avoid the associated overhead, it is best to use Transfer Objects to transport the data from the enterprise bean to its client.
When an enterprise bean uses a Transfer Object, the client makes a single remote method invocation to the enterprise bean to request the Transfer Object instead of numerous remote method calls to get individual attribute values. The enterprise bean then constructs a new Transfer Object instance, copies values into the object and returns it to the client. The client receives the Transfer Object and can then invoke accessor (or getter) methods on the Transfer Object to get the individual attribute values from the Transfer Object. Or, the implementation of the Transfer Object may be such that it makes all attributes public. Because the Transfer Object is passed by value to the client, all calls to the Transfer Object instance are local calls instead of remote method invocations.