Distributed Object Technology

mewstennisSoftware and s/w Development

Nov 4, 2013 (3 years and 11 months ago)

77 views

1

© Claus Pahl

Distributed Object Technology


Chapter 5





5.1

Intro Distributed Object Technology


5.2

Java RMI / Beans


5.3

CORBA


5.4

CORBA & e
-
Commerce: Security


5.5

COM/DCOM

5
-
2

© Claus Pahl

5.1


Intro Distributed Object Technology


Client components: content transport and display

+
standard technology: HTML, HTTP, browsers

+
advanced technology: MIME
-
types, plug
-
ins, scripting, Java applets, ActiveX
controls, electronic wallets (storing payment credentials for SET)

+
Scripting: small programs (scripts) are embedded in Web pages and executed
at the client’s side

+
active pages using Java or ActiveX


Server components:

+
CGI Common Gateway Interface defines an interface between Web server and
an independent application program (sometimes called gateway). The program
handles input from the client server and sends its output back to the browser.

+
Server APIs (Netscape’s NSAPI and Microsoft’s ISAPI) are application
programming interfaces that allow application software to be integrated with
with a Web server.

5
-
3

© Claus Pahl

eCommerce System Components


Session Management: the HTTP protocol is a stateless protocol,

+
nonetheless state is sometimes a convenient feature to have and

+
technologies have been realised to provide state on top of HTTP.



Cookies


forms using hidden fields


Applets



Object Technology: the approach of object
-
orientedness to analysis,
design and programming of software systems also affects
eCommerce systems.

5
-
4

© Claus Pahl

Object Technology

Here are some
principles

of object
-
oriented software development:



Encapsulation

-

objects hide details about their implementation


Polymorphism

-

there can be multiple implementations of an
object


Language binding

-

objects can be implemented in different
programming languages


Component software

-

software shall be developed in self
-
contained units

5
-
5

© Claus Pahl

Distributed Systems Technology


A
distributed system

is a collection of computers linked via some
network


Other names for distributed systems are

+
heterogeneous systems

+
federated systems


The components of a distributed system might be run under
different authorities


In distributed systems, locations of components might be
transparent.



A classical form of a distributed system is a client/server system

5
-
6

© Claus Pahl

Distributed Object Technology

Also relevant for eCommerce systems: distributed object technology


the basic idea:

+
objects should be to reside on any computer in a networked (distributed)
system

+
other programs can invoke operations by sending messages to the computer
that hosts these objects

+
ideally, these programs will not be able to distinguish between local and
remote objects


required infrastructure:

+
communication protocol between objects

+
naming: a naming and addressing system is needed to establish proper
communication

+
security: distributed systems operate over open networks; authentication,
privacy and integrity are important


5
-
7

© Claus Pahl

Platforms for Object Technology

There are several standards, quasi
-
standards and vendor

specific toolkits on the market


CORBA
-

Common Object Request Broker Architecture (by OMG)


a reference model for objects in distributed heterogeneous
environments.


(D)COM
-

(Distributed) Component Object Model (Microsoft)


an object system, part of Microsoft’s desktop operating systems and
applications, which defines communication standards


Java Beans/RMI.

+
RMI Remote Method Invocation is Java’s remote procedure call feature, i.e.
the mechanism for Java objects to communicate over a network

+
Java Beans is Java’s component technology

5
-
8

© Claus Pahl

5.2



Java RMI / Beans





Remote Procedure Calls (RPC) is a mechanism to invoke on a
computer from another computer that dates back to the 1970s.


RMI
-

Remote Method Invocation
-

is the Java RPC mechanism, i.e.
Java’s way to allow objects to communicate with another over a
network


RMI is more than RPC

+
it is object
-
based, i.e. extends classical RPC mechanisms

+
it is, however, limited to Java programs.


The RMI system is based on a 3
-
layered architecture

5
-
9

© Claus Pahl

RMI Architecture


Stub/skeleton layer

+
the layer that the remote object on a client computer and the server object
communicate with

+
stub and skeleton act as proxies for the actual remote object that is
processed

+
stub and skeleton are local objects that represent the remote object for the
local object

+
the stub is associated with the client and the skeleton with the server


Remote reference layer

+
is concerned with the protocol used to invoke remote methods (e.g. unicast or
broadcast)


Transport layer

+
is concerned with data transport for the message exchanges

+
usually TCP/IP is the transport mechanism

5
-
10

© Claus Pahl

RMI Invocation


An example: a method at a remote object shall be invoked



remoteObject.remoteMethod(arg1, arg2)

1)

The method corresponding to remoteMethod at object remoteObject
is invoked in the stub/skeleton layer (proxy)

2)

Data is sent to the reference layer which determines whether the
object referred to is local or remote.

3)

If the object is remote, the transport layer takes care of the
communication (setting up a connection and transferring data)

4)

Then the remote object processes input arguments arg1 and arg2
using remoteMethod

5)

Possibly resulting data is send back and propagated up the layers to
the client object.

5
-
11

© Claus Pahl

Development with RMI (1)


Server side:

+
develop the interface that describes the services provided by the remote
(server) object

+
implement the server code that implements the interface
-

this class need to
register itself (the object) with the RMI Registry (this registry runs a naming
and location service) by providing a service name

+
run the RMI Compiler to generate stubs and skeletons for the server class
-

leave the skeleton at the server side and transfer the stub to all possible
clients

+
start the RMI Registry on the server

+
execute the server class file
-

the server object is now ready and waiting for
incoming messages from other computers

5
-
12

© Claus Pahl

Development with RMI (2)


Client side:

+
write client code
-

this code will include a lookup call of the form




Naming.lookup(“rmi://hostname/servicename”)


where hostname is the name of the remote computer and servicename is the
name of the service that the remote object has registered

+
compile and execute the client

+
when the client is executed:


its stub for the requested service (shipped from the server) handles the
communication, i.e. a connection to the skeleton at the server side (with
access to the registry’s naming service) is made


a reference to the remote server object is made and the remote service
(method) can be invoked by the client

+
invocation of remote method: see above ...

5
-
13

© Claus Pahl

Java Beans


Java Beans are Java’s version of component software :

+
objects that are easy to reuse, compose and configure

+
objects that are internally coherent

+
objects that are describe by abstract interface (in so
-
called interface
definition languages
-

IDLs)


JavaBeans are part of Java’s middleware platform. Other packages
of the Java middleware platform are RMI, JDBC, and servlets



Enterprise JavaBeans (EJBs) carry the idea further to the context of
distributed systems and transaction processing.

+
EJBs can be easily transferred from one server to another

+
they typically encompass some business logic that relies on transaction
processing

5
-
14

© Claus Pahl

JavaBeans and EJB


Bean/EJB composition is supported by graphical editors


Similar to ActiveX, a set of interfaces is provided which allow us to
configure components at design time.


Beans/EJBs are designed to work in distributed contexts

+
can cooperate with other objects via RMI, ActiveX controls or CORBA
objects.

+
transaction processing and concurrency control is used

5
-
15

© Claus Pahl

EJB architecture


An EJB
-
compliant Web server contains a number of containers with
EJBs in them


Clients access these EJBs using method invocation facilities of the
EJB API (Application Programming Interface)



This architecture extends servlet architectures:

+
transaction management is supported

+
security (access control to EJBs) is provided

+
persistent storage of EJBs and data is provided

+
concurrent client access is managed

+
location transparency (clients should have no knowledge of location of server)
is guaranteed

5
-
16

© Claus Pahl

EJB Development Process

Six parties in the development process:


Bean developer: usually a company with expertise in some domain


Container provider: a compant that supplies a runtime environment
software for beans/EJBs


Server provider: a company that sells EJB
-
compliant servers
(usually the same as the container provider)


Application assembler: company that joins EJBs together


Deployer: company/organisation that deploy EJB assemblies (EJBs
and glue code)


System administrator: manages/maintains the running system,
looks after performance/security/reliability issues

5
-
17

© Claus Pahl

Bean Development


There are two types of beans:

+
entity bean: represents some stored entity (bank account, hotel bookings,
flight plans, ...)

+
session bean: processing
-
oriented (process debit on bank account, booking of
hotel, query flights, ...)


there are stateful and stateless session beans. An example for a stateful
session bean is a shopping cart


beans extend classes in the javax.ejb package


(graphical) editor support exists for bean assembly.


final beans/EJBs are packaged into JARs and added to servers
-

which enables others to access them

5
-
18

© Claus Pahl

5.3




CORBA






IT systems in any larger organisation have been built
-
up over the
years by constantly adding new applications.


The problem is that applications have been written in different
languages, for different hardware and software platforms using
different data formats.


Sharing data between applications within one organisation is not
easy (and gets even more difficult between organisations)


Distributed object computing

tries to resolve the situation and
to improve the
interoperability

of applications, based on

+
the client/server model from distributed computing

+
concepts from object
-
oriented computing

+
applications are viewed as objects (objects have attributes and methods, the
methods can be used to modify the attributes)

5
-
19

© Claus Pahl

Object Request Broker


The
object request broker
-

ORB

-

is a software bus located
between client and server objects handling all the communication
between objects



CORBA
-

Common Object Request Broker Architecture

-

is the
specification of an industry standard for such ORB
-
based
architectures, called
middleware

systems



CORBA was developed by the
Object Management Group

-

OMG

-

www.omg.org. OMG consists of hardware and software vendors
and other large organisations.

5
-
20

© Claus Pahl

Method Invocation

Assume an application distributed over client and server. The

application wants to invoke a method of another object at the server:


Client








Server


Method








Target


call








object





Stub






Skeleton







ORB






ORB




library






library











Activation component /






naming service

Repository

1

5

6

4

2

3

Method Invocation

5
-
21

© Claus Pahl

Method Invocation (2)

Assume an application distributed over client and server. The

application wants to invoke a method of another object at the server:


1) the method call at the client invokes the ORB functionality through
its application stub

2) the ORB library at the client initialises binding to the object by
sending a request to the activation component

3) the activation component retrieves a reference to the object
addressed by the method call from the repository

4) the activation component launches the object at the server

5) the ORB returns a reference of the object to the client

6) the method invocation is executed

5
-
22

© Claus Pahl

Interface Definition Language IDL


CORBA objects are described by an Interface Definition Language
IDL which formally defines the object’s interfaces


the IDL interface describes the object’s functionality and how a
potential client can invoke a method of the object (even if the
object is not written in the same language as the client object)


IDL is a language for defining objects


IDL solves the language binding problem through providing
language
-
specific translators which take an IDL description of an
object and translate it into a specific set of language bindings


languages currently supported include C, C++ and Java


an IDL specification can include attributes, parent classes,
exceptions raised, events generated, methods that can be invoked


an IDL specification is syntactically similar to a C++
-
class
description

5
-
23

© Claus Pahl

IDL and Java Interfaces


IDL specifications can be compiled into Java (and other language)
interfaces
-

based on mappings between a set of classical data
types (basic, operations, classes, etc)



the IDL spec



is translated into:


module Tester{



interface Single{



attribute string exname;




readonly attribute string location;



string returnsVal(in string point);



}


}



Package Tester;

public interface Single


extends org.omg.CORBA.Object

{


String exname();


void exname(String arg);


String location();


String returnsVal(String point);

}


5
-
24

© Claus Pahl

CORBA Architecture



Object Request Broker

Application

Objects





Common Facilities












Common Object Services

Naming

Security

...

...

User

Interface

5
-
25

© Claus Pahl

Object Services

Object services are system
-
level services packed as components with
IDL
-
specified interfaces


Most importantly, the ORB provides naming and communication
services


A more complete list of object services
-

available through the ORB
library:



-

naming



-

externalisation



-

events



-

querying



-

transaction



-

relationship



-

persistent object


-

property



-

lifecycle



-

security



-

concurrency control


-

trading



-

time




-

collection

5
-
26

© Claus Pahl

Object Facilities

Common Facilities are IDL
-
defined components of direct use to
application objects (on a higher level than object services)


horizontal facilities include

+
user interface editing services

+
information management services

+
system management services

+
task management services


vertical facilities provide interfaces for vertical market segments
such as

+
health,

+
finance,

+
telecommunications,

+
etc.

5
-
27

© Claus Pahl

Communication over the Internet

Several protocols, gateways and bridges are defined in the CORBA
standard:


There is a General Inter
-
ORB Protocol GIOP which describes object
communication across networks


CORBA works over the Internet using the Internet Inter
-
ORB
Protocol
-

IIOP.


IIOP defines how CORBA
-
objects communicate over the Internet


A specialised secure variant of IIOP, called SECIOP, exists


Remark: the implementation of these protocols has only begun.

5
-
28

© Claus Pahl

ORBs and RPCs

ORB method invocations and remote procedure calls shall briefly be
compared:



a remote procedure call RPC of a client program invokes a function
at some server. Data is supplied separate from the function


an ORB method invocation of a client object invokes a method of a
particular object at the server. The same method invoked at
another object might result in another behaviour. The reason for
this is that objects incorporate and maintain their own data.
Methods are implemented on that specific instance data.


The underlying communication technology is more or less the same.

5
-
29

© Claus Pahl

5.4

CORBA & e
-
Commerce: Security

The design of the CORBA security model is essentially influenced by
two of CORBA’s general design objectives

+
interoperability

+
flexibility

The problem is that these two work in different directions:

+
interoperability needs agreement (standardisation)

+
agreement limits flexibility

Thus, CORBA provides only a framework for implementing and
managing security services

+
objects with similar security requirements are grouped into domains

+
domain security policies are enforced by the ORB

5
-
30

© Claus Pahl

Authentication



User Sponsor

Principal

Authenticator

Current Object

Credentials

Object Request Broker

Client

Target

Current Object

1

2

3

4

5

5
-
31

© Claus Pahl

Authentication (2)

1) The user signs on to an ORB. The User Sponsor (typically the login
program) passes identity and password to the Principal
Authenticator object

2) The Principal Authenticator object creates a Credentials object (this
contains the user’s security attributes: roles, permissions)

3) Then the User Sponsor passes a reference to the Credentials to the
Current object (this represents the current execution context)

4) If the user wants to invoke a service, a connection between client
and target object has to be established. A security context object
will be attached to both (containing cryptographic algorithms and
keys for secure data transfer)

5) A security binding between the objects is established based on the
security context

5
-
32

© Claus Pahl

Assessing CORBA Security

CORBA promises guaranteed security. Does the promise hold?



The promise can only be guaranteed if the ORB cannot be
bypassed. That’s means that a user/client object cannot access
other service by e.g. operating systems calls.


The possibility of bypassing the ORB is given at the moment.


CORBA implementors have only started implementing security
services


As mentioned earlier on, CORBA offers only a security framework
-

we shouldn’t expect too much.

5
-
33

© Claus Pahl

5.5



COM

/ DCOM




COM
-

Component Object Model
-

was developed by Microsoft, it has
been realised as part of Microsoft’s desktop operating systems and
applications

The basic model defines communication standards


Other levels of functionality are provided under the umbrella term OLE
-

Object Linking and Embedding
-

which is another (de facto)
standard due to Microsoft’s domination in the PC
-
world

+
OLE can be seen as the object
-
oriented foundation of Windows

+
Distribution comes into the play by the fact that OLE is based on top of an
ORB
-

the Common Object Model COM

5
-
34

© Claus Pahl

COM/DCOM (2)


COM objects can be used from a scripting language such as
VBScript. Scripting provides the link between potentially complex
objects.


OLE controls, called ActiveX objects, are COM objects with
additional interfaces which make them usable as component
software.


ActiveX controls can be configured at design time through one
interface and operated at run
-
time through another


DCOM
-

or Distributed COM, uses a version of DCE RPC for its
communication protocol for objects who want to communicate via a
network.


DCE
-

Distributed Computing Environment
-

is another standard for
distributed systems, which contains the specification of a RPC
mechanism.