![Distributed systems Heterogeneity is a challenge to designers: distributed systems must be constructed from a variety of different networks, operating systems, computer hardware and programming languages Internet communication protocols mask the difference in networks and middleware can deal with the other differences Definition of Middleware Software that provides a programming model above the basic building blocks of processes and message passing [Coulouris, Dollimore, Kindberg, 2001]](https://image.slidesharecdn.com/cdocumentsandsettingsrdesktopmiddlewaresrc-091023145406-phpapp01/85/MIDELWARE-TECH-7-320.jpg)
MIDELWARE TECH
- 1. Middleware Technologies Mohammed Waheeduddin Associate Professor Anwarul Uloom College For Computer studies
- 2. Middleware Need for Distributed Computing Distributed Computing-Middleware RMI RPC CORBA SOA Web Services
- 3. Why do you go for Distributed computing? The information itself is inherently distributed due to the physical distributed nature of an organization. Explicit distribution gives Higher reliability Higher Availability Higher Performance etc.
- 4. The Problem What is the problem with traditional single address space computing? Objects have to be in the same address space, and hence an object cannot send a message to an object that is on a different machine. You need to extend or enrich the traditional model for facilitating distributed computing.
- 5. What is the solution? We would put the objects on different machines and have them send messages directly to each other. Let us assume that the client objects was written in Java (so that it can run anywhere) For the server objects, there are two obvious possibilities The server object was not written in Java. The Server Object is written in Java. The first situation requires us to have a way for objects to talk to each other regardless of what language they were written (CORBA). The second situation requires two objects written in Java to talk to each other (RMI) or RPC( written C or C++)
- 6. Distributed Object Computing A Distributed Object Computing Scenario. Server Objects and Client Program can be located on different machines. Client programs can send messages to these server objects, which are remote. Location Transparency: Clients can send messages to these objects as if they are available locally. Requires middleware. RPC,RMI,CORBA defines middleware.
- 7. Distributed systems Heterogeneity is a challenge to designers: distributed systems must be constructed from a variety of different networks, operating systems, computer hardware and programming languages Internet communication protocols mask the difference in networks and middleware can deal with the other differences Definition of Middleware Software that provides a programming model above the basic building blocks of processes and message passing [Coulouris, Dollimore, Kindberg, 2001]
- 9. Socket programming Sockets provide a low-level API for writing distributed client/server applications. Before a client communicates with a server, a socket endpoint needs to be created. The transport protocol chosen for communications can be either TCP or UDP in the TCP/IP protocol stack. The client also needs to specify the hostname and port number that the server process is listening on.
- 10. RPC
- 11. RPC is another mechanism that can be used to construct distributed client/server applications. RPC can use either TCP or UDP for its transport protocol. RPC relies heavily on an Interface Definition Language (IDL) interface to describe the remote procedures executing on the server-side. From an RPC IDL interface, an RPC compiler can automatically generate a client-side stub and a server-side skeleton. With the help of the stub and skeleton, RPC hides the low-level communication and provides a high level communication abstraction for a client to directly call a remote procedure as if the procedure were local. RPC
- 12. Java RMI
- 13. Java RMI The Java RMI is an object-oriented mechanism from Sun Microsystems for building distributed client/server applications. Java RMI is an RPC implementation in Java. Similar to RPC, Java RMI hides the low-level communications between client and server by using a client-side stub and a server-side skeleton (which is not needed in Java 1.2 or later) that are automatically generated from a class that extends java.rmi.UnicastRemoteObject and implements an RMI Remote interface.
- 14. DCOM
- 15. DCOM The Component Object Model (COM) is a binary standard for building Microsoft-based component applications, which is independent of the implementation language. DCOM is an extension to COM for distributed client/server applications. Similar to RPC, DCOM hides the low-level communication by automatically generating a client-side stub (called proxy in DCOM) and a server-side skeleton (called stub in DCOM) using Microsoft’s Interface Definition Language (MIDL) interface. DCOM uses a protocol called the Object Remote Procedure Call (ORPC) to invoke remote COM components.
- 16. What is CORBA? CORBA is a specification for the distributed object bus architecture defined by OMG. It is the product of a consortium called the object management group (OMG). OMG includes 800 Companies representing the entire spectrum of computer industry. OMG issues specifications, not products.
- 17. CORBA
- 18. CORBA CORBA is an object-oriented middleware infrastructure from Object Management Group (OMG) for building distributed client/server applications. Similar to Java RMI and DCOM, CORBA hides the low-level communication between the client and server by automatically generating a client-side stub and a server-side skeleton through an Interface Definition Language (IDL) interface. CORBA uses Internet-Inter ORB Protocol (IIOP) to invoke remote CORBA objects. The Object Request Broker (ORB) is the core of CORBA; it performs data marshaling and un marshalling between CORBA clients and objects. Compared with Java RMI and DCOM, CORBA is independent of location, a particular platform or programming language. CORBA supports both synchronous and asynchronous communications.
- 19. CORBA Object Request Broker (ORB) Application Objects Object Services Common Facilities Application Objects
- 20. CORBA The key parts of CORBA are: Object Request Broker (ORB):in charge of the interaction between components CORBA services: standard definitions of system services A standardized IDL language for the publication of interfaces Protocols for allowing ORBs to talk to each other CORBA was an attempt to modernize RPC by making it object oriented and providing a standard
- 21. CORBA Figure shows the four main elements of the architecture. Object Request Broker CORBA Services CORBA facilities Application Objects
- 22. CORBA-Object Request Broker is the case of OMG Architecture is the object bus lets objects transparently make request to - and receive response from – other objects located locally or remotely. Through ORB objects written in the different languages on different machines of different architecture running different operating system can communicate to each other.
- 23. CORBA- CORBA Services Are Collections of system – level service packages with IDL specified interfaces. They augment the functionality of ORB. They include Life Cycle services Persistence Services Naming Services Event Service Concurrency control service Transactional Service Relationship Service Externalization Query Service Licensing Service Properties Service Time Service Security Service Trader Service Collection Service etc.
- 24. CORBA-CORBA facilities Are collections of IDL – defined frameworks that provide services of direct use to application objects. Categories Horizontal Vertical Includes Interfaces for display, printing Help Workflow management. Facilities for specific application
- 25. CORBA-Application Objects. These are business objects. Clients and Server Objects. According to OMG : A business object is an application – level component you can use in unpredictable combinations. A business object is by definition, independent of any single application. Examples Customer Order Library Payment etc. A distributed object framework lays foundation for component based future. A distributed object has to be a component.
- 26. A summary on Java RMI, DCOM and CORBA Java RMI, DCOM and CORBA have all been around for some time and represent the most popular distributed, object-oriented middleware which can be used to rapidly develop distributed client/ server applications. They use proprietary communication protocols – e.g. Java RMI uses JRMP, DCOM uses ORPC and CORBA uses IIOP – to invoke remote objects or components. middleware such as Java RMI, DCOM and CORBA are not based on open standards, which makes it dif.cult for them to be ubiquitously taken up in heterogeneous environments. Ideally, what is needed is an open standards-based middleware infrastructure for building and integrating applications in heterogeneous environments, and Web services are emerging as such an infrastructure.
- 27. Service – Oriented Architecture (SOA) Structured Object Oriented Component Based All these developments have ignored the aspect of interoperability Interoperable messages and exchange patterns. SOA is concerned with interoperable message interchange to / and or from a message producer Consumer Producer message
- 28. Service Oriented Architecture Intended to define loosely coupled Services / Applications To define a process for integrating these interoperable components Applications are composed dynamically from the deployed and available services in the network They provide increased availability and stability to the users. Existing Web System: Browser Web Server Consumer Producer MESSAGE HTML / XHTML
- 29. Service Oriented Architecture The existing interoperability is inadequate Needs more polished message exchange patterns to adapt to any user agent and / or applications of choice Requires more generalized solution : Web Services Web Services Architecture extends the above interaction pattern by adding XML XML’s power and expressiveness serves the purpose. Any Consumer Any Producer Message XML
- 30. Issues with Existing Models Proprietary protocols Interoperability Platform lock-in Flexibility
- 31. What is SOA? IT architecture for request - reply applications Application functions are modularized and presented as services Services are loosely coupled Service interface is independent of the implementation
- 32. Characteristics of SOA Services have platform independent, self describing interfaces (XML) Messages are formally defined Services can be discovered Services have quality of service characteristics defined in policies Services can be provided on any platform SOA Interoperable Loosely Coupled Re-Usable Composable
- 33. Service The delivery of software as a service that is, like electricity or gas to your home Web services are the Distributed Computing equivalent of electrical socket
- 34. Anatomy of a Service Service Consumer Interface Proxy Service Interface Service Implementation New Service Wrapped Legacy Composite Service
- 35. Service Communication Communicate with messages No knowledge about partner Likely heterogeneous Service Consumers Service Producers
- 36. The SOA Interaction Pattern Discover Publish Interact SOA : Emphasizes on Standard Service Description Registration Discovery Interaction Registry Service Consumer Service Producer Service Service Description
- 37. Benefits of SOA Better reuse Build new client functionality on top of existing Business Services Well defined interfaces Make changes without affecting clients Easier to maintain Changes/Versions are not all-or-nothing Better flexibility
- 38. WEB SERVICES
- 39. WEB SERVICES Web services are emerging as a promising infrastructure for building distributed applications. Web services are based on a Service-Oriented Architecture (SOA) in which clients are service requestors and servers are service providers. Web services differ from other approaches such as Java RMI, CORBA and DCOM in their focus on simple open standards such as XML and HTTP, which have wide industry support and a chance of becoming truly ubiquitous. Essentially, a Web service is a loosely coupled, encapsulated, platform and programming language neutral, composable server-side component that can be described, published, discovered and invoked over an internal network or on the Internet.
- 40. • Loosely coupled : A Web service implementation is free to change without unduly impacting the service client as long as the service interface remains the same. • Encapsulated : The implementation of a Web service is completely invisible to the client of a service. • Platform and programming language neutral : A Web service can be implemented in any language and deployed on any platform. • Composable : A Web service can be composed from a number of deployed services. • Server-side component : A Web service can range in scope from a complete application to a subroutine that runs on a server.
- 41. • Described : An XML-based interface is used to describe the functionality and capabilities that a Web service can provide. • Published : A Web service can be registered with a service registry that can be accessed on an intranet or on the Internet. • Discovered : A Web service client can discover a service by searching a service registry and match their service requirements. • Invoked : A Web service can be bound to by a service client via standard transport protocols such as HTTP or FTP. • Internal network or the Internet : A Web service can be made available strictly within an organization or it can be offered across the.rewall, available to any consumer connected to the Internet.
- 42. What are Web Services? Web services are application components Web services communicate using open protocols Web services are self-contained and self-describing Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services
- 43. How Does it Work? The basic Web services platform is XML + HTTP. The HTTP protocol is the most used Internet protocol. XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions. Web services platform elements SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language)
- 44. Web services have two types of uses. Reusable application components There are things different applications needs very often. So why make these over and over again? Web services can offer application components like currency conversion, weather reports or even language translation as services. Ideally, there will only be one type of each application component, and anyone can use it in their application. Connect existing software Web services help solve the interoperability problem by giving different applications a way to link their data. Using Web services you can exchange data between different applications and different platforms.
- 45. Web Services have three basic platform elements. These are called SOAP, WSDL and UDDI.
- 46. What is SOAP? The basic Web services platform is XML plus HTTP. SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is for communication between applications SOAP is a format for sending messages SOAP is designed to communicate via Internet SOAP is platform, language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls SOAP will be developed as a W3C standard
- 47. What is WSDL? WSDL is an XML-based language for describing Web services and how to access them. WSDL stands for Web Services Description Language WSDL is written in XML WSDL is an XML document WSDL is used to describe Web services WSDL is also used to locate Web services WSDL is not yet a W3C standard
- 48. Thank You