the system 100 in fig1 a is an embodiment of a computer network system for remotely managing a plurality of network devices . system 100 comprises a client computer 130 in communication with a plurality of network devices 108 , 128 , 138 over a network such as the internet , the world wide web or any other network using a socket based protocol . client computer 130 may be embodied as a workstation or a personal computer which is readily accessed by a user 103 . client 130 preferably comprises a processor 109 , a communications device 111 , a memory 175 , an input device 105 , a display 107 , and a browser 102 all interconnected via a bus 124 . communication device 111 provides the communication port through which browser 102 sends and receives information and requests . examples of a communication device include modems and network adapters . input device 105 may be any type of conventional input or pointing device , for example a keyboard , tablet , touch screen , and or a mouse . input device 105 is used to transmit user commands from user 103 to the processor 109 for processing . memory 175 includes random access memory ( e . g . 128 mb ). memory 175 is used to store application programs , operations systems , and / or data . display 107 is used to display texts , graphics , or video to user 103 and can be any conventional display device . browser 102 is any software program for accessing , interacting with , and observing information in a network using socket - based protocols . for example , browser 102 can access , interact with , and observe information in the world wide web . browser 102 is preferably a java - enabled or java - capable browser . in this embodiment the java capable browser supports the abstract window toolkit ( awt ) which is a class library that contains a number of common graphical widgets . processor 109 , communications device 111 , memory 175 , input device 105 , display 107 and browser 102 are all conventional parts commercially available . in this embodiment , the devices are fibre channel switching devices in a fabric of switches included in a network . like the other switches in this embodiment , switching device 1 108 has a device server 122 which communicates information to the java - capable browser 102 of the client computer 130 . each device server communicates device information 132 , 134 , 136 about its respective switch . device information includes but is not limited to information regarding status , identification , environmental factors such as temperature , paths available within the network , device operating parameters , and events concerning the switch . in one embodiment , a user 103 initiates the management system by designating a launch device by inputting via input device 105 a uniform resource locator ( url ) that is associated with the device in the browser 102 . any device in the system can act as a launch device . in this embodiment , the browser 102 initiates a request 104 for a webpage written in an applet compatible language such as a markup language , for example hypertext markup language ( html ). upon the request , the launch device , in this embodiment switch or switching device 1 , polls the network of devices to see which devices are in the network and receives identifying information from each device . switch 1 &# 39 ; s device server 122 then sends 106 the requested page which comprises an unsigned fabric view applet 113 and requests 110 , 111 and 116 for device applets , to be sent to each of the device servers for its respective unsigned device applet 112 , 114 and 118 . the browser requests each applet which each device server sends . each device applet executes to display a graphical representation of each switch &# 39 ; s device information on display 107 as selected by the user 103 . fig1 b illustrates an embodiment of an apparatus in which unsigned applets are initialized to communicate with each other in the same shared environment in accordance with the present invention . in this embodiment , the shared environment is webpage 140 . within webpage 140 , unsigned fabric view applet 113 operates as does unsigned device applet 114 . each of these applets have been launched from different servers . fabric view applet 113 , which is first loaded by the browser in this embodiment comprises a container interface 166 , an example of a non - gui class model object called event model object 170 , an example of a gui class model adapter object called event model adapter object 168 that communicates with the event model object , and an example of a view object called event view object 172 . a model object compares newly transmitted data with the most recently stored data and determines whether or not there has been a change in the new data . in this embodiment , the event model object 170 processes data for fabric events based on events in all the switches in the fabric . if the model object detects a change in the new device data , a signal is transmitted to a view object which is responsible for graphically displaying the new data or information based on it on display 107 . here , an event view object 172 is responsible for graphically displaying information regarding fabric events based on the new data in the event model object 170 . if an applet is to be communicated with , it will comprise a model adapter object of a gui class , such as the java container class . the model adapter object has one or more methods that are overloaded to extract the data represented as one or more gui class objects for use by non - gui class model objects , rather than to do the normal processing of adding them for display to the user interface . here , the event model adapter object 168 will extract events data . a java capable browser instantiates an object of the class appletcontext . the appletcontext class comprises a method called getapplets ( ) which when called returns a list of references to all the applets currently present in the shared environment , which in this embodiment is a webpage 140 . an address location or a pointer would be examples of a reference . device applet 114 comprises an initialization controller 160 , which is program controlled logic , for example software , for obtaining the references to fabric view applet 113 and one or more model adapter objects therein including the event model adapter 168 . the initialization controller will store these references for later use by the device applet . if the device applets are to communicate device information with each other , they would each have appropriate model adapter objects to be referenced by the other device applets also . the device applet 114 further comprises a data handler 190 which is embodied as software for processing the device information received from device server 124 , switch event model object 192 , switch event view object 194 , and container interface 162 . fig1 c illustrates an embodiment of an overall method 150 of initialization for communication between unsigned applets in accordance with the present invention . an applet desiring to communicate with another applet in a shared environment calls 172 appletcontext . getapplets ( ) to obtain a reference to the recipient applet with which it desires to communicate . for example , in the embodiment of fig1 b , initialization controller 160 of device applet 114 makes a getapplets ( ) call 159 to the appletcontext object 164 which returns 161 a list of references to applets currently present including reference 163 to the fabric view applet 113 . an unsigned transmitting applet such as device applet 114 in fig1 b tests 174 the references in the list of applets to determine if the applet with which it desires to communicate is present . in the embodiment of fig1 b , the desired applet is the fabric view applet 113 . because the fabric view applet was loaded first , the reference to it will be found . if a recipient applet has not been found 176 , and all the references in the list 178 have been tested , the applet may try again later 181 at another time , for example after a polling interval , in order to obtain the reference in order to communicate . if the reference to the recipient applet has been found , the applet then calls the getcomponents ( ) 180 method of the container class with respect to the desired recipient applet to obtain a reference to the one or more model adapter objects . the returned references are each tested 179 until the reference to the desired one or more model adapter objects is found 184 or there are no more components 182 . in the embodiment of fig1 b , initialization controller 160 uses the reference 163 to the fabric view applet to call the container class method getcomponents for the fabric view applet to obtain a list of references to its components . initialization controller 160 tests the references and finds the reference 167 to the event model adapter 168 which is also of the gui class container in this embodiment . fig2 a illustrates an embodiment of an overall method 200 of remotely managing a plurality of network devices using unsigned applets in accordance with the present invention . each device applet polls its own device . the timing of the polling is configurable . in one example , the polling interval is set to every 5 seconds . at each polling interval , device information is requested and received 202 from the respective device server . if the information has not changed 204 , then the device applet does no further processing 206 with respect to the incoming device data . if the information has changed 204 , the model objects effected by the data change , the pertinent model objects , in the device applet are updated 205 . the information is communicated 208 to a recipient applet that uses that information such as the fabric view applet 113 . the user interface is then updated 210 to reflect the new information on the display if appropriate based on the user &# 39 ; s selection . fig2 b illustrates an embodiment of an apparatus for communication between unsigned applets launched from different devices in accordance with the present invention . in the shared environment of a webpage 140 , device applet 114 launched from device server 124 on switching device 2 communicates with fabric view applet 113 which was launched from server 122 on switching device 1 . device applet 114 comprises a data handler 190 which is a sink object for the device information from the corresponding device server 124 , a model object which in this embodiment is switch event model object 192 which is of a non - gui class and a switch event view object 194 . as in fig1 b , fabric view applet 113 comprises a model adapter object shown here as event model adapter object 168 , a non - gui class model object shown here as event model object 170 , and event view object 172 . in this embodiment , the device applet requests device information from its switch . included in the device information is a html page of event information . this event information is parsed by the data handler into a standard java class called properties which comprises name - value pairs with the methods to access them . the values in the properties class are put into an object of the standard class called arraylist . the arraylist is a dynamic array . each arraylist object represents one row in a table in the switch event model object . each row is added to this table which is also of the class arraylist and that contains all the rows . information for each event may include a row for each event in which the columns in the switch event model table include the following : machine name , event number , event timestamp , event count , event level , event message , and wwn ( worldwide name ). the rows are then sent to the switch event model object which determines whether or not the sent rows represent a different set from its current set of rows . if the new set does not represent new information , then processing ends . if it does then the switch event model object notifies the data handler 190 of this . fig2 c illustrates an embodiment of a method of communication between unsigned applets launched from different devices from the perspective of the transmitting applet which sends information in accordance with the present invention . as discussed with respect to fig2 b , once new information arrives , and the device applet has stored the new data for the device , the information is desired to be communicated 208 to the fabric view applet . the data handler 190 represents the list of rows of new information as one or more gui class objects . for example in the embodiment of fig2 b , the events in the switch event model table are formatted into a message 226 by the data handler as a single container class object . the container has a container at index 0 that represents some information about the message . following that container is one container for each row in order . each container has a component for each column in that row . using the reference to the event model adapter object , which is of the class container in this embodiment , previously obtained during initialization , the data handler 190 provides access to the message container object 226 by calling 244 a method add ( components ) of the container class , the call parameters including a reference 242 to the message 226 . the add ( components ) method has been extended by the event model adapter object 168 of the fabric view applet . fig2 d illustrates an embodiment of a method 246 of communication between unsigned applets launched from different devices from the perspective of the applet receiving information in accordance with the present invention . in the embodiment of fig2 d , the recipient model adapter object unpacks 248 the message represented as gui class objects . the recipient model adapter object then adds 250 the unpacked message information to the appropriate non - gui model object . in the embodiment of fig2 b , the event model adapter object 168 unpacks the event data represented in the message container object 226 . the method add ( components ) of the container class is overloaded to extract the message from the container object rather than the normal process of adding the container for display as part of the graphical user interface . for example , the event model adapter object 168 uses standard methods available to the standard container class to retrieve the data . for example , the switch name can be retrieved using standard methods to extract text strings from gui objects . in this embodiment , the retrieved data is put in the format of an arraylist table that the event model object can process . the event model object will then determine that new data has arrived . when a new set of rows comes in for a particular switch , the event model object will replace all the rows with a particular value in a certain column with the new rows . in this embodiment , the certain column used is the machine name column , and the particular value is the switch name . in this way , the applets communicate within the same shared environment without violating the java applet security model for applets launched from different devices . in the embodiment of fig2 b , if the switching device graphical representation is to be updated , one or more view objects in the device applet will update the display . for example , switch event view object 194 will update a display of the switch &# 39 ; s event information . if the user is looking at an interface to manage the entire fabric , one or more view objects in the fabric view applet will update the display . for example , event view object 172 would update a display of events for a plurality of switches in the fabric . fig3 illustrates an example of a single user interface 300 as a shared environment in which information for each switch is graphically represented by its own applet . switch 50 is graphically represented and dynamically updated in a window in a portion of the display 302 by its device applet . the fabric view applet draws the window 310 that comprises items that a user may select to obtain fabric view information . for example , a user may click on the “ fabric events ” button and a window is presented to the user as shown in fig4 . fig4 illustrates an example of a user interface showing device information for a plurality of switching devices in a network . the data has been obtained by the fabric view applet querying the device applet for each switch . in this embodiment , the fabric events view 400 represents the union of all the switches &# 39 ; events , and is updated immediately after the switch events are polled . fabric events do not exist on the switch itself . the information shown includes a name of the switch 402 , the event number 404 for the affected switch , the time of the event 406 , a number 408 of back - to - back occurrences of the same event , a security level 410 of the event , and a message 412 providing a description of the event . fig5 illustrates an example of a user interface showing device information for a switching device . the switch events view 600 provides a running log of events for a switch . in this embodiment , the view is accessed by clicking the bell icon 312 on the respective switch &# 39 ; s box in the fabric events view . the switch events view displays a machine name 602 , an event number 604 , a timestamp 606 of the time of the event , a number 608 of back - to - back occurrences of the same event , a security level 610 of the event , and a message 612 providing a description of the event . the device applet for the switch communicates directly with the switch so that the applet obtains and displays more complete information directly from the switch it is managing . the ability to obtain information directly from the switch as opposed to the launch switch querying the switch through the network saves processing time and bandwidth within the network . furthermore , when new features get added to a device , the applet for the device need only be updated . the launch device does not have to be concerned with interfacing with the new features of the switch . each device need not provide the union of all functionality available for all the devices , even if the functionality is not available on that particular device . the above description is included to illustrate the operation of one or more embodiments and is not meant to limit the scope of the invention . the scope of the invention is to be limited only by the following claims . from the above discussion , many variations will be apparent to those skilled in the art that would yet be encompassed by the spirit and scope of the invention .