Distributed Enterprise
Software Technologies
Diya Ajith
Saira Kazmi
Sumit Narayan
{diya,saira,sumit}@engr.uconn.edu
CSE 333 : Distributed Component Systems
Prof. Steve Demurjian
Distributed Systems


Extends OOP
Reasons:




Data used is distributed
Computation is distributed
Users of application are distributed
2 Key things to look for


Platform-independent models and
abstraction that one can apply
Hide as much of low-level
complexity as possible, without
sacrificing too much performance
Shared Objects
• Easy to Re-use
• Easy to distribute
• Easy to maintain
Distributed Systems
Fundamental Realities of Distributed Systems
Co-located
Distributed
Communication
Fast
Slow
Failures
Objects fail together
Objects fail separately,
Network can partition
Concurrent Access
Only with multiple
threads
Yes
Secure
Yes
No
Focus of Project



Investigate the technology from architecture,
security, remoting and inter-operability
perspective
Build example that demonstrate the use of
related APIs
Compare with other technologies
Our area of concentration
Distributed Object Components
CORBA
J2EE
.Net
Distributed Enterprise
Software Technologies
CORBA
Major Contributor: Sumit Narayan
CORBA: A Specification

OMG (Object
Management Group)
supplies a balanced
set of flexible
abstraction and
concrete services
CORBA Language Mappings
Ada
C
C++
COBOL
Java to IDL
Lisp
CORBA Scripting Language
Smalltalk
Others
Perl
Haskell
Python
Eiffel
PHP/ORBit
Tcl
CORBA: A Specification

Differ from typical programming languages



Objects can be located anywhere on the network
Objects can inter-operate with objects on other platform
Objects can be written in any programming language for
which there is mapping from IDL to that language
Application
Interfaces
Domain Interfaces
Object Request Broker
Object Services
CORBA



It is a specification, just like EJB
Allows various platforms, programming
language and vendors to interoperate
CORBA as Standard for Distributed Objects

Portable


Defines application programming interface (API) for both
server and client object implementation
Inter-operability

Defines network protocol IIOP (Internet Inter-ORB Protocol);
allows clients using CORBA product from any vendor to
communicate with objects using CORBA product from any
other vendor
CORBA

CORBA Services (COS)


Services to support integration and inter-operation of
distributed objects
They are defined on top of ORB – defined as
standard CORBA Objects with IDL interfaces
Factory
Naming
Context
Object Request Broker
Event
Channel
Object Life
Cycle
Naming
Events
Relationships
Externalization
Transactions
Trader
Query
Property
CORBA: Features
Client Application
Static
Stub
DII
Server Application
ORB
Interface
ORB
Interface
Skel
eton
DSI
Object Adapter
Client ORB Core
Network
IDL - Independent
Same for all
applications
Server ORB Core
There may be multiple
object adapters
CORBA: Architectural Goals








Simplicity
Consistency
Scalability
Usability for end users
Usability for administrators
Usability for implementers
Flexibility of security policy
Independence of security technology
CORBA: Architectural Goals




Application Portability
Interoperability
Performance
Object Orientation
CORBA: IDL

IDL – Advantages?


Modification of client code without the impact of
server code, vice-versa
IDL – Disadvantage?

A complete new language with C++ syntax;
programmer need to know to prepare IDL module
CORBA

Basic Object Adapter (BOA)


Provides basic services to allow variety of CORBA
Objects to be created – ambiguous
Portable Object Adapter (POA)


Allow developers to construct object implementations
that are portable between different ORB
Mediator between ORB and Server
Server Applications
Servants
Client
ORB
Incoming Request
POA
CORBA: POA Policies


Provided to the programmer to have control over
the object’s identity, state, storage and life-cycle
7 different policies

Thread Policy




Depends on the number of objects the application will have
Depends on the operating system
Expected load on the system
ORB_CTRL_MODEL / SINGLE_THREAD_MODEL
CORBA: POA Policies

Life Span Policy




Object ID Uniqueness Policy


Transient object cannot live beyond the process which created
it
Persistent object can live beyond the process which created it
TRANSIENT / PERSISTENT
UNIQUE_ID / MULTIPLE_ID
ID Assignment Policy


To specify whether the Object ID was generated by the
application or ORB
USER_ID / SYSTEM_ID
CORBA: POA Policies

Servant Retention Policy



Request Processing Policy



Whether POA retains active servants in object map
RETAIN / NON_RETAIN
How the request should be processed by the POA
USE_ACTIVE_OBJECT_MAP_ONLY /
USE_DEFAULT_SERVANT / USE_SERVANT_MANAGER
Implicit Activation Policy


Whether implicit activation of servants is supported by POA
IMPLICIT_ACTIVATION / NO_IMPLICIT_ACTIVATION
CORBA: Remoting


Relies on protocol called Internet Inter-ORB
Protocol (IIOP)
The service provided by the remote object is
described as Interface Definition Language (IDL)





Modularized object interfaces
Exceptions raised by an operation
Data types of an operation return value, its parameters
IDL supports multiple inheritance, depends on the
language to which it is mapped
IDL generates type information for each method in an
interface, and stores it in the Interface Repository (IR).
The client can hence query IR, and invoke the method
through Dynamic Invocation Interface (DII)
CORBA: Remoting



On server side, Dynamic Skeleton Interface
(DSI) will accept these requests
CORBA’s language independence - major
advantage
Requires fluency in IDL Programming
CORBA: Repositories

Interface Repository




Client access to definitions
Type checking for
signatures
Traversal of inheritance
graphs
Implementation repository





Location of implementation Access
Activation information
Administration control
Security
Resource allocation
IDL Interface
Definitions
Interface
Repository
Implementation
Installation
Client
Stubs
Includes
Client
Implementation
Skeletons
Implementation
Repository
Describes
Includes
Object Implementation
CORBA: Inter-operability

Achieved by Interface Definition Language (IDL)




Programming language neutral
Declarative, descriptive, C++ syntax like
Allows applications written in different programming
languages to inter-operate
Representation for minimum of following must be
present in the target language: literals, identifiers,
basic and constructed data types, modules and
interfaces
CORBA: Inter-operability



Mapped by a stub-compiler; to stubs in component’s
programming language - compiled and linked to
component code
Handles communication with remote machine via
ORB
For inter-operability between different vendors, use of
GIOP/IIOP
CORBA: Security
Considerations

Threat to CORBA System






Authorized user gaining access to data that should be
hidden from him
User masquerading as someone else; so that actions
are attributed to the wrong person
Security controls being by-passed
Eaves-dropping on communication line – gaining
access to confidential data
Tampering with objects
Lack of accountability
CORBA: Security
Considerations


Security Reference Model (SRM)
Security Specification is meta-model


Specification that is comprehensive (MAC,
Encryption)
Language Independent (C++, Java….)
CORBA: Security
Encapsulated within IDL modules:


Security: basic interface and data
types
SecurityLevel1: most basic, provides
security feature to all app.
SecurityLevel2: permits access to
credentials & policies
SecurityAdmin: permits manipulation
of administrative features
API

Which implements
abstraction defined in
the reference model
Security Technology

Constitutes
mechanisms like
encryption, validation
CORBA: Security
Specifications

4 key aspects of security




Confidentiality
 Authenticate – use principal
authentication Object
Integrity
 Prevents undetected,
unauthorized modification of
messages
 Detects message addition,
deletion or change of order
Accountability
Availability
User
Sponsor
Client
Application
Security Service
ORB Core
Security Technology
User
Sponsor
Principal
Authenticator
Object
Client
Application
Security
Current
Object
ORB
Credentials
Object
CORBA: Security
Specifications

Security Conformance
Level


User
Sponsor
Applications unaware
Applications aware
 Policy controlling
 Policy enforcing
Client
Application
Security Service
ORB Core
Security Technology
User
Sponsor
Principal
Authenticator
Object
Client
Application
Security
Current
Object
ORB
Credentials
Object
CORBA: Security
Client Application
Target Object
(Message Sender)
Execution Context
Credential
Identity
Privileges
Message
Domain
Policy
Enforcement
Code
Security Enforcement Subsystem
ORB
Domain
Policy
CORBA: Understanding





Will run on any platform as long as ORB
implementation exist.
Provides extensibility, but is difficult
Does not provide cross-language inheritance
and exception capabilities
Responsibility of locating an object
implementation is on ORB
Parameters between client and remote objects:
interface types are passed by reference; others
by value
CORBA: Understanding



Does not attempt to perform general-purpose
distributed garbage collection
Exception handling is taken care by the
Exception object
Provides location independence
Distributed Enterprise
Software Technologies
J2EE
Major Contributor: Saira Kazmi
J2EE Introduction


A component-based approach for design,
development, assembly, and deployment of
software.
The J2EE platform offers






a multi-tiered distributed application model
reusable components
a unified security model
flexible transaction control
web services support using XML based open standards
and protocols.
The Sun Java System Application Server is a build
and runtime environment that lets you build, deploy,
and run enterprise applications.
Distributed Multi-tiered
Applications
Components




J2EE applications are made up of components that are selfcontained functional software units that may communicate with
other components.
The J2EE specification defines the following components:
• Application clients and applets that run on the client.
• Java Servlet and JavaServer Pages™ (JSP™) are Web
based components that run on the server.
• Enterprise JavaBeans™ (EJB™) are business logic
components that run on the server.
J2EE components are written in Java.
Different from “standard” Java classes because J2EE
components are assembled into a J2EE application and are run
and managed by the J2EE server where they are deployed.
Enterprise
Information System
Tier



Business logic and functionality can organized into various components.
J2EE server provides underlying services in the form of a container for
every component type.
The programmer does not develop these services and is free to
concentrate on solving the business problem at hand.
Container Services


Containers provide interface between a component and the low-level
platform specific functionality supporting the component.
Before a component can be executed, it must be assembled into a J2EE
module and deployed into its container.
Container Services include:




Security (configurable)
System resources can only be used by authorized users/components.
Transaction management
Relationships among methods that make up a single transaction can be
specified.
Java Naming and Directory Interface™ (JNDI) lookups
JNDI lookup service provides naming and directory services to lookup
distributed components.
Remote connectivity
The J2EE remote connectivity model manages low-level communications
between clients and enterprise beans.
J2EE server
A J2EE server provides EJB and Web containers.
Enterprise JavaBeans (EJB) container
Manages the execution of enterprise beans.
Web container
Manages the execution of JSP pages and Servlet components.
Application client container
Manages the execution of application client components.
Applet container
Manages the execution of applets.
Packaging






A J2EE application is delivered in an Enterprise Archive (EAR)
file.
Forms a J2EE application using components.
The .EAR file contains J2EE modules and deployment
descriptors.
A deployment descriptor is an XML document describing the
deployment settings of an application, a module, or a component.
(for example security settings)
It can be changed without the need to modify the source code.
At runtime, the J2EE server uses the deployment descriptor to
deploy/run a component.
Remoting
Java Message Service API (JMS)


A messaging standard that allows J2EE
application components to create, send,
receive, and read messages.
It enables loosely coupled, reliable, and
asynchronous communication between
distributed components.
Remoting
Java API for XML-Based RPC

JAX-RPC enables the development of Web services using XMLbased remote procedural calls over the internet.

Uses SOAP and HTTP standards

Developer does not directly create SOAP messages.

WSDL is supported allowing for easy operability with non-Java
platforms like .NET

Can combine HTTP with a Java version of the Secure Socket Layer
(SSL) and Transport Layer Security (TLS) protocols to establish
basic or mutual authentication.

SSL and TLS ensure message integrity by providing data encryption
with client and server authentication capabilities.
Details of JAX-RPC
Basic Idea

A client creates a proxy and then simply invokes methods on the proxy.

A service endpoint interface (SEI) is a Java interface that declares the methods
that a client can invoke on the service.
Procedure

First Define the SEI and implementation class and interface configuration files
(service).

Compile the SEI and implementation class.

Use wscompile to generate the WSDL compliant files needed to deploy service.

Use deploytool to package the files into a WAR file.

Deploy the WAR file.

The tie classes (which are used to communicate with clients) are automatically
generated by the Application Server during deployment.



Define the client class and configuration file.
Use wscompile to generate and compile the stub files.
Compile and run the client class.
(final report includes an example of this)
Java RMI








Both Java/RMI and RMI – IIOP are provided as middleware
options.
Java Remote Method Invocation (RMI) is an Inter-process
protocol
RMI enables object-oriented distributed computing.
The server object makes methods available for remote invocation
by binding to a Name in the RMI Registry.
The client object, can check availability by looking up the name in
the RMI Registry.
RMI Registry thus acts as a central management point
It is a name repository and does not actually invoke the objects.
The RMI Registry holds onto the remote object stubs which it can
give to clients.
Java RMI
The application layer sits on top of the RMI system.
A client invoking a method on a remote server object actually makes
use of a stub or proxy.
Stubs are generated using the rmic compiler.
The remote reference layer is responsible for carrying out the semantics
of the invocation.
Security
Authentication, limiting access for different users/roles, and
secure transfer of data across network software components is a
major concern for enterprise applications.
 Security for J2EE components is provided by their containers.
A container provides two kinds of security:
Declarative security expresses an application’s security
structure, including security roles, access control, and
authentication requirements, in a deployment descriptor for the
component.
Programmatic security is embedded in an application and is used
to make security decisions. It is useful when declarative security
alone is not sufficient to express the security model of an
application.

Security
The J2EE server’s authentication service includes and interacts with
the following components:
Realm: A collection of users and groups that are controlled by the
same authentication policy.
User: An individual (or application program) identity that has been
defined in the Sun Java System Application Server. Users can be
associated with a group.
Group: A set of authenticated users, classified by common traits,
defined in the Application Server.
Role: An abstract name for the permission to access a particular set of
resources in an application.
Security in Web Applications

For any WAR created, security options can
be specified for:





User authentication method
Security constraints (access privileges)
Web resource collections
Network security requirement (basic or SSL)
Authorized roles
Interoperability
All Java interoperability features are includes in J2EE.
In addition J2EE provides the following integration tools:




Unified application model across tiers with enterprise beans (less
complex modules enhance interoperability).
Simplified interoperability with the Java Connector Architecture
(JCA) for legacy components.
Easy database connectivity with the JDBC API
Enterprise application integration with message-driven beans and
JMS(Java Message Service), JTA(Java Transaction API), and
JNDI(Java Naming and Directory Interface)
Interoperability




The EJB/CORBA mapping specification and RMI-IIOP enables
EJB components to be exposed as CORBA objects making them
well suited for cross-language interoperability.
Multiple operating systems supported.
XML-based data interchange integration with JAXP(Java API for
XML Processing), SAAJ (SOAP with Attachments API for Java),
and JAX-RPC (Java API for XML-based RPC)
A JAX-RPC Service provider can interoperate with any
SOAP/WSDL compliant system
Distributed Enterprise
Software Technologies
.Net
Major Contributor: Diya Ajith
.NET Framework Architecture
.Net

CTS (Common Type System)


CLR (Common Language Runtime)
Manages the execution of a .Net application, provides
cross platform support by ensuring type safety, code
verification, exception handling, garbage collection
and memory management
ASP.NET
 This component provides a layer of classes for Web
services


Defines Common standard that languages should
adhere to.
.Net

Windows Forms


ADO.NET


Provides a layer of classes for the windows user
interface
Provides classes for data access including database
and XML
Base Class Library

Provides the low level classes on which most of the
.Net functionality and other >net Framework classes
are built
Remoting



Remoting makes an object in one process
available to an application in another process
Marshalling enables a controlled data
communication between the 2 processes
Marshalling an object can be done in 2 ways


Marshall by value:Server creates a copy of the object
and passes the copy to the client
Marshall by reference: The server creates a reference
of the object ans send this reference to the client
Remoting
When a client calls an object marshalled by reference of
the object in the client’s application domain and the
client uses that proxy to access that original object on
the server
Remoting
When a client calls an object marshaled by value the server
creates and exact copy and sends that copy to the client.
The client then uses the data of the object and executes
the required functionality directly within the client’s own
process without making any additional calls to the server
Web Services ASP.NET
Communication based on open protocols
- Data
XML
-Schema
XSD
 UDDI
 DISCO
 WSDL
 SOAP
 Security

ADO.NET
Security

Code Based Access Control
Gives Permissions at the code level to access resources
depending on evidence permission and security policy

Role Base Access Control
Gives permission to user to access the resources based on
the role

Secure Code Verification and Execution
Ensures that the executing code stays in it’s domain

Secure Communication
Ability to pass messages locally or remotely in a secure
manner to avoid data modification

Secure Code and Data Protection
Ensures that code hasn’t been modified without authorization
using cryptographic and signed distribution files
Comparison

Security




J2EE and .NET provide easy to use Security models.
J2EE provides tools to specify roles for users/code
J2EE provides security management for its
componets
In CORBA, the security can be defined at various
levels, varying from basic interface to system
administration level.
Comparison

Database connectivity


Java uses JDBC and .Net uses Ado.net or
ODBC.NET.
ADO.net is not flexible and ODBC is very slow,
JDBC is more flexible because of the data source
object.
Comparison

Cross platform interoperability
J2EE and CORBA supports cross platform
interoperability, whereas .Net only supports windows.

Cross language interoperability
.Net and CORBA supports a number of languages
whereas J2EE RMI only supports only Java

Cross vendor interoperability
J2EE and CORBA cross vendor interoperability is
guaranteed by specifications, where as Microsoft is the
only vendor for .Net
Remoting

Remote Objects Written in Java RMI Interact
Approximately in Much the Same Way CORBA
Objects do. Server Objects Publish Their
Interfaces to Make Them Available to RMI
Clients. Stub Classes Deal With Binding to the
Remote Objects and Do the Client-side Data
Marshaling. Skeleton Classes on the Serverside Handle Incoming Calls. This Looks Very
Much Like the Elementary ORB Structure of
CORBA.
Remoting



Since Java-RMI Is Tightly Coupled With the
Java Language, Java-RMI Can Work With
True Sub-classes.
Parameters Passed During Method Calls
Between Machines Can Be True Java Objects.
 This Is Impossible in DCOM or CORBA at
Present.
Over and Above All This, J2EE Supports
Distributed Garbage Collection That Ties Into
the Local Garbage Collectors.
Remoting
Differences



RMI emphasis on JAVA only development whereas .NET
emphasizes flexibility and extensibility. CORBA is
language independent.
.Net does not have a standard protocol, it uses channels,
formatter and message sinks. The standard channels
are Httpchannel and TCPchannel.
.Net has the ability to configure remote objects using
only external configuration files, this simplifies the server
code. CORBA separates the implementation from the
server program, thus making it simpler to modify
Remoting

In Corba Remote object Interface is defined using IDL
which provides a separation between interface and
implementation. IDL is language independent. But in
java the interface is implemented in java and in .NET
there is no separation between the interface and
implementation.
Distributed Enterprise
Software Technologies
Thank You !!