Welcome to WebFlow Middle-Tier Demonstration ============================================= This demo's purpose is to show how WebFlow is working and to make people understand it easier. For better understanding , we should know about some very brief overview of CORBA. ** CORBA Architecture ** CORBA's architecture - specifically the Object Request Broker(ORB). The ORB is the heart of any CORBA system. The ORB would be lifeless without the Interface Definition Language(IDL) , which will be introduced later. ** ORB ** An Object Request Broker(ORB) is responsible for the communication between clients and servers. An ORB can be implemented as a single component , as a collection of components. The ORB provides the interface that is specified in the CORBA standard. You can consider the ORB to be sort of a magic box. You don't really need to know how it works in order to use it. It's like driving a car for most people. We just get in and turn the key , then drive off, blissfully unaware of exactly how internal combustion engines work. ORB interface component is the intermediary between objects and the ORB. The ORB interface is a collection of operations that provides services that are common to clients and servers. ** IDL ** The Interface Definition Language (IDL) is used in CORBA to describe the interfaces of objects. It's yet another language , but it's not hard to learn. It looks like C++ and Java. Specifically , IDL defines the modules , interfaces , and operations for applications. It is a declarative language only. IDL isn't used to implement applications. The IDL serves two important purposes in CORBA. 1) We use IDL to define the objects and modules that make up applications. IDL creates definitions in a platform- and language-neutral way. 2) IDL creates the server skeletons and client stubs that are automatically generated when an IDL file is compiled. We use the stubs and skeletons to implement servers in a target language of your choice. An IDL client stub is a piece of code that allows a client to invoke a server's services. We use an IDL server skeleton to implement a server's services. CORBA is available on a wide range of operating systems, and you can use just about any development tool to write your code. That's wonderful for you , but such variety makes it hard for us to describe simple things like creating a text file with IDL in it or compiling the text file with an IDL compiler. So keep the following points in mind when we tell you to do something. & Servers accept requests and deliver (or do)something. In other words , a server serves the needs of client objects or applications. & Clients request and receive something. In other words , a client uses the services of server objects. ******************* * The Scenario * ******************* Everything takes place in the WebFlow middle-tier. There are three modules , where two modules( Action , Response ) are related to invoke events and respond to them and another module( actionEvent ) is just supportive to find a event source and type. One IDL file defines these modules as interfaces. As an instance , if we have three methods in Action module , we should define these in the Action Interface like the following. interface Action:BeanContextChild{ void runfire(); void runreset(); void runquit(); }; Action module is implementing three Action methods( runfire() , runreset() , runquit() ). These methods should include the following lines of code. actionEvent aevt = new actionEventImpl(getBeanContextChildPeer(), "Fire"); | | |---> event source |----> Name of an event type fireEvent("Fire_Button" , aevt); | |----> a Name of Event , which a Client will need to use for attachPushEvent actionEvent module is implementing two methods( getSource() , eventType() ). getSource() returns the source object. eventType() returns the Name of an event type , which is used to distinguish many different events when getEvent method is invoked in Response module. For example , we have three Events ( "Fire" , "Reset" , "Quit" ) in Action module with different event types. But , these events of different type may have same event source. Response module is implementing one getEvent method( getEvent(Object e) ). A "getEvent" method takes an event as an object. And, this method should include a following code. actionEvent gevt = actionEventHelper.narrow(e); From "gevt" , we can retrieve it's source ( gevt.getSource() ) and its type ( gevt.eventType() ). Because a reaction corresponding to each eventType can be different , we need to use these methods. Client creates ORB and gets IOR (Interoperable Object Reference) of a server through a masterURL. And , a Client can attach a master server and any arbitrary number of slave servers to it. As long as the number of server are permitted , a Client can attach them and add modules evenly to each server. If our modules include Action-Event handling , a Client can register the event-sender and event-receiver like the following. ms_1.attachPushEvent(p1, "Fire_Button" , k1 , "getEvent"); And then , a Client commands any registered event and the output cames out after a server receives an event notification. We have two ways for invoking the method of the Response module : directly from a client and indirectly , by executing a method of the Action module. We will run the demo using the master server and two slave servers. Our client will add Action module to one slave server , and Response module and actionEvent module to the other. Action and Response modules will display their own window frames with different kinds of buttons. These buttons can be clicked by both a server and client. ************************************ * How to run this demo application * ************************************ 1. Connect to a master server. File(ex. /npac/home/webflow/WEBFLOW/JIGSAW/Jigsaw/WWW/Kieun/master.txt) is specified in a master conf. > java WebFlow.Server master.conf 2. Connect to one slave server. The slave1 server is pointed by a master server. A masterURL corresponsing to a File in a master.conf is provided in a slave1.conf. > java WebFlow.Server slave1.conf 3. Connect to another slave server. The slave2 server is pointed by a master server. A masterURL corresponding to a File in a master.conf is provided in a slave2.conf > java WebFlow.Server slave2.conf 4. Make a Client initialize the ORB and retrieve the initial server object reference. Give a Client a masterURL to make a master interoperable with slave webflow using IOR translated from getIORFromURL. Here , a given masterURL is supposed to have the same IOR as File as given in master.conf. webflow using IOR translated from getIORFromURL. Here , a given masterURL is supposed to have a same IOR as File given in a master.conf. Thus, this makes a master and slaves recognize each other. A client can add any number of modules in any connected slave and attach any number of events. > java WebFlow._try.Client http://osprey4.npac.syr.edu:8001/Kieun/master.txt **************************************** * What we can get in Event-Handling ? * **************************************** | Invoking events | responding events ---------------------------------------------------------------------------- runfire(): "Beep" button makes a sound-signal button click with a "Fire" and increments the number of button event type. clicks in a label. runreset(): Reset the number of button clicks button click with a "Reset" to 0 and beep button color is event type. restored to an original color. runquit(): All the processes(master, server and button click with a "Quit" client jobs) are killed gracefully event type. at one time. -----------------------------------------------------------------------------