Inventory of Distributed Computing Concepts

1. Inventory of Distributed Computing Concepts Chapter 3

2. Motivation • Earlier attempts to replace existing systems failed; • Distributed computing environment (DCE): emphasis -- distribution • Common object request broker architecture (CORBA): emphasis -- interoperability • Uniqueness of SOA is that it leverages existing middleware and distributed computing concepts • RPC, distributed objects, message-oriented middleware (MOM), application coupling, etc.

3. Issues in distributed systems • Heterogeneity in various aspects of a distributed systems • Communication modes • Synchronous: RPC, ORB • Asynchronous: P2P, Publish and subscribe • Variations in products • Many vendors: IBM, IONA, TIBCO, Apache, Adobe • Additional runtime features: • fault tolerance, load balancing, transaction handling, usage metering, auditing, ..

4. Technical Layers Core Assets Participant A Participant B Participant C Business Logic Technology Independent Interface Description Technology Independent Interface Description Technology Independent Interface Description Middleware Mapping XML ORB Technology Adapters Middleware Buses Communication facilities CORBA XML Web services

5. Technical Layer 2 : Chapter 3 Core Assets Participant A Participant B Participant C Business Logic Technology Independent Interface Description Technology Independent Interface Description Technology Independent Interface Description Middleware Mapping XML ORB Technology Adapters Middleware Buses Communication facilities CORBA XML Web services

6. Technical Layer 1: Ch. 4 -7 Core Assets Participant A Participant B Participant C Business Logic Technology Independent Interface Description Technology Independent Interface Description Technology Independent Interface Description Middleware Mapping XML ORB Technology Adapters Middleware Buses Communication facilities CORBA XML Web services

7. Technical Layer 3: Chapter 9 Core Assets Participant A Participant B Participant C Business Logic Technology Independent Interface Description Technology Independent Interface Description Technology Independent Interface Description Middleware Mapping XML ORB Technology Adapters Middleware Buses Communication facilities CORBA XML Web services

8. Communication Network A communication middleware framework isolates the application developers from the details of the network protocol. Application Application Network Protocol Stack Network Protocol Stack

9. Communication Middleware Application Application Middleware Middleware Network Protocol Stack Network Protocol Stack

10. Remote procedure call (RPC) Client Application Server Application Procedure call Execute call RPC Stub code RPC stub code RPC library/runtime RPC library/runtime Network Protocol Stack Network Protocol Stack RPC stubs and runtime enable location transparency, encapsulate RPC communication infrastructure and provide a procedure call interface.

11. Distributed Objects Client Application Server Application invoke method Execute method Client proxies Server skeletons ORB ORB Network Protocol Stack Network Protocol Stack ORBs enable client applications to remotely instantiate, locate, invoke methods and Delete server objects; Java RMI, Microsoft’s DCOM; CORBA is meant to be platform independent.

12. What is CORBA? • Common Object Request Broker Architecture (CORBA) specification (/standard) defines a framework for object-oriented distributed applications. • It is defined by a consortium of vendors under the direction of Object Management Group (OMG).

13. What is CORBA? (contd.) • Allows distributed programs in different languages and different platforms to interact as though they were in a single programming language on one computer. • Brings advantages of OO to distributed systems. • Allows you design a distributed application as a set of cooperating objects and to reuse existing objects.

14. Object Request Broker (ORB) • A software component that mediates transfer of messages from a program to an object located on a remote host. • Hides underlying network communications from a programmer. • ORB allows you to create software objects whose member functions can be invoked by client programs located anywhere. • A server program contains instances of CORBA objects.

15. Clients, severs and objects Server0 Client CORBA Object invocation Server1

16. CORBA Objects and IDL • These are standard software objects implemented in any supported language including Java, C++ and Smalltalk. • Each CORBA object has a clearly defined interface specified in CORBA interface definition language (IDL). • The interface definition specifies the member functions available to the client without any assumption about the implementation of the object.

17. Client and IDL • To call a member function on a CORBA object the client needs only the object’s IDL. • Client need not know the object’s implementation, location or operating system on which the object runs.

18. IDL facilitates internetworking Specify in IDL Use IDL-language compiler Client sees only IDL interface C++ Java target object smalltalk OLE (VB, PB,Delphi) Ada, Cobol etc.

19. Separation of Interface and Implementation • Interface and implementation can be in two different languages. • Interface abstracts and protects details (trade secrets) from client • Interface offers a means of expressing design without worrying about implementation.

20. ORB : Conceptual View • When a client invokes a member function on a CORBA object, the ORB intercepts the function call. • ORB directs the function call across the network to the target object. • The ORB then collects the results from the function call returns these to the function call.

21. Client Object Object Stub Client Stub ORB Implementation Details Access to the services provided by an Object ORB : (Object-oriented middleware) Object Request Broker ORB mediates transfer between client program and server object.

22. Message-oriented Middleware (MOM) • Made famous by IBM’s MQseries and TIBCO’s Rendezvous products. • Based on messages and queues. • A message contains a header and a payload. • A queue can store and distribute messages. • Publish/subscribe model of communication: • A topic offers another model of communication between subscribers and publishers. • MOM allows for loose coupling between message consumers and message producers enabling dynamic, reliable, flexible, high-performance systems to be built.

23. Components and Application Servers • An application server mediates between a web server and backend systems. • Request from a web client is passed onto an application server by the web server. • Programmer productivity, cost-effective deployment, rapid time to market, seamless integration, application portability, scalability, security are some of the challenges that component technology tries to address head on. • Enterprise Java Beans is Sun’s server component model that provides portability across application servers, and supports complex systems features such as transactions, security, etc. on behalf of the application components. • EJB is a specification provided by Sun and many third party vendors have products compliant with this specification: BEA systems, IONA, IBM, Oracle, Sybase, Gemstone.

24. EJB container Web Container Web Application Enterprise Java Beans Database Server J2EE Application Programming Model for Web-based applications Business Logic Web Service Web client

25. Business Logic EJB container Application Container Enterprise Java Beans Presentation Components Database Server J2EE Application Programming Model for Three-tier Applications Study Fig. 3-8 of your text for J2EE technology suite.

26. On to more fundamental concepts: Synchrony • Synchronous and asynchronous communications • Synchronous: • immediate response of communicating partners • Server process/thread blocks until response is completed • Follows request/response pattern • Used when servers are available all the time • Typically communicating partners are tightly coupled • Examples: • request from web client to a web browser for “search” or for “information” • CORBA procedure invocation • Java RMI (remote method invocation) • Traditional remote procedure call (RPC)

27. Asynchronous communication • Communicating partners are decoupled • Message driven: • sender creates a message and delivers it to a mediator who then sends it to “a” recipient • Server need not be available all the time • Sender and receiver loosely coupled • Can facilitate high-performance message-based system • Example: • Any event-driven system • Any messaging system (instant messenger) • Publish-subscribe mode communications

28. Interface vs Payload Semantics • Typically interaction between a client and a server results in the execution of an activity (ot transaction) • Request needs to be specified by the request. • Interface semantics: Requested activity can be encoded in the operation signature in the server’s “interface” or • Payload semantics: It can be embedded in the message itself

29. Interface Semantics Process1 Process2 getCustomer() retrieveCustomerData() returnResult() Semantics of the activity is explicitly stated in the message/method call

30. Payload Semantics Envelop With message Process 1 Process 2 Requested transaction/activity is embedded in the message Details of the activity not explicit; the semantics are embedded in the message

31. Payload Semantics onMessage()

32. Payload semantics is generic String transferMoney (amt: decimal, accTo: String) { …} String executeService (message: String) { …}

33. Tool to explore • Rational rose demo model • Windows rosecppdemo.exe

34. Document-centric Messages • With emergence of self-descriptive data structures such as XML, document-centric has become popular • Semantically rich messages where operation name, its parameters, return type are self descriptive. • SOAP (Simple Object Access Protocol) over XML is an example (look at the example in p.45 of your text) • Lets look at XML, SOAP, WS evolution. WSSOA

35. Tight vs. Loose Coupling • An important characteristics of an SOA that is a loosely coupled system. • On the technology front this is driven by dynamic discovery and binding enabled by Universal Description, Discovery and Integration (UDDI) • On the business front loose coupling addresses the growing need for companies to be flexible and agile with respect changes in their own processes and those of their partners (read p.46) • How does loose coupling help in improving agility, flexibility and performance?

36. Tight vs. Loose coupling

37. Summary • We discussed the fundamental choices available to a designer in assembling a distributed system • A designer must choose appropriate communication infrastructure, synchrony, call semantics, use of intermediary, object-oriented versus data-centric interfaces. • All these factors impact the coupling of the distributed systems.