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. lecture1 slide 1
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

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

7. lecture1 slide 3
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.

8. lecture1 slide 4
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:

9. lecture 2 slide 1
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.

10. lecture 2 slide 2
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.

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

12. lecture 2 slide 4
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.

13. lecture 3 slide 1
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.

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

15. lecture 3 slide 3
An archetypal Distributed object architecture
1. 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.
2. The Server Proxy invokes the method call
locally, passing in the unmarshalled data for
the arguments.
3. 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.

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

17. lecture 4 slide 1
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.

18. lecture 4 slide 2
note
1. Since its introduction in 1980s, RPC has been widely
in use in n/w apps.
2. Two prevalent APIs – The open N/W Computing RPC
(Sun Micro – early 80s) and Open Group Distributed
Computing Environment (DCE) RPC.
3. Both provide a tool rice, for transforming remote
procedure calls to local procedure calls to the sub.
4. RPC APIs employ syntax for procedural or function
calls and are suitable for procedural languages such
as C.
5. 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.

19. lecture 4 slide 3
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.

20. lecture 4 slide 4
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.

21. lecture 5 slide 1
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

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

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

24. lecture 5 slide 4
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

25. lecture 5 slide 5
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

26. lecture 6 slide 1
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

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

28. lecture 6 slide 3
Client/Server CORBA style
5. 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.
6. CORBA lets us create an ordinary object and then
make it transactional, secure, lockable, and persistent
by making the object multiply – inherit from the
appropriate services.
7. IDL – Interface Definition Language is used to write the
specifications. Components written to IDL should be
portable across languages, tools, OSs, and n/ws.

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

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

31. lecture 7 slide 1
Benefits of CORBA ORB
1. 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.

32. lecture 7 slide 2
Benefits of CORBA ORB
2. 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.

33. lecture 7 slide 3
Benefits of CORBA ORB
3. 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-ORB
Protocol (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.

34. lecture 7 slide 4
Benefits of CORBA ORB
4. 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

35. lecture 7 slide 5
Benefits of CORBA ORB
5. Built-in security and transactions:
The ORB includes context information in its messages to handle security
and transactions across machine and ORB boundaries.
6. 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.
7. 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.