Presentation is loading. Please wait.

Presentation is loading. Please wait.

Distributed components

Similar presentations

Presentation on theme: "Distributed components"— Presentation transcript:

1 Distributed components
Week 6 – Lecture 1

2 3 Tier Client/Server PCs Network c Presentation File system
Operating system Presentation Proc C PCs Network c Operating system Operating system File system Application Proc C Database

3 Why do we have distributed systems?
Scalability Heterogeneity Fault tolerance

4 Scalability Able to handle growth as it arises
Without a reduction in service i.e. response time Without changing the code Implies Changing the host of processes Adding hosts

5 Heterogeneity We know that components may be heterogeneous in several dimensions The hardware platform The operating system The programming language in which it is written

6 Fault tolerant If a host fails we need to transfer the work to another host Seamlessly

7 A service request consists of three parts
The name of the component The service to be performed The list of parameters Requests and results are passed in messages.

8 So what do we need to do? We need
To identify the host and process that can provide the service To transfer messages to/from the requesting process in one host from/to the serving process in another host reliably and quickly The messages need to be understood – both syntax and semantics.

9 Applications will be built on HTTP – e.g. WEB services
More applications will be written using HTTP as the transport protocol and XML to pass parameters between processes within an application applications within an organisation and applications between organisations. This allows thin client architectures to be more feasible and make the differences between operating systems and platforms less important

10 Today we want to look at a more generalised form of distributed components –

11 Clients WAN & LAN Database servers Application Servers

12 We know that TCP will transport messages
between processes on different hosts reliably, but we will need more than that. TCP needs the IP address and then the port number We need – - A protocol to find the host supporting the process - A protocol to ensure we are passing parameters understandably

13 To implement scalability and
heterogeneity and fault tolerance, and to allow developers to proceed without knowing the implementation we need transparency There are eight layers of transparency!! (see Emmerich – Engineering Distributed Objects – page 19-27)

14 Access transparency Requires that the interface between components on different hosts be the same as between components on the same machine. Without access transparency, components cannot easily be moved from one host to another.

15 Location transparency
Requires that a component can be addressed without knowledge of the host on which the component is located.

16 Migration transparency
Requires that a component can be moved from one host to another without users or designers needing to take special consideration Dependent on access and location transparency

17 Replication Transparency
Requires that multiple copies of the same component can be kept on the same or different hosts And that the user is not aware that the service is being provided by the copy not the original And that when a component changes all copies are changed simultaneously

18 Concurrency transparency
Requires that several components can request service from a shared component while preserving the integrity of each transaction

19 Scalability transparency
Requires that it should be transparent to the designers and users of a component how scalability is to be achieved It is achieved by replication and migration transparency

20 Performance transparency
Requires that load is balanced across multiple copies of a component such that the user does not see any reduction in performance as the number of transactions processed increases

21 Failure transparency We know that failures are more likely to occur in a distributed environment This facility requires that users are unaware that a failure has occurred, that recovery occurs automatically and that transactions are rerouted to other servers and processes If a failure occur, a transaction must not be left part processed

22 Why use the term “component” and not “object”?
They may not have been written using an object oriented language They may not have all of the attributes of objects They tend to be larger in scope and carry out a significant unit of work They are often “containers” consisting of a number of objects Encapsulate business functions

23 Reasons for using components
Code re-use Assembly of new applications from pre-built components Support for heterogeneity Ability to scale

24 Distributed component requests have a lot of work to do
Find the host for the process (resource discovery) Resolve data heterogeneity Synchronise client and server (parallelism) Transfer messages across the network Start the process if it is not active (and deactivate it afterwards) Handle errors Perhaps 2000 times more work than to invoke a process in the same language on the same host.

25 So how do we do this and maintain transparency?
Process On Host A Process on Host B Application layer Middleware Middleware Presentation & Session Layers TCP/IP Network & Transport Layers TCP/IP Data link & Physical layers

26 Seven different approaches
Load balancing Transaction oriented middleware Message oriented middleware (MOM) Remote Procedure Calls (RPCs) Distributed Objects XML, UDDI, WSDL and SOAP on the WEB GRID computing

27 More mnemonics to learn
Uses XML rather than HTML to give semantic meaning to the data being exchanged UDDI (Universal Description Discovery Integration) to describe services WSDL (WEB Service Description Language) SOAP (Simple Object Access Protocol)

Download ppt "Distributed components"

Similar presentations

Ads by Google