Frameworks for Component Based Client/Server Computing -Scott M. Lewandowski

1. Frameworks for Component Based Client/Server Computing-Scott M. Lewandowski Presented by: Manish Mehta Tulika Rathi Sucharita Simhadri Anupama Vasanth

2. What is in this paper? • Introduction to Client/Server computing • Introduction to component technologies -- CORBA and DCOM (JavaBeans is not discussed) • Frameworks for Client/Server computing using distributed objects.

3. What is Client/Server computing? • Two logical parts -Server: that provides service(s). -Client : that requests services of the server. Both client and server together form a complete computing system with a distinct division of responsibilities.

4. Server • Traditional servers were passive. • Recent research shows some systems fulfilling the theoretical organization of Client/Server in which servers can be active. • Can divide the task in subtasks and delegate each subtask to other servers.

5. Why is Client/Server so popular? • Client/Server computing has gained popularity in recent years due to proliferation of low-cost hardware. • Monolithic applications fail when the number of users accessing a system grows too high or when too many features are integrated into a single system.

6. Client • Most of the clients have a modern Graphical User Interface(GUI) • GUI is usually provided with the help of operating system to maintain consistency across multiple applications.(“Swing” is different)

7. Fat v/s Thin -- client/server • A part of the system with disproportionate(more) amount of functionality is “FAT”. • A portion of a system with less responsibilities delegated to it is “THIN”. FAT Servers for example: Web Servers FAT Clients for example: Most Database Systems

8. N-tier Systems • The canonical C/S model assumes exactly two discrete participants i.e “Two-tier” system. • It is also possible to have the application logic reside separately from the user interface and data, turning the system into “N-tier” system. • N-tier system provides more flexibility than traditional 2-tier system because of the separation of the application logic. • Decoupling the application logic from the data allows data from multiple sources to be used in a single transaction.

9. Middleware • To provide transparent access to non-local services and resources distributed across the network. Database Middleware: ODBC, SQL, Oracle Glue Groupware Middleware: Microsoft Exchange, Lotus notes Internet Middleware: HTTP, SSL Object-Oriented Middleware: CORBA, DCOM

10. Functions & benefits of c/s system Functions • Regulate access to shared resources when multiple clients attempt to access the same resource via server. • Provide a standardized system through which network services can be utilized to provide location transparent access to all services. Benefits • Natural mapping of applications into a c/s framework.(Phone Number) • Resource intensive applications can be designed to run on multiple low-cost systems.

11. Distributed Objects and Components Classical object v/s Distributed object • Classical objects are entities that encapsulate data and a set of operations(methods) that act on that data. • Classical objects do not exist as separate entities once the program is complied. • Distributed objects can reside any where in the network and continue to exist as physical standalone entities while remaining accessible by other objects.

12. Benefits of Distributed objects • Self-managing distributed objects take responsibility for their own resources, work across network, and interact with other objects. • They allow applications to be split up into lightweight pieces that can be executed on separate machines. • Distributed objects can generate events to notify other objects that an action should take place. This synchronization is very useful. • With middleware, we can ensure interoperation between/among objects.

13. Components • Components are the smallest self-managing, independent, and useful parts of a system that work in multiple environments. • Components are most often distributed objects incorporating advanced self-management features. • Components may contain multiple distributed or local objects, and they are often used to centralize and secure an operation.

14. New models for c/s computation We discuss three models • Client/server using distributed objects like CORBA and DCOM • Client/server applications using Java • Client/server applications using Java and CORBA.

15. Client/Server with CORBA CORBA (Common Object Request Broker Architecture) • Most important part is ORB • ORB defines the object model and provides bi-directional location-transparent object access. • Internet Inter-ORB Protocol(IIOP) provides inter-vendor ORB compatibility by adding several CORBA-specific messages to the TCP/IP schema. • ORB intercepts method invocations form client objects and routes them to an appropriate server.

16. CORBA (contd.) • Interface Definition Language (IDL) is used to specify the services that an object can provide. • IDL is defined independent of the factors affecting interoperability such as Implementation language, tool, Operating System. • The flexibility is achieved at the expense of equipping each client component with an IDL stub for each server used. • CORBA supports Dynamic Method Invocation, handled through Dynamic Invocation Interface (DII) .DII allows a component to learn about the methods of other components at run time.

17. CORBA (contd.) • To accommodate components without IDL-based stubs, CORBA provides a Dynamic Skeleton Interface (DSI) that binds incoming method calls for such objects at run-time. • Server demands are met via an Object Adapter, which provides the core run-time functionality required by servers. Two ways to locate another object • Naming Service – like while pages in a phone book • Trade Service – like yellow pages (choose from pool)

18. Client/Server with DCOM • Primarily uses ActiveX components • Integration of Java with DCOM is possible through Visual J++. • Binding provided with Visual J++ are strong enough so that ActiveXs written in other languages can be made to look like remote Java objects. • Uses IDL based on Distributed Computing Environment (DCE)-- Not compliant with CORBA.

19. Client/Server with DCOM (contd.) • A request for a reference to a DCOM objects results in arbitrary handle. • DCOM supports a registry of available interfaces. • For a DCOM client to access the methods of an object, it must use a virtual lookup table to obtain a pointer to that function. • Since DCOM objects have no unique object identification, there are no naming or trading services.

20. CORBA v/s DCOM • DCOM “objects” do not have a state; rather they are collections of interfaces. • The object can be located using Naming or Trading services in CORBA. But, in DCOM, a client object can not request to be connected to a given server.It can only ask to be connected to arbitrary server supporting the services needed. • Benchmarks incorporating network communication and simple method invocation show DCOM to be almost 20% slower than CORBA.

21. CORBA as the Dominant Model • More portable (Not only Microsoft) • Open System in the third generation. • CORBA uses universal security mechanism which is independent of platform and OS-level security.DCOM uses Windows NT security Model. • CORBA provides seamless integration for the most popular OO languages.DCOM language support is limited to Java, C, C++ and VB. • CORBA hides the IDL from programmer. • All industry giants are rallying behind CORBA.

22. Java for Client/Server Applications • Mobile code system provided through bytecodes, which solves portability and security problems. • VM translates the bytecodes into actual machine instructions on-the-fly. • Packages allow dynamic class linking with methods that can be overridden at runtime. • Native support for multi-platform multi-threading and thread synchronization. • Java provides some core frameworks relevant to Client/Server computing. (Java Applet, Java Beans, Java Security)

23. C/S using Java & CORBA • Integration of Java and CORBA can provide a platform for universal network computing. • Advantages of Integration : ( by CORBA ) • Superior performance and flexibility.- for example HHTP/CGI • Scalability- load balancing • Component infrastructure- feature of CORBA • Split Components- split components in Client and Server side components.

24. C/S using Java & CORBA (contd.) • Advantages of Integration (by Java) • Simplified code distribution • Mobile code • Agenting • Superior language feature - Multi-threading

25. Frameworks • Frameworks are tools to help programmers construct software systems structures in the same way as the analogous real-world system. • Frameworks provide a way to manage a system of interacting objects and to develop objects that will integrate seamlessly into the framework. • The framework is ideally suited for capturing the elements common to a family of related systems. • Frameworks are a valuable tool for ensuring the availability of object services.

26. Conclusion • Distributed objects promise to revolutionize the stagnant C/S market. • CORBA, with many advantages over DCOM is becoming the Distributed Object standard. • Leveraging CORBA and Java provides the most notable advantages of component technology.

27. Thank you !