Distributed Enterprise Software Technologies Diya Ajith Saira Kazmi Sumit Narayan {diya,saira,sumit}@engr.uconn.edu CSE 333 : Distributed Component Systems

Distributed Enterprise Distributed Enterprise Software TechnologiesSoftware Technologies

Diya AjithDiya Ajith

Saira KazmiSaira Kazmi

Sumit NarayanSumit Narayan{diya,saira,sumit}@engr.uconn.edu{diya,saira,sumit}@engr.uconn.edu

CSE 333 : Distributed Component SystemsCSE 333 : Distributed Component Systems

Prof. Steve DemurjianProf. Steve Demurjian

Distributed SystemsDistributed 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 SystemsDistributed Systems

Co-located Distributed

Communication Fast Slow

Failures Objects fail togetherObjects fail separately, Network can partition

Concurrent AccessOnly with multiple

threadsYes

Secure Yes No

Fundamental Realities of Distributed Systems

Focus of ProjectFocus 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

Distributed Object Components

CORBA J2EE .Net

Our area of concentration


CORBA

Major Contributor: Sumit Narayan

CORBA: A SpecificationCORBA: A Specification

OMG (Object Management Group) supplies a balanced set of flexible abstraction and concrete services

CORBA Language MappingsAdaC

C++COBOL

Java to IDLLisp

CORBA Scripting LanguageSmalltalk

OthersPerl

HaskellPythonEiffel

PHP/ORBitTcl

CORBA: A SpecificationCORBA: 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

Object Request Broker

ApplicationInterfaces

Domain Interfaces

Object Services

CORBACORBA

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

CORBACORBA

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

Object Request Broker

FactoryNamingContext

EventChannel

Object Life CycleNamingEventsRelationshipsExternalizationTransactionsTraderQueryProperty

CORBA: FeaturesCORBA: Features

Client Application Server Application

Client ORB Core Server ORB Core

StaticStub

DII DSISkeleton

ORBInterface

ORBInterface

Object Adapter

Network

IDL - Independent Same for allapplications

There may be multipleobject adapters

CORBA: Architectural GoalsCORBA: 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 GoalsCORBA: Architectural Goals

Application Portability Interoperability Performance Object Orientation

CORBA: IDLCORBA: 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

CORBACORBA

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

Client ORB POA

Incoming Request

Server Applications

Servants

CORBA: POA PoliciesCORBA: 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


Life Span Policy Transient object cannot live beyond the process which created

it Persistent object can live beyond the process which created it TRANSIENT / PERSISTENT

Object ID Uniqueness Policy UNIQUE_ID / MULTIPLE_ID

ID Assignment Policy To specify whether the Object ID was generated by the

application or ORB USER_ID / SYSTEM_ID


Servant Retention Policy Whether POA retains active servants in object map RETAIN / NON_RETAIN

Request Processing Policy 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: RemotingCORBA: 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: RemotingCORBA: Remoting

On server side, Dynamic Skeleton Interface (DSI) will accept these requests

CORBA’s language independence - major advantage

Requires fluency in IDL Programming

CORBA: RepositoriesCORBA: Repositories

Interface Repository Client access to definitions Type checking for

signatures Traversal of inheritance

graphs Implementation repository

Location of implementation Activation information Administration control Security Resource allocation

IDL InterfaceDefinitions

InterfaceRepository

ClientStubs

Client

ImplementationInstallation

ImplementationSkeletons

ImplementationRepository

Object Implementation

AccessIncludes Includes Describes

CORBA: Inter-operabilityCORBA: 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-operabilityCORBA: 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 CORBA: Security ConsiderationsConsiderations

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 CORBA: Security ConsiderationsConsiderations

Security Reference Model (SRM) Security Specification is meta-model

Specification that is comprehensive (MAC, Encryption) Language Independent (C++, Java….)

CORBA: Security

API Which implements

abstraction defined in the reference model

Security Technology Constitutes

mechanisms like encryption, validation

Encapsulated within IDL modules:

Security: basic interface and datatypes

SecurityLevel1: most basic, providessecurity feature to all app.

SecurityLevel2: permits access tocredentials & policies

SecurityAdmin: permits manipulationof administrative features

CORBA: Security CORBA: Security SpecificationsSpecifications

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

UserSponsor

ClientApplication

ORB Core

Security Service

Security Technology

UserSponsor

ClientApplication

PrincipalAuthenticator

Object

CredentialsObject

SecurityCurrentObject

ORB

CORBA: Security CORBA: Security SpecificationsSpecifications

Security Conformance Level Applications unaware Applications aware

Policy controlling Policy enforcing

UserSponsor

ClientApplication

ORB Core

Security Service

Security Technology

UserSponsor

ClientApplication

PrincipalAuthenticator

Object

CredentialsObject

SecurityCurrentObject

ORB

CORBA: SecurityCORBA: Security

Client Application

(Message Sender)

ORB

Security Enforcement Subsystem

Execution Context

Credential

Identity

Privileges

Message

Policy Enforcement Code

Target Object

Domain

Domain Policy

CORBA: UnderstandingCORBA: 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: UnderstandingCORBA: Understanding

Does not attempt to perform general-purpose distributed garbage collection

Exception handling is taken care by the Exception object

Provides location independence


J2EE

Major Contributor: Saira Kazmi

J2EE IntroductionJ2EE 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 Distributed Multi-tiered ApplicationsApplications

ComponentsComponents J2EE applications are made up of components that are self-

contained 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 ServicesContainer 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 managementRelationships among methods that make up a single transaction can be specified.

Java Naming and Directory Interface™ (JNDI) lookupsJNDI lookup service provides naming and directory services to lookup distributed components.

Remote connectivityThe 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) containerManages the execution of enterprise beans.

Web containerManages the execution of JSP pages and Servlet components.

Application client containerManages the execution of application client components.

Applet containerManages the execution of applets.

PackagingPackaging 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.

RemotingRemoting

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.

RemotingRemoting

Java API for XML-Based RPC

JAX-RPC enables the development of Web services using XML-based 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-RPCDetails of JAX-RPCBasic 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 RMIJava 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 RMIJava 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.

SecuritySecurity

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.

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

Security in Web ApplicationsSecurity 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

InteroperabilityInteroperability

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)

InteroperabilityInteroperability 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


.Net

Major Contributor: Diya Ajith

.NET Framework Architecture.NET Framework Architecture

CTS (Common Type System) Defines Common standard that languages should

adhere to. 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

.Net.Net

Windows Forms Provides a layer of classes for the windows user

interface ADO.NET

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

.Net.Net

RemotingRemoting

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

RemotingRemoting

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

RemotingRemoting

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.NETWeb Services ASP.NET

Communication based on open protocols

- Data XML

-Schema XSD UDDI DISCO WSDL SOAP Security

ADO.NETADO.NET

SecuritySecurity

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 ExecutionEnsures that the executing code stays in it’s domain

Secure CommunicationAbility to pass messages locally or remotely in a secure manner to avoid data modification

Secure Code and Data ProtectionEnsures that code hasn’t been modified without authorization using cryptographic and signed distribution files

ComparisonComparison

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.


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.


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 interoperabilityJ2EE and CORBA cross vendor interoperability is guaranteed by specifications, where as Microsoft is the only vendor for .Net

RemotingRemoting

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 Server-side Handle Incoming Calls. This Looks Very Much Like the Elementary ORB Structure of CORBA.

RemotingRemoting

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.

RemotingRemoting

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

RemotingRemoting

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.


Thank You !!

Documents

Distributed Enterprise Software Technologies Diya Ajith Saira Kazmi Sumit Narayan {diya,saira,sumit}@engr.uconn.edu CSE 333 : Distributed Component Systems