Listen to your teachers when they tell you WHAT to do. But more importantly, think about it later and ask yourself WHY they told you to do it.
--Your friends at LectureNotes

Note for Distributed Computing - DC By JNTU Heroes

  • Distributed Computing - DC
  • Note
  • 6 Offline Downloads
  • Uploaded 1 year ago
0 User(s)
Download PDFOrder Printed Copy

Share it with your friends

Leave your Comments

Text from page-1

UNIT-1 Evolution of Distributed Computing:In the early years of computing, mainframe-based applications were considered to be the best-fit solution for executing large-scale data processing applications. With the advent of personal computers (PCs), the concept of software programs running on standalone machines became much more popular in terms of the cost of ownership and the ease of application use. With the number of PC-based application programs running on independent machines growing, the communications between such application programs became extremely complex and added a growing challenge in the aspect of application-toapplication interaction. Lately, network computing gained importance, and enabling remote procedure calls (RPCs) over a network protocol called Transmission Control Protocol/Internet Protocol (TCP/IP) turned out to be a widely accepted way for application software communication. Since then, software applications running on a variety of hardware platforms, operating systems, and different networks faced some challenges when required to communicate with each other and share data. This demanding requirement lead to the concept of distributed computing applications. As a definition, “Distributing Computing is a type of computing in which different components and objects comprising an application can be located on different computers connected to a network distributed computing model that provides an infrastructure enabling invocations of object functions located anywhere on the network. The objects are transparent to the application and provide processing power as if they were local to the application calling them. Importance of Distributed Computing The distributed computing environment provides many significant advantages compared to a traditional standalone application. The following are some of those key advantages: Higher performance. Applications can execute in parallel and distribute the load across multiple servers. Collaboration. Multiple applications can be connected through standard distributed computing mechanisms. Higher reliability and availability. Applications or servers can be clustered in multiple machines. 1

Text from page-2

Scalability. This can be achieved by deploying these reusable distributed components on powerful servers. Extensibility. This can be achieved through dynamic (re)configuration of applications that are distributed across the network. Higher productivity and lower development cycle time. By breaking up large problems into smaller ones, these individual components can be developed by smaller development teams in isolation. Reuse. The distributed components may perform various services that can potentially be used by multiple client applications. It saves repetitive development effort and improves interoperability between components. Reduced cost. Because this model provides a lot of reuse of once developed components that are accessible over the network, significant cost reductions can be achieved. Distributed computing also has changed the way traditional network programming is done by providing a shareable object like semantics across networks using programming languages like Java, C, and C++. The following sections briefly discuss core distributed computing technologies such as Client/Server applications, OMG CORBA, Java RMI, Microsoft COM/DCOM, and MOM. Client-Server Applications The early years of distributed application architecture were dominated by two-tier business applications. In a two-tier architecture model, the first (upper) tier handles the presentation and business logic of the user application (client), and the second/lower tier handles the application organization and its data storage (server). This approach is commonly called client-server applications architecture. Generally, the server in a client/server application model is a database server that is mainly responsible for the organization and retrieval of data. The application client in this model handles most of the business processing and provides the graphical user interface of the application. It is a very popular design in business applications where the user. interface and business logic are tightly coupled with a database server for handling data retrieval and processing. For example, the client-server model has been widely used in enterprise resource planning (ERP), billing, and Inventory application systems where a number of client business applications residing in multiple desktop systems interact with a central database server. 2

Text from page-3

Figure 1.2 shows an architectural model of a typical client server system in which multiple desktop-based business client applications access a central database server. Some of the common limitations of the client-server application model are as follows: ■Complex business processing at the client side demands robust client systems. ■Security is more difficult to implement because the algorithms and logic reside on the client side making it more vulnerable to hacking. ■Increased network bandwidth is needed to accommodate many calls to the server, which can impose scalability restrictions. ■Maintenance and upgrades of client applications are extremely difficult because each client has to be maintained separately. ■Client-server architecture suits mostly database-oriented standalone applications and does not target robust reusable componentoriented applications. CORBA The Common Object Request Broker Architecture (CORBA) is an industry wide, open standard initiative, developed by the Object Management Group (OMG) for enabling distributed computing that supports a wide range of application environments. OMG is a nonprofit consortium responsible for the production and maintenance of framework specifications for distributed and interoperable object-oriented systems. CORBA differs from the traditional client/server model because it provides an objectoriented solution that does not enforce any proprietary protocols or any particular programming language, operating ystem, or hardware platform. By adopting CORBA, the applications can reside and run on any hardware latform located anywhere on the network, and can be written in any language that has mappings to a eutral interface definition called the Interface Definition Language (IDL). An IDL is a specific interface anguage designed to expose the services (methods/functions) of a CORBA remote object. CORBA also defines a collection of system-level services for handling low-level application services like life-cycle, persistence, transaction, naming, security, and so forth. Initially, CORBA 1.1 was focused on creating component level, portable object applications without interoperability. The introduction of CORBA 2.0 added interoperability between different ORB vendors by implementing an 3

Text from page-4

Internet Inter-ORB Protocol (IIOP). The IIOP defines the ORB backbone, through which other ORBs can bridge and provide interoperation with its associated services. In a CORBAbased solution, the Object Request Broker (ORB) is an object bus that provides a transparent mechanism for sending requests and receiving responses to and from objects, regardless of the environment and its location. The ORB intercepts the client’s call and is responsible for finding its server object that implements the request, passes its parameters, invokes its method, and returns its results to the client. The ORB, as part of its implementation, provides interfaces to the CORBA services, which allows it to build custom-distributed application environments. Figure 1.3 illustrates the architectural model of CORBA with an example representation of applications written in C, C++, and Java providing IDL bindings. The CORBA architecture is composed of the following components: IDL. CORBA uses IDL contracts to specify the application boundaries and to establish interfaces with its clients. The IDL provides a mechanism by which the distributed application component’s interfaces, inherited classes, events, attributes, and exceptions can be specified. ORB. It acts as the object bus or the bridge, providing the communication infrastructure to send and receive request/responses from the client and server. It establishes the foundation for the distributed application objects, achieving interoperability in a heterogeneous environment. Some of the distinct advantages of CORBA over a traditional client/server application model are as follows: OS and programming-language independence. Interfaces between clients and servers are defined in OMG IDL, thus providing the following advantages to Internet programming: Multi-language and multi-platform application environments, which provide a logical separation between interfaces and implementation. Legacy and custom application integration. Using CORBA IDL, developers can encapsulate existing and custom applications as callable client applications and use them as objects on the ORB. Rich distributed object infrastructure. CORBA offers developers a rich set of distributed object ervices, such as the Lifecycle, Events, Naming, Transactions, and Security services. Location transparency. CORBA provides location transparency: An object reference is independent of the physical location and application level location. This allows developers to create CORBA-based systems where objects can be moved without modifying the underlying applications. 4

Lecture Notes