Unit 2 PPT slides

1. Unit 2 PPT slides MWT

2. MIDDLE WARE TECHNOLOGIES B.TECH III YR II SEMESTER UNIT 2 PPT SLIDES TEXT BOOKS: 1.Client/Server programming with Java and CORBA Robert Orfali and Dan Harkey, John Wiley & Sons,SPD 2nd Edition 2. Java programming with CORBA 3rd Edition, G.Brose, A Vogel and K.Duddy, Wiley-dreamtech, India John wiley and sons

3. INDEX UNIT 2 PPT SLIDES S.NO. TOPIC LECTURE NO. PPTSLIDES 1. Review of Java concepts - RMI L7 L1. 1 TO L1.4 2. Review of Java concept RMI API L8 L2. 1 TO L2.4 3. Review of Java concept JDBC L9 L3. 1 TO L3.4 4. Client/Server CORBA-style L10 L4. 1 TO L4.4 5.The object web: L11 L5. 1 TO L5.5 6. CORBA With Java L12 L6.1 TO L6.5 7.Benefits of CORBA orb L13 L7.1 TO L7.5

4. UNIT2 syllabus • Review of JAVA concepts like RMI, • RMI API,JDBC,client/server CORBA-style,the object web,CORBA with java

5. RMI • RMI is the technology is used to invoke remote objects from client • 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 lecture1 slide 1

6. Distributed object systems • Java RMI • CORBA • DCOM • SOAP lecture1 slide 2

7. Review of Java concepts - RMI • The message-passing paradigm is a natural model for distributed computing – it mimics inter-human communications. • It is an appropriate paradigm for network services, where processes interact with each other through the exchange of messages. lecture1 slide 3

8. Review of Java concepts - RMI • But the abstraction (APIs such as Java unicast and multicast socket APIs provide it) provided by this paradigm may not meet the needs of some complex n/w apps for the following reasons: lecture1 slide 4

9. Review of Java concepts - RMI • Basic message passing requires that the participating processes be tightly coupled i.e., throughout their interaction, the processes must be in direct communication with each other. lecture 2 slide 1

10. Review of Java concepts - RMI • The message-passing-paradigm is data-oriented. Each message contains data marshaled in a mutually agreed upon format, and each message is interpreted as a request or response according to the protocol. The receiving of each message triggers an action in the receiving process. lecture 2 slide 2

11. Message-passing paradigm • The message-passing paradigm is inadequate for complex apps involving a large mix of requests and responses lecture 2 slide 3

12. Distributed Object paradigm • The dist. Object paradigm provides abstractions beyond those of the message-passing model. It is based on objects that exist in a dist. System. • In a OOP language such as Java, objects are used to represent an entity that is significant to an app. • Each object encapsulates – • The state or data of the entity – In Java, instance variables of each object; • The operations of the entity – through which the state of the entity can be accessed or updated – In Java, these are the methods. lecture 2 slide 4

13. Illustration • A process running in Host A makes a method call to a dist. Object residing on host B; passing with the call, the data for the arguments, if any. • The method call invokes an action performed by the method on Host B, and a return value, if any is passed from Host B to host A. • A process that makes use of a dist. object is said to be a client process of that object and the methods of the object are called remote methods to the client process. • The paradigm is known to be action-oriented. lecture 3 slide 1

14. An archetypal Distributed object architecture • The Object client looks up the registry for a reference to the object. • Thereferenceis used by the object client to make calls to the methods of the remote object or remote methods. • The call is handled by a S/W component, called a client proxy. • The Run-time support is responsible for the IPC (marshaling of argument data). lecture 3 slide 2

15. An archetypal Distributed object architecture • The Run-time support handles the receiving of messages and the unmarshalling of data and forwards the call to a S/W component called the server proxy. • The Server Proxy invokes the method call locally, passing in the unmarshalled data for the arguments. • The outcome of the execution of the method, including the marshaled data for the return value is forwarded by the server proxy to the client proxy; via the run-time support and n/w support for both sides. lecture 3 slide 3

16. Distributed Object Systems: Most popular toolkits: • Java RMI • CORBA • DCOM and • Toolkits and APIs that support the Simple Object Access Protocol (SOAP), which is a web based protocol. lecture 3 slide 4

17. Steps in a Remote Procedure Call • Proc1 on Host A makes a call to Proc2 on Host B. • The Run-time support maps the call to a call to the proxy on Host A. • The proxy marshals the data and makes an IPC call to a proxy on Host B. • The proxy on Host B unmarshals the data received and issues a call to Proc2. • The code in Proc2 is executed and returns to the proxy on Host B. • The proxy marshals the return value and makes an IPC call to the proxy on Host A. • The proxy receives the return value, unmarshals the data, and forwards the return value to Proc1, which resumes its execution flow. lecture 4 slide 1

18. note • Since its introduction in 1980s, RPC has been widely in use in n/w apps. • Two prevalent APIs – The open N/W Computing RPC (Sun Micro – early 80s) and Open Group Distributed Computing Environment (DCE) RPC. • Both provide a tool rice, for transforming remote procedure calls to local procedure calls to the sub. • RPC APIs employ syntax for procedural or function calls and are suitable for procedural languages such as C. • For an object oriented language like Java, RPC is not suitable – Java provides the RMI API; which is object-oriented and has a syntax that is more accessible than RPC. lecture 4 slide 2

19. RMI • RMI is an object-oriented implementation of the RPC model. • It is an API for Java programs only. • Using RMI, an object server exports a remote object and registers it with a directory service. • The object provides remote methods, which can be invoked in client program. • Syntactically, a remote object is declared with a remote interface, an extension of the Java interface. • The remote interface is implemented by the object server. • An object client accesses the object by invoking its methods; using syntax similar to local method invocations. lecture 4 slide 3

20. The API for the Java RMI • There are three areas to be covered. • The remote interface; • The server-side S/w; • The client-side S/w • The Remote Interface – is the starting point of creating a distributed object. lecture 4 slide 4

21. Review of JDBC • SQL-Level • 100% Pure Java • Keep it simple • High-performance • Leverage existing database technology • why reinvent the wheel? • Use strong, static typing wherever possible • Use multiple methods to express multiple functionality lecture 5 slide 1

22. JDBC Drivers • Type I: “Bridge” • Type II: “Native” • Type III: “Middleware” • Type IV: “Pure” lecture 5 slide 2

23. Type I Drivers • Use bridging technology • Requires installation/configuration on client machines • Not good for Web • e.g. ODBC Bridge lecture 5 slide 3

24. Type II Drivers • Native API drivers • Requires installation/configuration on client machines • Used to leverage existing CLI libraries • Usually not thread-safe • Mostly obsolete now • e.g. Intersolv Oracle Driver, Web Logic drivers lecture 5 slide 4

25. Type III Drivers • Calls middleware server, usually on database host • Very flexible -- allows access to multiple databases using one driver • Only need to download one driver • But it’s another server application to install and maintain • e.g. Symantec DBAnywhere lecture 5 slide 5

26. Type IV Drivers • 100% Pure Java -- the Holy Grail • Use Java networking libraries to talk directly to database engines • Only disadvantage: need to download a new driver for each database engine • e.g. Oracle, mSQL lecture 6 slide 1

27. Client/Server CORBA style • The Common Object Request Broker Architecture(CORBA) is the most ambitious middleware project ever undertaken by our industry. • It is the product of a consortium – called the Object Management Group (OMG) that includes over 800 companies. • Microsoft has its own competing object broker called the Distributed Component Object Model (DCOM). • CORBA was designed to allow intelligent components to discover each other and interoperate an object bus lecture 6 slide 2

28. Client/Server CORBA style • Services provided – creating and deleting objects, accessing them by name, storing them to persistent stores, externalizing their states, and defining ad hoc relationships between them. • CORBA lets us create an ordinary object and then make it transactional, secure, lockable, andpersistent by making the object multiply – inherit from the appropriate services. • IDL – Interface Definition Language is used to write the specifications. Components written to IDL should be portable across languages, tools, OSs, and n/ws. lecture 6 slide 3

29. Distributed CORBA Object: • CORBA objects are blobs of intelligence, that can live anywhere on a network. • They are packaged as binary components that remote clients can access via method invocations. • Both the language and compiler used to create server objects are totally transparent to clients. • Location transparency, OS transparency. • The interface serves as a binding contract between clients and servers. lecture 6 slide 4

30. Benefits of CORBA ORB • Static and Dynamic method invocations. 2. High-level language bindings. • Self-describing system – run-time metadata. • Local/Remote transparency. • Built-in security and transactions. • Polymorphic messaging. • Coexistence with existing systems – separation of an object’s definition from its implementation is perfect for encapsulating existing applications. lecture 6 slide 5

31. Benefits of CORBA ORB • Static and Dynamic method invocations: A CORBA ORB lets you either statically define your method invocations at compile time, or it lets you dynamically discover them at run time. So you either get strong type checking at compile time or maximum flexibility associated with late (runtime) binding. Most other forms of middleware only support static bindings. lecture 7 slide 1

32. Benefits of CORBA ORB • High-level language bindings: A CORBA ORB lets you invoke methods on server objects using your high-language of choice. It doesn’t matter what language server objects are written in. CORBA separates interface from implementation and provides language-neutral data types that make it possible to call objects across language and OS boundaries. In contrast, other types of middleware typically provide low-level, language-specific, API libraries. And they don’t separate implementation from specification – the API is tightly bound to the implementation, which makes it very sensitive to changes. lecture 7 slide 2

33. Benefits of CORBA ORB • Local/Remote Transparency:An ORB can run in stand-alone mode on a laptop, or it can be interconnected to every other ORB in the Universe using CORBA 2.0’s Internet Inter-ORBProtocol (IIOP) services. An ORB can broker inter-object calls within a single process, multiple processes running across networks and OSs, which is completely transparent to your objects. Note: CORBA can broker among fine-grained objects – like C++ classes – as well as more coarse-grained objects. lecture 7 slide 3

34. Benefits of CORBA ORB • Self-describing system: CORBA provides run-time meta data for describing every server interface known to the system. Every CORBA ORB must support an Interface Repository that contains the real-time information describing the functions a server provides and their parameters. Metadata is useful for clients to discover how to invoke services at run-time; and tools to generate code “on-the-fly”. The meta data is generated automatically either by an IDL-language pre-compiler or by compilers that know how to generate IDL directly from an OO language. ex: Visigenic/Netscape’s Caffeine generates lecture 7 slide 4

35. Benefits of CORBA ORB • Built-in security and transactions: The ORB includes context information in its messages to handle security and transactions across machine and ORB boundaries. • Polymorphic messaging: An ORB invokes a function on a target object – that is, the same function call will have different effects, depending on the object that receives it. ex: configure-yourself method invocation behaves differently when applied to a database object versus a printer object. • Coexistence with existing systems: CORBA’s separation of an object’s definition from its implementation is perfect for encapsulating existing applications. Using CORBA IDL, you can make your existing code look like an object on the ORB, even if it is implemented in stored procedures, CICS, IMS, or COBOL. This makes CORBA an evolutionary solution. You can write your new apps as pure objects and encapsulate existing apps with IDL wrappers. lecture 7 slide 5