1 / 24

G52IWS: Distributed Computing

Chris Greenhalgh. G52IWS: Distributed Computing. Contents. Distributed Computing Pre-WS Distributed Computing Platforms CORBA Java RMI Message-Oriented Middleware Common Challenges & relation to Web Services Supporting protocols HTTP DNS TCP.

terris
Download Presentation

G52IWS: Distributed Computing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chris Greenhalgh G52IWS: Distributed Computing

  2. Contents • Distributed Computing • Pre-WS Distributed Computing Platforms • CORBA • Java RMI • Message-Oriented Middleware • Common Challenges & relation to Web Services • Supporting protocols • HTTP • DNS • TCP See “Developing Java Web Services” chapter 1 See W3C HTTP specifications; see IETF DNS RFCs; See G51WPS notes

  3. Distributed Computing “Objects” / services / servers / ports Object TCP/IP Application Internet Object TCP/IP TCP/IP Object After “Developing Java Web Services” figure 1.1

  4. The Importance of Distributed Computing • Higher performance though concurrency • Collaboration between multiple applications • Higher reliability and availability with replicated services • Scalability through replication • Extensibility through dynamic (re)configuration • Higher productivity, shorter development cycles and reduced cost through decomposition & re-use

  5. Client-Server Applications Application Clients Application Application TCP/IP TCP/IP TCP/IP Server (e.g. database) After “Developing Java Web Services” figure 1.2

  6. Client-Server • 1 – simple model or building block of distributed computing • Single server exposes common facilities to multiple clients • Each client make explicit requests to the server(s) according the client’s requirements/logic • 2 – minimal (“two tier”) approach to distributed application development • Complex client with extensive business logic intermingled with presentation & user interaction • Simple server (e.g. database) for coordination/persistence (singular server?!)

  7. Common Object Request Broker Architecture (CORBA)‏ Clients Server objects C C++ Java C C++ Java IDL IDL IDL Client Stubs Server Skeletons CORBA Object Request Broker (ORB)‏ Networking After “Programming Java Web Services” figure 1.3

  8. CORBA Features • Open standard from the Object Management Group (OMG)‏ • OS, programming language and platform independent • interfaces defined in CORBA IDL (Interface Definition Language)‏ • Rich set of services and features • e.g. lifecycle, events, naming, transactions, security • Location transparency through location-independent object references

  9. CORBA features cont. • Network transparency using the IIOP (Internet Inter-ORB Protocol)‏ • Remote callback support with asynchronous messages • Dynamic invocation interface for run-time interface discovery

  10. CORBA issues • High initial investment in training, application porting etc. • Availability of CORBA services still limited in most implementations • Scalability may be limited due to tightly coupled distributed object model (e.g. Direct object invocations)‏

  11. Java Remote Method Invocation Java client RMI Stubs RMI Skeleton Java RMI Server Remote Ref. Layer Remote Ref. Layer JRMP After “Developing Java Web Services” figure 1.4

  12. Java RMI Features • Developed by Sun Microsystems • Allows distributed Java application development with invocation of methods on remote Java objects • i.e. Java objects in other Java Virtual Machines (VMs)‏ • Exploits Java Serialization and Java Remote Method Protocol (JRMP)‏ • Stub “intercepts” the client request and passes over RMI/JMRP to server skeleton and hence to server object

  13. Java RMI Features cont. • Includes a simple registry for non-persistent naming/lookup of remote services • Interoperates with CORBA using RMI-IIOP (RMI over IIOP) as an alternative to JRMP

  14. Java RMI Issues • Limited to the Java Platform (excepting bridging to CORBA/RMI-IIOP)‏ • Tend to be tightly coupled via remote object references • No specific session management support • Each Remote Method Invocation is handled independently

  15. Message-Oriented Middleware (MOM)‏ MOM infrastructure Application A Application B Adapter API Adapter API Messages sent & received (& transactions contexts)‏ Persistence After “Developing Java Web Services” figure 1.6

  16. MOM Features • Loosely coupled asynchronous communication based on messages • Messages typically sent via queues • MOM infrastructure supports reliable delivery, transactions, security. • Often used for Enterprise Application Integration • Various technology options, including OBM MQSeries, TIBCO, SunONE Message Queue, Java Message Service (JMS) API

  17. MOM Issues • APIs are often proprietary and language-specific • Message formats are often proprietary • MOM infrastructure is often designed to be managed by a single organisation/entity

  18. Common Challenges in Distributed Computing • Maintenance of client/server stubs in heterogeneous environments • Quality of Service goals such as scalability, performance & availability take a lot of work • Interoperability between different protocols is almost impossible (e.g. RMI to DCOM)‏ • Led to disjoint communities with little/no interoperability • Typically work well with a local network: not firewall friendly, or easy to access over the Internet

  19. Relation to Web Services • Similar concerns – distributed applications • Growing emphasis on composition and re-use • Growing emphasis on platform-neutral and inter-organisational distribution • Increasingly sophisticated architectural & interactional models • Multi-tier designs within and across organisations • Distributed messaging and complex choreography as well as client-server approaches

  20. Supporting standards • HTTP • DNS • TCP/IP

  21. HTTP • Simple text-based request/response protocol over TCP/IP • Main request types: POST, GET • End-point identified by http: URL • Host • Optional non-default port (default 80)‏ • Path • Optional fragment reference and arguments • See G51WPS notes on HTTP

  22. DNS • Simple binary request/response over UDP • Request: asks questions about a domain name • e.g. “What is the IP address of www.nottingham.ac.uk” • Response: returns known information • and/or refers request to another DNS server which is more likely to know • Used for host part of HTTP URLs to identify server IP address • See G51WPS notes on TCP/IP

  23. TCP/IP • The Internet Protocol suite • An open standard of the Internet Engineering Task Force (IETF). • Includes • IP – host-to-host delivery, globally • UDP – unreliable datagram delivery service • TCP – reliable byte stream delivery service to a particular host (IP address) and TCP port • ICMP – control and management messages • See G51WPS notes on TCP/IP

  24. Summary • Its still distributed computing… • With added: • Inter-organisational emphasis • Interoperability • Platform/language neutrality • Business requirements • XML 

More Related