Enterprise Component Comparison:

An Examination of J2EE, CORBA, and .NETFinal Report

Seth FreemanPhil Griffith

Frank Manni12/12/2005

Prof. Steve Demurjian

1. Overview

The goal of our project was to perform a comparison of J2EE, .NET, and CORBA

capabilities for component-based application design in four important areas of

computing. These areas include database connectivity, Web Services, security and

interoperability. In each of these areas, we evaluated how the J2EE and .NET platforms

compare with each other. Also, we identified the areas in which CORBA can be useful.

By comparing these platforms for these tasks, we have identified which one is the best to

use for implementation of a specific task.

All large distributed applications depend on databases to store application-related

data. We explored the facilities in J2EE, .NET and CORBA that support database

connectivity. We examined the different ways J2EE and .NET handle database updates,

insertions and queries. We also compared the performance of J2EE and .NET in updating

and querying a sample database.

Web Services allow applications to share functionality using communication

protocols such as HTTP, SOAP and XML. We examined the facilities in J2EE and .NET

to create and deploy a web service. We also explored the mechanism for each platform to

invoke the methods of a web service. Finally, we compared the ease of use of

implementing a web service in J2EE vs. .NET, as well as the performance of each.

CORBA provides similar functionality to Web Services in that it facilitates the

communication between multiple distributed applications. We examined the benefits of

utilizing web services vs. CORBA.

Security of distributed applications is paramount. Platforms used for developing

distributed applications must provide API's to enforce security. We will focus on the

security mechanisms performed directly by the application and application framework to

enable authentication, authorization and the encryption of data. J2EE, .NET and CORBA

each include services to do this. We explored these technologies in detail and determine

their strengths and weaknesses. We also compared the ease of use of incorporating

authentication and authorization in applications developed by J2EE, .NET and CORBA.

The interoperability of an application determines how well the application can

exchange information with other applications residing on heterogeneous platforms. This

is an important factor when designing distributed applications, because clients, servers,

databases, and other components often reside on different platforms. Thus there must be

tools that allow the application developer to translate data and information among

different platforms. We examined what support J2EE, .NET and CORBA provide to

facilitate this exchange. We also focused on remoting using J2EE and .NET and on

different types of interoperability that CORBA allows.

2. Detailed Discussion/Scope

In this project, we compared/contrasted the functionality of J2EE, .NET, and

CORBA for component-based application development. Below is a brief description of

each of the technologies, and their underlying components.

2.1 J2EE

J2EE (Java 2 Platform, Enterprise Edition) is a specification to enable application

developers to develop multi-tier enterprise-wide distributed applications. J2EE was

developed by Sun Microsystems in collaboration with leaders in the enterprise software

arena; it focuses on providing a software platform that promotes the development and

deployment of reusable software components.

J2EE is an extension of J2SE (Java Platform 2, Standard Edition). J2SE consists

of a robust set of API’s for application developers based on the Java programming

language. Applications developed in J2SE are compiled into Java byte code and run on

the Java Virtual Machine (JVM). The core Java API’s and the JVM together constitute

the Java Runtime Environment (JRE) which is required on any hardware platform which

wants to support J2SE. Figure 1 is a diagram of J2SE v1.5 which shows the relationship

between J2SE, JRE, JVM as well as the numerous packages available.

Figure 1. Java 2 Standard Edition version 1.5

J2EE extends the J2SE by adding support for Enterprise JavaBeans components,

Java Servlets, JavaServer Pages, XML technologies and Web Services. Enterprise Java

Beans are server-side components used to encapsulate the business logic of an

application. Java Servlets are Java programs used to extend the functionality of a server.

JavaServer Pages (JSP) are HTML documents embedded with Java code, used to

dynamically create HTML pages. XML technologies are used to allow the transfer of

data between various components in a distributed application, and are realized through

multiple packages including Java API for XML Processing (JAXP). Web Services are

supported through Java packages such as Java API for XML-based RPC (JAX-RPC).

This extra functionality provided in J2EE is what enables the development of enterprise-

wide applications.

2.2 .NET

.NET, developed by Microsoft in 2002, is a platform designed for application

developers to quickly develop Internet-based applications. .NET supports distributed

application development by including database support through ADO.NET, legacy

support through IIOP.NET, as well as support for Web Services and XML. The .NET

Framework is the infrastructure to support .NET technologies consists of the following

components, illustrated in Figure 2.

Figure 2. Framework for .NET

The .NET Architecture is comprised mostly of two components.  One is the .NET

Framework class library and the other is the Common Language Runtime (CLR).  The

CLR is responsible for providing the run time environment and services to the .NET

framework.  The CLR consists of many components including the garbage collector,

Common Language Runtime (CLR)

ASP.NET

.NET Framework class Library

Window Forms

Web forms XML Web Services

VB.NET C# VJ# VC++.NET ……..

Win 32

Class Loader, thread support, Type checker, Security engine, etc.  The compilers of

the .NET languages turn the source code into Microsoft Intermediate Language (MSIL),

which is used by the CLR to execute code.  This is beneficial as it makes developing

applications in .NET easier since the choice of language in the .NET framework wont

matter because they will all be interoperable.  This also leads to reusability of classes

among different languages.  So a class in one language can be used for another

application that is being coded in a different language.

The classes in this library support object oriented capabilities like inheritance,

polymorphism, etc.  The class library provides a common type system shared among all

of the languages.  This means that a String in one language for example, Visual

Basic.NET, is the same type as a String in C#.  So the class libraries are universal for

every language in the framework.   .NET is very XML oriented and several features make

use of its benefits.  As a result there exists XML Classes in the class library that are used

to provide support for communicating with relational and non-relational data sources

through XML format. At the top layer, application developers can develop either

Windows Forms for a user of the application to interact with, and/or develop Web Forms

and XML Web Services through the programming language ASP.NET.    Overall, the

.NET framework provides a consistent language independent model for developing all

types of applications, making it great environment for developers.

2.3 CORBA

CORBA (Common Object Request Broker Architecture) developed by Object

Management Group (OMG) is a middleware architecture used to facilitate

communication between heterogeneous applications over a network. Because of this, the

main focus of CORBA is interoperability.

CORBA allows for objects written in one programming language to be mapped to

objects in a different language. Of paramount importance to CORBA is the object. Any

reference to this object must use the object's interface [OMG]. In CORBA, an objects

interface is completely separate from its implementation, and when an object is

referenced through its interface, both the input and output parameters must be supplied.

This is done by defining an OMG IDL (Interface Definition Language) for each object to

be shared locally, or across the network. Clients can then send requests to a given object

through the ORB (Object Request Broker), which transparently sends/receives

requests/responses to distributed or local object implementations. Using the ORB for an

object requires a common protocol, but the overwhelming majority of CORBA

applications use a standard protocol [OMG].

Figure 3. The above figure shows how a client references an object [OMG]

The client references the IDL (interface) Stub, which arrives as a request to the

ORB. The ORB then accesses the IDL Skeleton to reference an object directly.

2.3.1 Remote Method Invocation of an Object

A key strength of CORBA is its use of remote method invocation. For every

instance of an object, CORBA keeps track of a reference to that instance. When a request

is made for an object, CORBA looks at the reference. If the reference is to a remote

object, the request is sent across the network. If the reference is to a local object, CORBA

performs a local invocation.

2.3.2 The ORB

Perhaps the most important part of CORBA is the ORB. Quite simply, the ORB

“takes care of all of the details involved in routing a request from client to object, and

routing the response to its destination” [ORB]. However, the ORB does much more than

that.

The ORB also:

Manages the Interface Repository, which is an OMG database containing all IDL definitions.

Allows clients to get interface definitions. Creates invocations for access during Dynamic Interface Invocation. Converts object references to the correct formats for a session Activate and deactivate objects on the server so that the client can access

them when they are needed.

Figure 4. The parts of the ORB. Figure from [CTUT]

3. Component Project Breakdown

3.1 Database Connectivity

In this section we compared the technologies in .NET, J2EE and CORBA to

facilitate database usage. We focused on the following areas:

Components – What are the underlying classes that enable database interoperability?

Connectivity -What is the process of establishing connections to various databases?

Interactions – How are updates to the database executed? How the results of queries are are obtained and processed?

Performance – What platform performs best on real-world data? 3.1.1 ADO .NET

ADO.NET is the new database technology of the .NET platform, and it builds on

the previous ADO technology. ADO is a language-neutral object model that is

the major advantage and selling point of Microsoft's Universal Data Access strategy. The

use of XML promotes interoperability, scalability, and better performance. The .Net

platform includes data providers for several types of databases including, Oracle, OLE

databases, and SQL Server. The underlying technique of ADO.NET is the use of data

sets in promoting a disconnected technique where the data will be represented in local

memory and take some of the load of the database server.

ADO.NET can perform the following essential tasks for database connectivity.

Establish a connection using the Connection object and perform queries or updates

(DELETE, INSERT, etc.) using the Command object. It also allows for error and

exception handling using Error and Exception classes. These four tasks use the classes

mentioned above and additionally the use several other key classes, which makes

database connectivity in .NET easy and a little different than the conventional techniques.

The DataSet object contains either a pre-selected subset of the remote database or

a sub set defined by the results of a query. This structure is best described as a local

memory copy of the database. The Dataset allows for a disconnected operation to occur

meaning there is no continuous connection to the database. After retrieving a DataSet

you have a local view of the database eliminating the need of an open connection hence

reducing the load on the database server. The DataSet contains not only the data but the

structure of the database including tables, rows, and relationships. The DataSet works in

a three step process: step 1 connects to the database, step 2 retrieves the results from a

query, and step 3 closes the connection. Once this is complete all processing can be done

on the local machine. This process is done through XML as the DataSet is created from a

XML file. In Step 2 the ADO.NET interface stores the data into an XML file. Since the

DataSet is processed in memory the information may not necessarily reflect what is

stored in the database. All operations (update, delete insert, etc.) are done in memory at

the client. Meaning you can change the structure of a dataset which maybe different than

the original database structure. Then when appropriate, the changes made in memory can

be reflected in the database by using XML. The dataset can be converted to an XML file

then the XML file is sent to the database to enforce any changes. As a result this

disconnected technique minimizes opens connections to the database, reduces roundtrips

to a database and allows the database server to handle other requests. Although the

disconnected technique does have its disadvantages of reading and locking rows one at a

time. The DataReader reads one row at a time and no one else can access it until it done,

so multiple users for one database could pose some problems.

The interface between a data source and the application in ADO.NET is the

DataAdapter class. The DataAdapter is responsible for filling in the Data Set object with

data and schema information. The DataAdapter works in conjunction with the

DataReader class to fill the DataSet object. The DataReader reads in one row at a time

and the reconnects and grabs the subsequent rows. While a DataReader is “open” no

other objects can read or write to the data source until the reader is closed.

The DataSet is broken down into two subcomponents the DataTable class and a

collection of relationships for the corresponding tables. The DataTable component

includes all row column, and constraint information about the tables the data belong to.

Each row can be modeled with the DataRow class. This class keeps track of state of any

row. The state is simply whether or not the data had been modified or unchanged. This

structure can be viewed as a temporary relational database. The structure is a partition of

the actual database in memory. You can also perform any operations on a dataset that

you could do on an actual database. Out side of normal operations like updating and

delete. You can insert new rows and even tables to the Dataset.

3.1.1.1 XML benefits

The .NET framework has made database an independent issue for developers by

providing integration of XML with ADO.NET. Regardless of the database used by the

developers because the code for querying the database is the same for all applications.

ADO.NET uses XML for its main method of data exchange, which leads to

interoperability with applications that use XML. Most databases now are XML

compatible so the difference between and Oracle and OLE database are irrelevant. Since

both providers can use XML, the format of sending data back and forth will be universal

so the choice of database will not be a problem when using .NET applications. As a

result this also leads to maintainability. Since ADO.NET uses XML any architecture

changes can be handled seamlessly. If the number of tiers changes in the architecture the

application will not be affected since the all communicate via XML the data exchange

will be no different. As seen from before ADO.NET offers ease of programmability.

The classes provided easily allow for connectivity and SQL statement execution and

processing.

The disconnected technique mentioned in the previous section is obvious

performance enhancement over previous technologies that use COM marshalling. Also

with the use of XML, ADO.NET doesn’t have to deal with type conversion of data,

which is a performance enhancement. The disconnected technique also makes the

database application more scalable due to the reduction of open connections, which will

lead to better resource usage and a reduced load on the server side.

3.1.1.2 ODBC.NET

While OLE DB and SQL Server are two popular types of databases, Microsoft

wanted to support more than just these two. OLE DB is very similar to ODBC in

supporting several types of database connectivity. The ODBC.NET data provider

originally was an add-on for the .NET framework but in the more recent versions it

comes as a standard package. All of the providers can be found under System.Data and

next is the ODBC, OLEDB, and SQLClient classes where you choose the provider you

wish to use. All of the providers work the same as providing access to ODBC drivers is

identical to providing access to OLEDB drivers for the OLEDB.NET. One advantage of

the ADO.NET data providers is that all of them describe the same class structure. The

class structure contains the classes Connection, Command, DataAdapter, DataReader,

Error, etc. Using these classes in a manner mentioned in the previous sections is no

different than using them for one provider or the other. The only things you need to

change are the names of classes and the format of the connection string. For Example the

connection class in ODBC.NET is ODBCConnection compared to OLEDBConnection

for the OLE data provider and the same holds for SQL Server Providers. The

ODBC .NET Data Provider is intended to work with all compliant drivers but it has only

been tested with the following: SQL ODBC Driver, ODBC Driver for Oracle, and Jet

ODBC Driver.

3.1.2 JDBC

Java Database Connectivity (JDBC) is an API that allows Java programs to work

with databases. JDBC provides tools for application developers to allow clients to

connect to databases, and then send commands to the database in the SQL language.

JDBC contains a set of database-neutral classes and interfaces. These classes

communicate with the database-specific code, referred to as a driver, which is developed

by the database vendor or some third party. JDBC is contained in the java.sql package.

3.1.2.1 Connecting to Databases

The first step in working with databases is to open a connection to the database.

Opening a connection is done through the DriverManager class, which ‘manages’ the

drivers for different databases, and chooses the specific driver for the given database the

client wishes to connect to. JDBC supports four categories of drivers that can be used to

communicate with databases [JDBC]. These four types of drivers are:

JDBC-ODBC bridge with ODBC driver Native-API partly-Java driver JDBC-Net pure Java driver Native-protocol pure Java driver

JDBC-ODBC bridge enables JDBC access to a database by mapping JDBC to

ODBC and then using the ODBC driver. ODBC (Open Database Connectivity),

developed by Microsoft, is a popular API for accessing databases, written in C. JDBC-

ODBC bridge is typically only used when then no JDBC driver exists.

Native-API partly-Java driver maps JDBC to some native API for a database. For

example, JDBC calls may be mapped to an API for Oracle, Sybase, or some other

DBMS. This solution, like the JDBC-ODBC bridge requires some binary code be loaded

on each client machine.

JDBC-Net pure Java driver converts JDBC calls to a DBMS-independent net

protocol, which is sent to a middleware server that translates the net protocol into a

DMBS-specific protocol. The middleware server typically resides on a different machine.

This solution allows all-Java clients to connect to many different databases, yet requires

the use of an additional server.

Native-protocol pure Java driver, referred to as a thin driver, translates JDBC

directly into the database’s native protocol. This driver is completely written in Java, and

allows the client application to directly call the DBMS server. There is no platform-

specific code necessary, so this driver can be used on any platform with a Java virtual

machine.

In JDBC 2.0 DataSources were introduced to allow programmers a more flexible

way to create and use database connections [J2EE INTRO]. A DataSource is an object

that implements the DataSource interface, and returns a Connection object to the client.

Prior to using a DataSource object, some server must create a DataSource object and bind

it to a name in the directory service. Client applications then access the directory service

through Java Naming and Directory Interface (JNDI), an API providing a collection of

methods to interact with directory services. Through DataSource objects, the client does

not need to know anything about the database, just the name that is associated with it.

Furthermore, changes can be made to the database and/or drivers without any knowledge

of the client application.

3.1.2.2 Statements

The Statement class is used to create, update, retrieve, and delete data from a

database. Statement objects are created using the createStatement( ) method of the

Connection class. Statement objects contain methods which pass SQL commands to the

database, and return the results of the SQL commands. SQL commands such as create,

insert, update, and delete can be passed as arguments to the executeUpdate( ) method of

Statement objects. SQL commands to query the database are passed as arguments to the

executeQuery( ) method of Statement objects.

JDBC also allows for the specification of multiple SQL commands to be executed

together as a batch. The Statement object contains the method addBatch( ) which allows

the programmer to group multiple SQL commands together. The method executeBatch( )

sends the entire batch of SQL commands to the database at once, and returns an array of

integers corresponding to the result of the operation.

3.1.2.3 ResultSets

ResultSet objects are the results of an SQL query sent through an executeQuery()

method of the Statement object. ResultSet objects contain methods to navigate through

the rows in the ResultSet, as well as extract data from columns for a given row in the

ResultSet. There are different types of ResultSet objects, and they can be classified

based on how the allow the programmer to scroll through them, what happens when they

are updated, and how long the ResultSet stays open.

3.1.2.3.1 Scrollable ResultSet

Since query results often contain multiple records, there must be a mechanism to

move from one record to another. There are two types of ResultSet objects,

NonScrollable and Scrollable, which differ in how they allow the programmer to do this.

Nonscrollable ResultSet objects only allow the client to move from the first row

to the last row of the ResultSet object. The next( ) method of the ResultSet object allows

the client to move to the next row.

Scrollable ResultSet objects allow the programmer to move forward and

backwards through the results of the query, as well as skip to the beginning and end.

Methods available to the Scrollable ResultSet object include next( ), previous( ),

afterLast( ) and beforeFirst( ).

3.1.2.3.2 Updateable ResultSet

Prior to JDBC 2.0, ResultSet objects only contained functionality to move from

one record to the next and read the data in the columns for each record. JDBC 2.0

introduced the ability to update the data in the database directly through the ResultSet

object. Updateable ResultSet objects contain methods to update columns for a given

record, insert new records, and delete records in the ResultSet object.

3.1.2.3.3 Holdable ResultSet

Prior to JDBC 3.0, ResultSet objects were typically released as soon as another

Statement object was executed. JDBC 3.0 added the functionality that a ResultSet object

could remain open when a new SQL command is executed by the Statement object.

These ResultSet objects are referred to as Holdable.

3.1.3 CORBA

CORBA doesn’t use databases the way that other programming languages do. In

a way, they are somewhat irrelevant to CORBA. This is not to say that CORBA

applications do not use databases, because they can and do. However, they are not

integral to CORBA.

Figure 5. The above diagram demonstrates how CORBA might use a database

In Figure 5, one can see how CORBA might use a database. The implementation

of an Object might call a database with some information. Using that information, it

would interact with the database and might send that information back to the client.

However, as the Object can be done in many different programming languages, the way

that language interacts with the database is the central concern, not that of CORBA.

3.2 Security

In this section we compared the technologies in .NET, J2EE and CORBA to

enable security measures. We focused on the following areas:

Authentication – What capabilities exist within an application to determine an entity’s identity?

Authorization – What capabilities exist within an application to restrict/grant resources based on the requesting entity’s identification?

Encryption - What built-in techniques are there to encrypt data? Development – Which of these utilities that enable authentication and

authorization are easier for the application developer to use?

3.2.1 .NET

The .NET framework provides solutions for implementing authentication,

authorization, and cryptographic schemes. The two main components mentioned above,

CLR and the class libraries help aid in these solutions. The CLR prevents unexpected

behavior and limits code execution. Using just in time compilation, the native machine

code can make use of the CLR’s security engine to process code to enforce some security

measures. The class library contains classes concerning cryptographic protocols and

authentication / authorization mechanisms, etc. These 2 components are the driving force

behind Microsoft’s managed code idea that is demonstrated in the .NET Framework.

The framework encompasses several areas of security. These include evidence

based security, verification process, Role-based security, code access security, and

cryptography. Evidence based security, the verification process, and code access

security all deal with ensuring proper behavior of machine code. This is the idea of

managed code, which will not be the focus of this paper. The paper will focus more on

encryption (Cryptography), authentication, and authorization (Role-based security)

aspects of the framework.

The .NET framework implements role based access with its Principal and Identity

Model. The Principal is simply the user of the application who is executing the code.

Using the authentication measures mentioned below the principal’s Identity is verified.

Then after verification the principal can be assigned roles. So each application will have

its own principal object that contains its identity and list of roles. The roles will be most

likely listed in a database that will be mapped to different users.

3.2.1.1 Authentication

The identity and principal objects are essentially an abstraction of a user and their

roles. The identity consists of three properties Name, IsAuthenticated, and Type. There

are four types of identity classes: passport, forms, windows, and generic. The first three

are fairly well defined but the generic version is designed to be custom. The principal

object is the holder of roles for the user. The principal object uses the Principal interface

which works in conjunction with the Identity object. There are only 2 classes for

Principal, Windows and Generic. The windows principal works with the windows

identity, while the generic one works with the others.

.NET supports several different methods for authentication to determine

credentials. Authentication is the first step for Role based security. Once ones identity is

verified authorization procedures can be taken into account to determine the roles for the

user. Authentication is classified under three types form based, passport, and window-

based authentication.

Form based authentication is using web based (HTML) forms to verify

unauthenticated requests which will then get redirected back to the server. The

application will use a database or exchange server to verify credentials. Specifically in

ASP.NET authentication is performed using cookies that contain the identity information.

This way any subsequent authentication can be handled with the cookie instead of

manual verification all the time.

Passport authentication is a Microsoft specific and designed service to provide

authentication. This is similar to the form-based authentication but Microsoft passports

use a centralized server to check credential for particular sites. Another technology is

Internet Information Server (IIS), which has built in mechanisms for authentication.

These mechanisms include Kerberos, NTML, and X509 certificates which are all done

through the HTTP protocol. These are third party products that are well known and

conform to standards, making them universal.

The windows based authentication is essentially using a central server like IIS or

something similar to the passport server to verify ones credentials. Then using the .NET

languages ASP.NET, C# or Visual Basic the next step is to construct Identity and

Principal objects. Anytime you construct a Principal and Identity pair you must set the

defined Principal as the thread’s principal. This way when the code is executed the

correct Principal will be used for authentication and authorization. This is a simple one

line command in the following syntax:

Thread.CurrentPrincipal= MyPrincipal;

where MyPrincipal is a user defined Principal Object with a set of roles.

As one can see these configurations are custom and can vary on a per application

basis. The Identity will be customizable for each different user and different principal

objects can be defined representation a different set of roles. Additionally the

authentication mechanism for verification can be selected by the user with a wide variety

of choices mentioned above.

3.2.1.2 Authorization

Authorization is performed using two ways, security demands or through the

Principal Object. A security demand limits access by restricting a user list or a specific

role list. The security demand can be placed on an entire class or a subset of methods

with in the class. Here is an example of placing a demand on an entire class Animal:

Imports System.Security.Permissions

<PermissionSetAttribute(SecurityAction.InheritanceDemand, _Name := "FullTrust")> _Public Class Animal' ...End Class

Here is an example of placing a demand on a method DoSomething() in class Animal:

Imports System.Security.Permissions

Public Class Animal

<PermissionSetAttribute(SecurityAction.InheritanceDemand, _Name := "FullTrust")> _ Public Overridable Sub DoSomething()   ' ... End Sub

End Class

Source: http://www.vbip.com/books/1861007477/chapter_7477_03.asp

The security demand for both examples is full trust. Meaning only users that have

full trust are able to use this class and partial trust users will not be able to use or extend

this class. It is essentially the same syntax to place a demand on a class or a method. It is

preferred usually to place a demand on entire class than specific methods but it is up to

the software developer. The security demand placed on a class is also inherited by any

other classes that extend this class.

Using the PrincipalPermission class provided in the .NET class library does this.

Here is an example:

//you must be in the Administrators or Users group to access any //method of this class [PrincipalPermission (SecurityAction.Demand, Role="Administrator")] [PrincipalPermission (SecurityAction.Demand, Role="User")] public class protect { //additionally, you must be an the local computer Administrator to access //the protectedMethod method [PrincipalPermission (SecurityAction.Demand, Name="mycomputer\Administrator")] public void protectedMethod() { Debug.WriteLine ("accessed"); }other methods }

The principal object is simple to use as well, the application just has to call the

IsInRole() method of the IPrincipal interface associated with the principal object. Notice

you have to use the CurrentPrinicpal Property of the thread and set it to the principal that

you are defining. This is because when a method is executed the thread running the code

will need to have the permission set to the principal you set to achieve the desired results.

Here is a code example:

[PrincipalPermission (SecurityAction.Demand , Role="Administrator")] public void protectedmethod() { WindowsPrincipal wp = Thread.CurrentPrincipal as WindowsPrincipal; if (wp!=null)

if(wp.IsInRole("Administrator")==true) Debug.WriteLine ("Access Granted"); else throw new Exception ("Access Denied");

else throw new Exception ("Access Denied"); }Source http://www.informit.com/articles/article.asp?p=102217&seqNum=3

Using either of these 2 ways you can place limitation on methods or classes using the

Principal object or Principal Permissions Object. You can also use security demands to

place restrictions on the entire class or specific methods. Both methods are essentially

the same, they differ in syntax and functionality. While they work a little different they

accomplish the same task of authorizing users.

3.2.1.3 Encryption

Encryption is essentially built in through the available class libraries. .NET uses

the Windows CryptoAPI to enable developers to make use of cryptography. These

include algorithms, hashing, and signatures. The algorithms supported are public key

RSA and DSA, and symmetric DES and Triple DES. These algorithms can be used with

such other provided services to help fortify other built in security measures. For

example using the cookie authentication mentioned above with encryption algorithms can

even enhance the security of web applications. This is all accomplished using streamed

data. Any streamed object (file stream) can be sent to an encryption object, which in turn

can be streamed elsewhere to a network socket for example. The new direction is

encryption of XML documents. The new XML digital signature (XMLDSIG)

specification will allow for XML objects to be signed and encrypted for secure

transportation. The .NET framework can handle several cryptographic solutions as seen

above but its tie to the Windows Crypto API hurts its interoperability. Enterprise systems

will comprise of heterogeneous components, which could be a cause for concern. The

other concern is the protocols and algorithms for providing security are not extremely

difficult to reverse engineer. This could have devastating future implications.

3.2.2 J2EE

Historically, security of Java applications was code-based. This is due to the fact

that initial java programs were distributed across the Internet, i.e. applets, so measures

had to be taken to ensure java code could not do anything malicious. To this end

mechanisms such as code-signing, to verify the identity of the code developer and the

integrity of the code, and bytecode verification, to ensure the code adheres to rules of the

Java language, are utilized.

As the uses of Java migrated to the development of multi-tiered distributed

application, the need to secure the resources of an application from users of the

application created the need for user authentication and user authorization mechanisms.

Specifically, role-based access control, whereby resources are accessed based on a users

role within the application became necessary.

We will examine ways to achieve authentication and authorization declaratively

and programmatically. Declarative security is enforced in J2EE through application

configuration files, specifying resource constraints/permissions for users of an

application. Programmatic security refers to security checks explicitly called within the

application code. We will examine programmatic security as realized by the Java

Authentication and Authorization Services (JAAS) API. Finally, we will examine the

cryptography utilities provided through the Java Cryptography Architecture (JCA), Java

Cryptography Extensions (JCE) and Java Secure Sockets Extensions (JSSE) APIs.

3.2.2.1 J2EE Application Configuration

The J2EE specification is used to develop multi-tiered distributed applications.

These applications are stored within an Enterprise Archive (EAR) files. These files

consists of EJB modules stored in Java Archive (JAR) files, web modules stored in Web

Archive (WAR) files, application client modules stored in JAR files and deployment

descriptor files [J2EE SEC]. Deployment descriptor files are XML files specifying the

contents of the archive, deployment instructions and security settings. Each archive file

(EAR, WAR, JAR) contain their own deployment descriptor. Figure 6 below shows an

example architecture.

Figure 6. J2EE Application Configuration3.2.2.2 Authentication

Client SideClient Side Middle TierMiddle Tier Enterprise Information ServerEnterprise Information Server

Web Application Servers:Web Application Servers:JSP, Servlets, HTML, XMLJSP, Servlets, HTML, XML

EJB Server, JNDI, EJB Server, JNDI, JMS, JavaMailJMS, JavaMail

RDBMS, ERP,RDBMS, ERP,Legacy AppsLegacy Apps

Authentication in J2EE is achieved by verifying the identity of a user, then

creating a Subject object containing a set of Principals and Credentials. Principals

correspond to the various identities of a user, while Credentials include user certificates

or some other system-defined properties. Once a user has an associated Subject object,

the corresponding set of Principals and/or Credentials will be used to determine access to

resources.

3.2.2.2.1 Declarative Authentication

Authentication in J2EE can be done in many ways. Typically, the authentication

mechanism is based on the authentication policy of the resource the Principal is

requesting [J2EE SEC]. We will discuss three authentication mechanisms, each which

can be specified within the WAR deployment descriptor. These mechanisms are:

HTTP authentication Form-based authentication Certificate-based authentication

With HTTP authentication, users must provide userid/password pair, typically as

part of HTTP header. When users request a protected resource without this header, the

Web Server will return an Unauthorized Client Error (401) and a WWW_Authenticate

HTTP header, prompting the Web Browser to pop up a dialog window. The user must

enter the userid/password pair, which the Web Server can use to perform authentication.

Form-Based Authentication obtains userid/password information from HTML

forms. When a user requests a protected resource, the Web Server redirects the client to

an HTML form. If authentication fails, user is redirected to error page. In both Form-

Based and HTTP authentication, cookies are often used to retain state information,

similar to as in .NET.

Lastly, Certificate-Based Authentication verifies the authenticity of a user, typi-

cally based on an X.509 client certificate the user passes to the Web Server. In this

model, the Web Server must be configured to perform mutual authentication over Secure

Sockets Layer (SSL). Once obtaining the client certificate, the Web Server can map the

Certificate to a Principal that has been assigned a security role. This also mirrors the

Passport security scheme in .NET.

3.2.2.2.2 Programmatic Authentication

Programmatic Authentication entails the explicit calls to authentication

mechanisms/procedures from the application code. This can be done in many ways,

through interactions with databases, directory servers, etc. We will explore the Java

Authentication and Authorization System (JAAS) API, designed to provide a flexible and

scalable means to authenticate a user [JAAS].

Through JAAS, an application can authenticate a user by creating a LoginContext

object and passing a CallBackHandler [JAAS]. The LoginContext object reads a

configuration file that contains a list of LoginModules. When the

LoginContext login( ) method is called, the login( ) methods of each LoginModule is then

called. Each LoginModule uniquely authenticates the user, based on its underlying

technology. For example, one LoginModule could query a database with user information,

another could communicate with a directory server, and another could check the user

registry on the Operating System. Figure 7 shows a diagram illustrating these

interactions.

The overall authentication success or failure depends on the outcome of each

LoginModules authentication [JAAS]. Each LoginModule is flagged in the configuration

file as Required or Optional. Specifically, the overall authentication is successful, only if

all Required LoginModules succeed. Once authentication is successful, the LoginContext

object calls the getSubject( ) method to return the Subject object. Subsequently, the

getPrincipals( ) method can be called to obtain the set of Principals associated with the

Subject.

Figure 7. Authentication through JAAS

3.2.2.3 Authorization

Once a user has been authenticated, the J2EE application has determined the

Subject object corresponding to the given request, as well as the set of Principals and

Credentials. To perform authorization, the J2EE application must check the mapping

between the Principal(s) and the resource/method the user is requesting.

3.2.2.3.1 Declarative Authorization

To declaratively enforce authorization, deployers of a J2EE application must

specify within the application’s deployment descriptors the following: (i) the roles used

within the application, (ii) mapping of roles to methods within an EJB or Servlet, and (iii)

Application

LoginContext

Biometric AuthenticationKerberos Authentication

NT AuthenticationLDAP ServerRDBMS

JNDILoginModule

RdbmsLoginModule

LoginModules

mapping of principals to roles. Below we discuss each of these steps.

The Roles within an application can be specified in the deployment descriptor of an EAR

within security-role elements. Figure 8 below, shows how the Teller role could be

defined.

<assembly-descriptor><security-role>

<description>This role is for tellers

</description><role-name>Teller</role-name>

</security-role><assembly-descriptor>

Figure 8. Teller Role defined within deployment descriptor of EAR

Once Roles have been defined, application deployers can map roles to methods

within a Web Module. Within the deployment descriptor of a WAR, the security-

constraint element specifies constraints on specific resources. For example, In Figure 9

below, the GET method of the Servlet associated with the relative URI /finance/account

is only allowed to be called by Principals with the Teller Role.

<security-constraint><web-resource-collection>

<web-resource-name> Account servlet protected area

</web-resource-name><url-pattern>/finance/account</url-pattern><http-method>GET</http-method>

</web-resource-collection><auth-constraint>

<description>Teller can access the URIs</description><role-name>Teller</role-name>

</auth-constraint></security-constraint>

Figure 9. Mapping between Roles and the Servlet Methods in the deployment descriptor of WAR

Finally, the application deployer must map the Roles to Principals, or identities of

the users of the application. This step is dependent upon the underlying architecture uti-

lized by each J2EE application server. Typically, user/role mappings are stored in a data-

base, or accessed through some directory server [J2EE SEC].

3.2.2.3.2 Programmatic Authorization

Through the JAAS API, authorization is achieved through mapping a Principal to

a current thread of execution and then calling a method that executes some privileged

code. To associate a Principal with the current thread, the application calls the doAs( ) or

doAsPriveleged( ) methods of a static Subject object. The doAs( ) and doAsPriveleged( )

methods take as arguments (i) a Subject object representing the user requesting access

(obtained through authentication) , and (ii) an object that implements the

PrivelegedAction or PrivelegedExceptionAction interfaces [J2EE SEC].

The actual authorization check is done when the run( ) method of the object

implementing the PrivelegedAction interface is called. At this time, the Java Security

Manager searches the java security policy files for entries corresponding to the class.

Specifically, there should exist a grant entry that describes codeSources and/or Principals

authorized to perform Privileged operations [J2EE SEC].

3.2.2.4 Encryption

J2EE extends J2SE to incorporate a rich collection of cryptographic utilities

through the Java Cryptography Architecture (JCA) and Java Cryptography Extensions

(JCE) APIs, and support for SSL through Java Secure Sockets Extension (JSSE). We will

examine these in the following sections.

3.2.2.4.1. Java Cryptography Architecture and Java Cryptography Extensions

Java Cryptography Architecture (JCA) and Java Cryptography Extensions (JCE)

provide extremely robust set of core cryptography classes for J2EE application

developers. JCA contains core security classes providing cryptography and security

services related to access control and cryptography. JCE extends JCA to provide classes

supporting message digests, digital signatures, certificate management, encryption, key

exchange and message authentication codes. Together, JCA and JCE provide a complete

platform-independent cryptography API [JCA SPEC].

The design goal of JCA was to support implementation independence,

implementation interoperability, algorithm independence, and algorithm extensibility

[JCA SPEC]. To this end, the JCA makes use of Cryptographic Service Providers (CSP),

or packages or sets of packages that provide concrete implementations of a subset of

cryptographic services supported by Java security API. Java programs may get an

implementation for one service, for example public/private key pair generation from one

provider, implementation of message digest from another provider, and implementation

of digital signature from another provider. Through JCA and JCE J2EE applications can

exhibit extremely customizable and flexible cryptographical schemes.

3.2.2.4.2. Java Secure Sockets Extension

Java Secure Socket Extension (JSSE) is a set of Java packages and APIs that

enable the use of SSL from within J2EE applications [JAVA SEC]. Using JSSE,

application developers can ensure secure transmission of data between clients and

servers. JSSE provides functionality for data encryption, server authenticity, message

integrity, and client authentication. JSSE is similar to JCA and JCE, in that it consists of

an API and corresponding implementation of the API that can be interchanged with an

implementation from a different vendor.

3.2.3 CORBA

CORBA, being a distributed system, is more vulnerable to security breaches than

other software applications. This is because there are more areas of a system that are

vulnerable to attacks. The CORBA Security Service adds security to CORBA to protect

many areas against these attacks [SSS]. However, much of CORBA’s security is not

implicitly defined in CORBA itself. CORBA’s Security Service gives administrators and

developers specifications on what they must do to make CORBA secure.

CSS provides the following security functionalities: authentication, authorization,

auditing, secure communication, non-repudiation, and administration [OMGS].

However, for a CORBA application to be considered secure, when the client makes a

request to the ORB and when the ORB sends a request to the target object, those areas are

not considered. However, the ORB must have a security implementation on it holding a

security policy.

Figure 10. A secure CORBA system

3.2.3.1 Authorization

To access objects in the system, CORBA defines a principal. A principal is

system entity or user that has the rights to access another object in the system. A principal

that starts an action is called an initiating principal. The principal must have attributes to

determine what it can and cannot access. These privileges are defined on the system and

may be constrained within certain times.

A principal then has certain credentials. Credentials contain information about a

principal and what that principal has access to and when.

Figure 11. Security Credentials stored on a system. [SSS]

3.2.3.2 Authentication

To invoke an object, a principal must authenticate itself to the system. To do this,

it must establish its credentials, and it does so using a Principal_Authenticator object.

This object supplies the principal with default credentials, and it checks the various

information that the principal supplies, i.e. username, password, and access requested. It

can then return either success, failure, continue, or expired. Based on which one of these

that is returned, the principal may or may not gain access to the system.

The authenticate method that is part of the Principal_Authenticate object is not

explicitly defined by CORBA. This allows users to define their own authentication

methods. However, the CORBA standard recommends that this authentication be done

before a principal access any objects.

3.2.3.3 Encryption

In CORBA, one key vulnerable area is during object requests and responses. To

ensure that the message transmitted is not modified or read in transit, CORBA can define

a protected part of a message, and any change to this area will cause the target object to

reject the message.

Protection can also be added below the ORB message layer in CORBA. Systems

can choose to integrate Secure Socket Layer protection. If this is done, CORBA will not

use its own security methods in addition to this one.

CORBA allows for various encryption techniques to be added to its message

layer, but does not define one automatically. It provides a method for its users to do so,

but does not do so itself.

3.2.3.4 Security Service Protocol (SECP)

The OMG is replacing the CORBA Security Service with the Security Service

Protocol. This protocol is still a work in progress, and there is an adopted submission of

the Protocol, but a specification has not yet been released [OMGS]. This protocol is

being by Syracuse University and Adiron, LLC for a protocol for clients and servers to

protect communication in CORBA.

CORBA Orbs communicate by using the GIOP (General Inter-ORB Protocol).

This protocol defines the format of the messages that are passed over the ORB to and

from the client and object. When GIOP runs over TCP/IP it is a part of IIOP. SECP will

be another layer below the GIOP that adds security to message transportation [SECP].

Figure 12. How SECP fits into the CORBA security environment. [SECP]

SECP has three parts: Circuit Establishment, Context Establishment, and Message

Transport. Circuit Establishment creates a secure, bi-directional connection between a

client and target. Context Establishment allows both a client and target to set up security

contexts, and based off the specified security context of the client and the target, certain

behaviors may take place. Message Transport is the final phase of the SECP, and this

phase securely transports the messages and then destroys the contexts [SECP].

3.3 Web Services

In this section we will compare the technologies in .NET, J2EE and CORBA to

support Web Services. We are focusing on the following areas:

Functionality – How are Web Services supported? Development – How easy is it to develop a Web Service on each platform? Performance – Which client on a given platform performs better for a given Web

Service? For the same Web Service created on (two) different platforms, which performs better?

3.3.1 .NET

Similar to the database functionality Microsoft makes use of XML in its .NET

framework for implementing web services. The main reason is that with XML the client

does not need to know the language the web services are implemented in, which

promotes interoperability. Since all the communication is done via XML there is no

difference between a Java component, a C++ component, or a COBOL component that

does a particular service. The client just needs to know the location and available

methods of the web service in order to use it. The process for using web services is a

four-step process. First the client must contact a Universal Description Discovery and

Integration (UDDI) registry (for example http://uddi.microsoft.com), which contains

information about published web services. Essentially this is a directory of known web

services available so the client is able to know what is available. It is possible to deploy a

web service without registering it in UDDI. But if you want a large number of people to

make use of a service, you need UDDI so that clients can find it. An entry within a

UDDI directory is simply an XML file containing information about the host and the

service offered. An entry breaks down into three components. The first component

describes the company offering the service: name address, etc. The second component

includes categories of the web service. The third component describes the actual interface

to the service with enough information to create a client application to use the web

service. Services are defined through a document known as a Type Model. Generally

the Type Model contains a Web Services Description Language (WSDL) file that

describes a SOAP interface to the XML Web service. After contacting this server the

client will receive the URL of the Web Service. After receiving the URL the client can

contact the Web Service server and receive a discovery document that will enable the

client to locate the service description in a WSDL file on the server. A WSDL file is an

XML document that describes the SOAP messages and their format for the web service.

WSDL in essence is the equivalent to IDL for CORBA. The syntax of a WSDL file is

standard and programming language independent making it appropriate for describing

XML Web services that can be accessed from multiple platforms. WSDL also defines

the location of the service and what communications protocol is used to talk to the

service. The WSDL file contains everything necessary to write a client program to make

use of an XML Web service. THE UDDI and discovery document just help locate the

WSDL files. Microsoft .NET is able to read a WSDL file and generate the code to

communicate with an XML Web service.

Once a client knows what methods they can use and how to use them the client

can actually begin to use the web service. First the client will call an available method of

the Web Service by sending an XML file to the server with the SOAP message with the

appropriate arguments. SOAP is a simple and flexible protocol that defines the XML

format for web service messages. The server then processes the SOAP message and calls

the method with the given arguments on the server. The server then takes the output of

the method call and sends it back in a SOAP message where the client can process the

results.

Figure 13. Web Service infrastructure 1. Directory 2. Discovery 3. Description 4. Format

3.3.1.1 .NET Support

After seeing how web services actually work .NET is able to allow users to create,

deploy, and use web services. Microsoft.NET has a built in ASP.NET Web Service

Project type for creating web services. After creating a project .NET creates all the

necessary and optional files you would need such as the Web configuration file

ClientClient

Web Web ServiceService

Directory Directory ServiceService

11

22

3.3.

4. 4.

ClientClientClientClient

Web Web ServiceServiceWeb Web

ServiceService

Directory Directory ServiceService

11

22

3.3.

4. 4.

(Web.config), the discovery file (ProjectName.vsdisco), the code-behind class file

(ProjectName.asmx.cs or.vb), etc. The configuration file is optional to have custom

configurations for the Web Service. The Discovery file was mentioned above and is used

in discovering the web service. The code behind file is the functional code of the web

service methods that are implemented in C# or Visual Basic. Note there are more files

generated these are just a few of them but .NET generates them all at project start up.

After creating a project and coding the methods for the web services you have to

deploy the Web service. To deploy your web services simply copy the files to the server

and follow the directory structure you want. Typically you will store all of the files under

a subdirectory of the root folder. Underneath this folder make a bin folder and include

the .DLL file of the code you designed. Microsoft .NET has an Internet Services

Management tool if you want to adjust any settings; otherwise the service is ready to be

used by clients. Note in addition to regular .disco files that are generated .NET also

produces .vsdisco files. These files are for dynamic discovery meaning a client can

discover more than just one web service on a server. They can go through all of the web

services on a host and locate all available web services.

Once a client has discovered a web service that they want to use they are able to

make use of it. To use a web service the client must create a proxy class. This class can

be generated by .NET at the command prompt using the WSDL tool. Using the location

of the WSDL file .NET can automatically generate the proxy class source code in the

language it was designed in or even another .NET language if one desires. The client

application can use this class by instantiating an object with the new operator. Then

with this object one can use the exposed methods of the web service. Any method calls

on the proxy class object will be converted to SOAP request messages that will be sent to

the server. The proxy class will also take response messages and convert them to return

values of the method call for the client application to use. The proxy class object is the

interface of the client application to the XML web service on the server side. No matter

what the language or platform you are using the XML in the WSDL file will define the

class structure. So both J2EE and .NET environments are able parse the WSDL file and

construct the appropriate syntax for the class. Also note that to send data across the

network data will need to be serialized. Microsoft .NET offers two types of serialization

XML and binary. Binary converts the object and its members to a stream of bytes while

XML serialization requires the fields to be of a specific format defined in an XML

schema definition document (XSD). There is a XSD tool in .NET that can be run at the

command prompt to perform this serialization. The data will also need to be deserialized

as well upon being received. Microsoft really focused on Web Services in their design of

the .NET architecture. As a result it can handle all the necessary operations like Creating,

Deploying, Discovery, and Consuming.

Microsoft included a WSDL tool in .NET that allows for easy import of a WSDL

file to generate source code in VB or C#. The goal in mind is to generate the code to be

included on the application project you are developing. The WSDL tool is a command

line tool that takes in the WSDL file and optional but very useful parameters. These

parameters specify the output class, namespace, and language. These are only some of

the possibilities there are other options as well but these three are the most important.

After generating the cs or vb file you can simply copy the file into the project source

directory. Then the project will have access to the web service methods. The next step is

to instantiate an object. Next you can use the service methods as you would use any

normal object’s methods. This tool provides a way to use existing web services in your

application by simply importing the XML WSDL file.

3.3.2 J2EE

J2EE provides numerous tools enabling application developers to leverage the

interoperability benefits associated with Web Services. Similar to .NET, J2EE includes

tools to support and realize the directory, discovery, description and format steps for a

client to use a Web Service.

J2EE provides support for the publishing and discovery of Web Services through

the Java API for XML Registries (JAXR) API. JAXR is a single general purpose API for

interoperating with multiple registry types, including the Electronic Business using XML

(ebXML) Registry and Repository standard, and registries conforming to the UDDI

specification [JAX-RPC]. The JAXR architecture consists of JAXR providers, and JAXR

clients. JAXR Providers are actual implementation of the JAXR API that provides access

to a specific type of registry. JAXR Clients are programs that connect to and access the

contents of a registry through a JAXR Provider [JAX-RPC].

To develop Web Services, J2EE contains the Java API for XML-based RPC

(JAX-RPC) toolkit. JAX-RPC enables the development of interoperable and portable

SOAP-based Web services [JAX-RPC]. JAX-RPC is used to implement J2EE Web

Service clients that can connect to Web Service endpoints, as well as to implement Web

Service endpoints for clients to connect to. Two ways to create J2EE Web Service

endpoints are:

JAX-RPC Endpoints Enterprise Java Beans (EJB) Endpoints

JAX-RPC endpoints consist

of Java Servlets that have been adapted for use as a web services component. EJB

endpoints are components that providing the same functionality as the EJB, but which are

specifically designed to handle SOAP requests.

J2EE contains other APIs for the processing of XML documents and management

of SOAP requests. Java API for XML Processing (JAXP) allows for the transformation

and parsing of XML documents. SOAP with Attachments API for Java (SAAJ) contains

classes to create, send and receive SOAP messages.

3.3.3 CORBA

Web Services are very similar to the IIOP aspect of CORBA. Both allow remote

access to a target, and the implementation of the client does not matter as long as the data

is received by the target in the correct format. [CORBA/SOAP].

In 2002, OMG released a specification of how to integrate CORBA with Web

Services. This mapping automatically allows an IDL to be converted into a WSDL for

access across the web. This allows a web services client to make a SOAP call to a

CORBA system. The ORB would receive the call, get the necessary information, and

then contact the object’s implementation. [CORWS]

3.3.3.1 CORBA Advantages

CORBA has the following advantages:

Data is in the correct format when it is received from the ORB. This saves time from having to parse XML.

Standard specification, which is Defined by the OMG. Readable Interface Descriptions. SOAP wsdl files are difficult to read through. Supports various events, i.e. transaction, notification, security services.

3.3.3.2 CORBA Disadvantages

CORBA has the following disadvantages:

Data cannot be read by humans alone. Because it is in the correct/digital format. Protocol(IIOP)does not easily transport over the internet. This limits the scope of

where CORBA can be used. ORB must be present on all machines, or elaborate coding is required to workaround.

Does not directly support .NET. Cannot transport some types of documents easily, such as .pdf or .doc files.

3.3.2.3 Web Services Advantages

Web Services had the following advantages over CORBA:

Ready-made to travel over the internet because it uses the http protocol. Data is easy to read in XML format Supports .NET Supported by IBM and Microsoft. Can transport attachments without problems.

3.3.2.4 Web Services Disadvantages

Web Services have the following disadvantages:

Congestion at Port 80. Many competing SOAP standards. Difficult to encode polymorphism. No standard specification. No event services. Slower performance—data needs to be parsed WSDL files are not easy to read.

3.4 Interoperability

In this section we will compare the technologies in .NET, J2EE and CORBA that

facilitate communication between heterogeneous applications. We are focusing on the

following areas:

Components – What classes/packages support interoperability? Functionality – How do applications designed for each platform typically

communicate with heterogeneous/homogeneous components? Remote Communication – How are remote methods handled in J2EE

and .NET?

3.4.1. .NET

The .NET remoting infrastructure takes an abstract view to inter-process

communication. Meaning there is no focus on the underlying systems communicating

just the global view of sending objects back and forth, similar to web services. The goal

of a remoting system is to allow the ability to enable communication between objects in

different application domains or processes, regardless of the protocols or formats being

used on either side. To accomplish inter process communication there needs to be a

remote object (on the server side) and applications that can listen/request the object. A

remoting object is an object that can be accessed outside of its application. There are two

proxies created on the client side the TransparentProxy and the RealProxy. The

RealProxy is the object that transmits the method call to the server machine. The

TransparentProxy is an object that contains a list of all classes, as well as the exposed

methods of the remote object.

The remoting object can be used in two ways. The first way is that the remoting

object is directly copied to the client side. From there the client can execute the objects

methods directly on the local machine. This is a plausible method but usually not a

desirable for several reasons. It will usually be the case that the client does not need all

of an object’s methods. Chances are the client will only need a small subset of objects

methods so copying the entire object will waste bandwidth and memory especially for

large classes with lots of methods. Also the object will have private data that maybe be

used by the public methods. This would allow for users to access the private data

resulting in some security issues.

The second method is the method of using object references is the method that is

used for remote communication. The remoting object on the server side sends a

reference of the server object to the client rather than a copy of the object itself. The

client sends any method calls to the server side object to be executed there and not on the

local machine. The server then processes this request and uses the remoting object to

execute the method on the server side. The results are then sent back to the client. In this

way only the method call, the method arguments, the results, and possibly exceptions are

sent to the client. This way bandwidth is used more effectively and the entire object

doesn’t need to be sent just the necessary information listed above. This way also limited

the exposure of the class, which is beneficial for security.

At the code level remote objects are accessed through channels. In .NET there are

two existing types of channel classes HttpChannel and TcpChannel. Each one supports

the protocol that their name suggests. Microsoft .NET does allow for custom channels

where the coder can create a new channel type or extended a built in one like HTTP or

TCP. For example making an IIOP channel would allow for interaction between .NET

and CORBA orbs, which is currently not supported in .NET. As mentioned before inter-

process communication requires a remote object. A remote object is any object that

inherits from the class MarshalByRefObject. Not both the client and server applications

must inherit from this class as well. One limitation of the inter process communication is

that the data must be serializable so it can be sent across the network. This is not a

problem for built in data types like String, numbers, etc. as they are serializable by

design. The problem may occur in custom classes that have been created. However this

problem can be resolved easily by inheriting from the ISerializable interface.

Additionally including a serializable attribute in the class can do it.

The server of a remote object can also choose the duration of the object’s lifetime and

activation policy using the RemotingServices.RegisterWellKnownType class. The

lifetime and activation options include Single Call, Singleton, and Client Activated

Objects (CAO). The Single Call option means that an object doesn’t maintain any state.

This means that for every client request to the remote server object a new instance of the

object is created as a result. This is the activation option for web services because the

stateless nature achieves good load balancing which leads to high scalability. The

Singleton objects is where the same instance of the object is used to service requests from

clients. This type is used there is a need for consistency among shared data or resources

for all of the clients. For example, say you wanted to maintain a hit counter that tracked

the number of hits on a server resource. The third option is the notion of Client Activated

Objects (CAO) where the client activates the remote object by instantiation instead of

invoking a method. The client calls Activator.CreateInstance to create an object.

Sending an activation message to the server where the remote object is instantiated does

this. A reference is transmitted to the client. The same object on the server processes

every request the client makes. This option is more like the Singleton type rather than the

single call type. But the remote object is activated not at the point in time when the first

method is called but rather at the point of the instance creation on the server.

Selecting the properties for a remoting object such as channel and formatter

comes down to choosing the tradeoff between performance and interoperability.

The .NET framework contains two serialization formatters. The binary formatter converts

an object's state into a binary stream, which is a bit faster. And it also contains a SOAP

formatter that converts an object into an XML string representation. An advantage of the

remoting architecture in .NET is that it does not require the use a specific formatter for an

explicit channel type. For example one could use the Binary formatter with the HTTP

channel or use the SOAP formatter with the TCP channel or vice versa. The customizable

channel and formatter architecture allows you to select channels with appropriate

formatters depending on your needs and specifications

.

HTTP Channel TCP Channel Uses the SOAP serialization formatter by default. Uses the binary serialization formatter

by default. Suitable for Internet deployment and works well with firewalls.

More suitable for deployment within an internal network/LAN

Performance is fairly good. Very good performance since it uses raw sockets and a binary payload.

High interoperability. Channel can be used to talk to a large number of services (deployed even in disparate platforms) that can speak SOAP.

Not as interoperable as the HTTP channel.

Source: http://www.devarticles.com/c/a/ASP.NET/Understanding-.NETRemoting /5/

To write a custom channel, the channel class you are creating would need to

implement the IChannelSender and the IChannelReceiver interface, both which inherit

from the IChannel interface. The IChannelSender interface must have a message sink that

serializes the message and then sends it to the server object. On the server side the

IChannelReceiver implementation should perform the following five steps. First it listens

for requests then deserializes the received message. Third it should invoke the method

call on the server object. After this it should serialize the output to prepare to

transmission back to the sender. Finally it will send the output back to the client. Back

on the client side the message sink created by the IChannelSender object will read the

servers response and deserialize the message to be processed.

The topic of web Services was mentioned above and is very similar to remote

computing. Web Services is a type of remote communication. But there are some

differences between the two. First Web Services can only use the HTTP protocol

while .NET Remoting can use any protocol. Web Service communication requires a new

object to be created for every request, where a .NET remote object can handle multiple

requests. Web Services are platform independent so they are more interoperable. .NET

remoting requires the client to support this feature of remote communication, which will

most likely mean the client needs to be built in a .NET environment.

The .NET framework does not innately support CORBA protocols. As a result

there a several open source projects and commercial products available or on going to

resolve this issue. There was a project that is aiming to integrate CORBA into the.NET

framework. The project is called Remoting.NET. The main goal is to support Internet

Inter-ORB Protocol (IIOP), which are the standard protocols of CORBA and other

middleware technologies. Also the solution must have no outside dependencies and

easily adopted with out having to change any back end systems. The reason this problem

stalled is because of commercial products that accomplish the same tasks. Also another

open source project called IIOP.NET has actually been completed and is downloadable at

http://iiop-net.sourceforge.net. One product that is developed and available is Borland’s

Janeva that attempts to bridge the gap seamlessly between J2EE and .NET. Even today

there is no built in API’s that allow for .NET remoting to J2EE and CORBA applications.

As mentioned the current solutions are all done through third party software either

commercial or open source.

There is also a Microsoft product called the .NET and J2EE interoperability tool

kit. This came out in late 2003 and offers some solutions to make .NET and J2EE

applications interoperable. They offer such solutions as using .NET Remoting to enable

inter-platform connectivity by creating a custom channel for remoting objects. For

database connectivity it is possible to Employ Microsoft SQL Server 2000 to create a

shared database between .NET and J2EE. The use of web services as mentioned above

really promotes interoperability. The overall goal of the tool kit is to use bridge the gap

by using services of .NET, J2EE, and any other third party software mentioned above.

3.4.2 J2EE

In J2EE interoperability is achieved through the following: Remote Method

Invocation (RMI), Java IDL and RMI over Internet Inter-Orb Protocol (RMI-IIOP). RMI

allows J2EE Applications to communicate with remote Java applications, and uses the

Java Remote Messaging Protocol (JRMP). Java IDL Allows J2EE Apps to communicate

with objects in other languages. RMI over IIOP (RMI-IIOP) combines RMI’s ease of use

with CORBA’s interoperability, and allows Java developers to write remote interfaces in

Java that can be implemented in any CORBA-compliant language.

3.4.2.1 Remote Method Invocation (RMI)

RMI clients are Java programs that call methods of remote objects residing on

RMI servers. RMI servers are Java programs that create remote objects and bind them to

a specific name in the rmiregistry, a simple name repository that maps specific names to

remote objects [RMI]. Serialization is used to allow RMI clients to pass objects as

arguments to remote methods, and to allow RMI servers to pass objects to the client as

return values.

In the initial RMI specification, the RMI server creates a remote object that

extends the java.rmi.server.UnicastRemoteObject class. For each subsequent client

access to the remote object, the server forks a new thread to handle the client request.

Through this approach the server object must remain active for the entire duration.

Furthermore, each client request accesses the same remote object, so in some applications

where there is some shared state, the programmer may need to specify synchronization

routines.

In the release of J2SDK the java.rmi.activation.Activatable class and the RMI

daemon, rmid, were introduced to allow Java programs to specify that remote object

implementations be created and execute "on demand," rather than running all the time

[RMI]. Activatable remote objects can transition from a passive state to an active state,

when the object is accessed via a method invocation. If that remote object is not currently

executing, the system initiates the object's execution inside the JVM on the server. Using

RMI activation, the server can later deactivate the object, changing its state back to

passive, and freeing up its computational resources. A major benefit of this model is that

remote object references can be maintained over a long period of time.

3.4.3 CORBA

The OMG has specified a CORBA Interoperability Architecture. This allows

components with different implementations, such as different ORBs or distributed, non-

compliant systems, to communicate. However, implementation differences may not be

the only reason why two systems do no communicate. Administrative differences, such

as security policies, may not permit communication [CTUT].

3.4.3.1 Domains

To aide in this problem, CORBA has defined the concept of a domain. A domain

is a group of objects that for some reason do not communicate with other objects. For

one domain to communicate with another, a bridging mechanism between the two

domains must be defined. This mechanism potentially could handle different types of

communication and therefore needs to be flexible.

3.4.3.2 Bridging

Two types of bridging are generally used. Mediated bridging occurs when at the

boundary of each domain, objects are translated into a standard protocol or some other

form agreed upon by the two domains. Intermediate bridging is when the objects are

directly transformed from one domain to another. The full bridge is where if within one

CORBA environment, all of the mediation stays within that environment. Otherwise, if

the mediation differs from the standard, that is a half bridge [CTUT].

Bridges can from domains that are all within an ORB (in-line bridging) or not

(request-level bridging). In-line bridging is simpler to implement, and just needs more

stub and skeleton code or additional services in the ORB [CTUT].

3.4.3.3 Request-Level Bridging

Request level bridging is more interesting than in-line bridging because it deals

with how CORBA interoperability occurs across different platforms. The following

steps make up request-level bridging.

1) The client ORB simulates that the server ORB and the bridge are actually part of its own object. The client requests this object using the DSI.

2) The DSI, using the bridge, translates the requests.

3) The DSI invokes the request through DII of the Server. Any results are passed back.

To do this, the bridge must have access to the Interface Repository, or have pre-

defined knowledge of the object specifications. Also, The standard method for

transferring this information is GIOP [SECP].

4. Analysis

4.1 Databases (J2EE vs. .NET)

Using the State Insurance Company’s licensing application the performance eval-

uation could be run on a real world database. The existing java application was already

implemented just some time stamping code was needed before and after the query to

measure the run time. For .NET a completely new application needed to be designed.

The resulting program would connect to a database and run queries. Initially there were

come difficulties connecting to the remote database and it took considerable time. Even

connecting to a remote database was yielding problems despite examples on the Internet.

Eventually the connection was established and the identical query was run and timed.

After the compiling the results for the query:

SELECT Lic_License_Number, Org_Name, Lic_Class, Lic_Status, Lic_Cancel_Date, Lic_License_Date, Org_TIN,Org_Status FROM csg.Organization, csg.License WHERE Org_Tin=Lic_Tin and Lic_Tin_Type = 'O' and lower(Org_Name) like '%aetna%'

The time measurements were recorded over a set of 10 trials. After averaging the

times the results showed that the J2EE platform out performed .NET by almost double.

This was with a small result size. The next step was to try will larger result size. The

query instead was: 

SELECT Lic_License_Number, Org_Name, Lic_Class, Lic_Status, Lic_Cancel_Date, Lic_License_Date, Org_TIN,Org_Status FROM csg.Organization, csg.License WHERE Org_Tin=Lic_Tin and Lic_Tin_Type = 'O' and lower(Org_Name) like '%a%'

The only difference was in the where clause changing like ‘%aetna%’ to ‘%a%’.

This would fetch all organizations with the letter a in its name instead of containing

Aetna in its name. The difference in size was 4 for the first query compared to over

17,000 for the second query. The time analysis still showed that J2EE had faster query

times than .NET. Although in the large case size the time discrepancy was relatively

lower. We had to run the .NET test again because initially we were using the Fill method

of the DataAdapter object. This does run the query but additionally it fills the dataset as

well. As a result we were measuring more than just the query run time. Instead of using

the Fill method we used the ExecuteReader method, which only executed the query and

nothing else.

The licensing application uses an Oracle database for all of its data. We also

wanted to test .NET to MS Access databases and JDBC to MS Access databases and

observe the query times. The two tables that were used in the above queries Organization

and License were duplicated in an MS Access database. We populated both with 4

entries identical to the real world database. Then after running the query on the local

Access database for both platforms, both times were much lower since there was no

network communication involved. Surprisingly the Java program still achieved faster

times than .NET even though both are Microsoft Technologies. We then implemented a

separate program to connect to the Access database. We wanted to try a different

database type instead of oracle so the existing licensing application was not used. There

was no testing for large size result sets on the access database since it would be difficult

to duplicate 17,000 entries in a timely manner. For all of the test cases it held that j2EE

database connectivity is faster than the .NET technology where the result set is small in

both Oracle and Access. Also it holds that J2EE is faster on large result sets in an Oracle

database. While there is no testing or evidence to prove that large result set queries on

Access databases would be slower in .NET. Based on the results it is very likely

that .NET would be slower in this case.

4.2 Web Services (J2EE vs. .NET)

4.2.1 .NET

The analysis for .NET web services was using the built-in WSDL tool to import

WSLD files to create the proxy client source code. The WSDL file is a command line

program that inputs a WSDL with a set of parameters and will output the source code to a

specified file. We chose this direction rather than implementing ASP.NET web service

for two reasons. One reason is we wanted to try something different rather than imple-

menting code. Second the standard web service projects require a running web server,

which was not available to get the project started. The goal is to incorporate existing web

services into a client application. After downloading a WSDL file from xmethods.com

we used the tool to generate the code. We needed to specify the output language of the

resulting code, which in this case was C#. We specified a file name that was relevant.

The name was Stocks.cs since the web service was used to retrieve stock quotes for the

market and individual stocks. These are the only two necessary parameters but there are

other various options that could have been used. The next step was to take the generated

C# file and include it into the client application by copying it into the project directory.

After this the web service can be used by simply instantiating the web service object. Fi -

nally, the client will have access to the web service by invoking the desired methods in a

normal fashion.

4.2.2 J2EE

To examine J2EE’s support for web services, we created a very simple web

service that returned a String to the web service client. We created the web service and

deployed it on the Sun Application Server v8.1 that comes bundled with the J2EE1.4

SDK. Creating the web service consisted of the following steps:

1. First we created the web service interface. This class defines the methods that will be exported, and must extend the java.rmi.Remote class.

2. Then we created a class that implements the web service interface.

3. Next we created the WSDL file, with the wscompile command line utility. This utility requires the web service interface, as well as an xml file containing the name of the web service, the namespaces to be used, the packages where the web service classes reside, and the fully-qualified name of the service definition endpoint. This file was provided for us from the book we used.

4. Deploy the web service within the J2EE Application Server.

5. Build the web service stubs classes.

Next, we needed to create a client to access the web service. The simplest way to

have a client invoke the web service is to use static stubs. To create a client that used

static stubs, we did the following:

1. Create the client code that will be accessing the web service. This class must import

the javax.xml.rpc.Stub class.

2. Run the wscompile utility with the –gen:client option to generate the client stubs

3. Compile the client class.

4. Run the client.

When the client application runs from the command line, it calls the web service

and the String is output to the user.

4.3 Security

4.3.1 .NET

For all of the security experiments the focus was on authentication and authoriza-

tion rather than encryption. These topics seemed more pertinent to the class and the en-

cryption capabilities are not so interesting as there are built in functionality. For authenti-

cation in .NET, we used windows based authentication, which used the Windows Identity

and Windows Principal Object. The authentication was done using windows account in-

formation on one of our machines. The Identity Object has three members Name, Type,

and IsAuthenticated. The Name was the name of my computer and user account Name

that turned out to be FranksPC\Frank. The Type was NTLM and IsAuthenticated was

true. NTLM is a windows platform protocol that is used on top of the HTTP protocol. It

is a cryptography protocol that is standard in most Microsoft products. Essentially it

uses your windows credentials as the information for the log on service. So the Identity

is used to tell whether the user is authenticated meaning the user is who they say they are.

For authentication we used the Principal Object to describe the role the user be-

longs to. There are several built in Roles for .NET including User, Administrator, Guest,

Print Manager etc. It is also possible to have custom user defined roles if desired. The

principal object was based on one role initially it was administrator. As mentioned above

the line :

Thread.CurrentPRinciapl= myPrincipal;

where myPrincipal is the Principal object described above. This line sets the executing

thread’s Current Principal to the one that was defined. Then before the method is

executed you can use the IsInRole method inside an “if” statement to determine if the

method can be executed. So if the user who is executing the code belongs to the role you

define in the argument of IsInRole. Then the method can be executed. Other wise the

user will be denied access to that method. We chose a method that would read the

“secret” content of a file. Initially the role was Administrator, so if the user were not the

admin he would not see the content of the file. Since the user was the Admin of the PC

we were able to see the message. We then tried different built in Roles to test if we had

access. For example we were able to access the method if the role was User. However

access was denied invoking the method for Guest, Power User or Print Manager roles.

The code is easy to implement and understand. In the end it was fairly simple to

authenticate and authorize a user to access methods or resources. So code based and role

based access control was definitely easy to use. We also tried to use Microsoft passports

for authentication. But that is more for web applications and also required some

registration with Microsoft. Initially this might be a hassle but after everything is set up

it would be very easy to make use of the technology’s benefits.

4.3.2 J2EE

We tested the JAAS authentication facilities by creating a Java program

(JaasTest.java) that creates a LoginContext object, based on the JAAS configuration file

(jaas.config). In this configuration file, one LoginModule, RdbmsLoginModule is

specified, with three options specifying the JDBC driver, and url for the database

containing user/password information and a debug flag for debugging the code. The

LoginContext object is also passed a ConsoleCallBackHandler, which will be used to

prompt the user for their username and password.

When the user runs JaasTest.java they will be prompted for their username and

password. Once entering this, the RdbmsLoginModule compares this against information

in the database specified in the jaas.config file. The RdbmsLoginModule also retrieves

from the database the Principals and Credentials of the user, and returns this in the

Subject object. Finally, if authentication is successful, the JaasTest program prints out the

Principal and Credential information for the user.

We obtained this test program from an article on the Internet [JAAS], and

installing, configuring it and testing it was straightforward. We simply had to change the

driver and database information, and create a sample database containing user/role

information.

4.4 Interoperability

4.4.1 .NET

The first goal was to implement a simple remoting model by having a client and

server application as well as an implementation for a remote object. All three would be

simple programs. This went smoothly and using the TCP channel we were able to invoke

a remote method that returned, “The secret word is REMOTING”. This is very similar to

a hello world example. We then tested the remote communication on a remote machine

rather than hosting the server on the local machine. We distributed the server and client

programs to the group and were able to achieve the same functionality given the right IP

address instead of using localhost. This also worked as planned and no problems oc-

curred. To use the remote object we made a class library project in Visual Studio .NET,

which resulted in a .DLL file, which would be, referenced in both the client and server

programs. The client and server applications were just console application projects.

The second goal was to use the remote communication with a Java Client

and .NET server, a .NET client and a Java server or both. The goal in mind was to down-

load IIOP.NET, an open source project mentioned above to achieve the interoperability.

After downloading the source and reading the documentation I attempted to follow the

steps to generate the DLL’s and EXE’s that the project consisted of. Unfortunately the

makefile that was supplied did not work correctly. As a result the files that were required

were not built. We created a RMI client and server applications that were going to be

used with the .NET remoting client and servers. But due to the technical problems this

was unable to occur. But in the end we did implement remote communication on both

platforms. We established that for both platforms remote communication was easily per-

formed.

4.4.2 J2EE

To analyze RMI in Java, we created a simple Java interface (Hello.java)

containing two methods to be exported, and implementation class (HelloImpl.java). We

then created the RMI server class (HelloServer.java) that creates a HelloImpl object, and

binds the object to the name ‘HelloObj’ in the rmiregistry. We then started the

rmiregistry from the DOS prompt with the command “start rmiregistry” and ran the

HelloServer program with the command “java HelloServer”. We then created a class

HelloClient.java, which creates a reference to the remote HelloImpl object. It then calls a

method on the remote object that returns a String, and prints the String to the command

prompt. These programs were simple to test, and illustrated the basic functionality of

RMI.

4.5 CORBA

Throughout our research, we tried to implement a simple program on a CORBA

platform. This program would simply be a “Hello World” application, and in it, a Java

client would request a C++ object. However, this implementation proved to be more

difficult than we anticipated.

We tried using two different implementations of CORBA: Borland Enterprise

Server with Visibroker and TAO (The Ace ORB). However, both of these

implementations had their problems. Visibroker lacked example documentation, but was

extremely simple to install. Once installed, we had no problems creating an IDL and

compiling it. We used idl2java (see appendix 7.2) We also had no problems adding

functionality to the methods defined by the IDL. However, when trying to set up an ORB

with a functioning object, we had problems having that object run on the server.

TAO, on the other hand, had excellent examples [TAO]. However, the

installation of TAO proved to be extremely problematic, and we were not able to get it to

install on a Windows platform.

5. Conclusions

5.1 Databases (J2EE vs. .NET)

For .NET there is a detailed description of the ADO.NET interface. This includes

the functionality, the role of XML including the benefits, and the components associated

with ADO.NET. For J2EE research was conducted on the different categories of JDBC

drivers used in the J2EE. The underlying classes and functionality were also researched.

After comparing .NET and J2EE it was evident both platforms function very closely to

each other. The biggest difference was in the data structures used to store the results of

queries, DataSet for .NET and ResultSet for J2EE. These components both attempted to

process information locally rather than maintaining a continuous connection to the

database. The DataSet is a bit more complex than ResultSet, as it can perform more

database operations like creating tables and performing updates. The Dataset can behave

like a temporary relational database that is a subset of the original database.

It was also discovered that while CORBA can be used for database connectivity it

is not as relevant as the other two technologies. While you can add the middleware of

CORBA to the database connection it doesn’t make much sense to add an unnecessary

tier.

5.2 Web Services (J2EE vs. .NET)

In evaluating Web Services J2EE and .NET are more or less the same. They both

implement web services using XML over the SOAP and HTTP protocols. At this point

in time there are no underlying differences between the two as they function almost

identical and offer the same support with some minor differences.

5.2.1 CORBA and Web Services

The question of whether or not to use Web Services or CORBA depends on the

type of problem that needs to be solved. If the application is not large, needs to used by

various users, requires documents to be sent, or needs to go across the Internet, Web

Services would be the better choice. However, if the application is a large-scale

application that does not require communication across the Internet and emphasizes

performance, CORBA would be the better choice.

5.3 Security

Both .NET and J2EE include rich support for evidence based security, verification

process, role-based security, code access security and cryptography. Both platforms allow

for declarative and programmatic security enforcement. When deploying web

components, both J2EE and .NET utilize configuration files to specify role/method

mappings. Furthermore, they each allow applications to utilize underlying authentication

mechanisms, including the user/group information on the underlying operating system,

LDAP directory, or database servers. For cryptography, .NET and J2EE both provide

cryptographic utilities to enable secure communication.

The CORBA metamodel describes the functionality that should be supported by

CORBA implementations to enable authentication, authorization and encryption. Each

CORBA implementation must be analyzed individually to determine how much security

functionality it supports.

5.4 Interoperability

Both J2EE and .NET easily allow inter-process communication between

applications running on similar platforms. At this time J2EE provides more support for

interoperability with other CORBA-compliant languages than .NET. Other than this, they

provide very similar support for customizing the way data is sent, and the persistence of

remote objects on the servers. So we did not find any significant reasons to use one over

the other for this criteria.

Based on our research, we decided that CORBA could be extremely useful when

deploying large-scale distributed systems. This is because CORBA’s whole focus is

interoperability, and its strengths are in dealing with lots of data of different types. Based

upon the difficulty we had using CORBA, it is not worth using for a small-scale

application. In other words, if interoperability is needed among different

languages/platforms and with few users, the remoting methods previously discussed

should be used instead of CORBA. The choice to use CORBA should be a deliberate

one. Simply because interoperability is needed does not mean that CORBA will solve

the problem.

6. Future Work

One of the ideas we had for future work was to run different implementations of

CORBA.  By having different implementations running, we could examine different

metrics, such as how quickly the ORB processes data.  We could also examine more

qualitative issues such as how easily each implementation is to use.  Finally, we could see

how difficult it is to make a CORBA system secure.  By adding the various parts of the

security specifications to a CORBA system, we can see how well the specifications

perform against real-world threats.

Another avenue of future work encompasses examining databases connectivity

for both platforms. For the project only two types of databases and two queries were

tested due to timing constraints and due to .NET database connectivity issues. While

Oracle and Access are two of the more prominent databases examining other types like

SQLServer for example would have been interesting to include. Additionally different

types of queries with more joins and selected columns need investigation. The testing

conducted was very interesting using a real world database but only the surface was

scratched in terms of testing. So as result further review would yield a more definitive

conclusion.

In regards to security, more research can be done to test the authentication and

authorization mechanisms in .NET and J2EE. In particular, we could examine and test the

facilities to perform authentication and authorization in Web-based applications, and to

see which platform provides more customizable solutions. Also, we would like to test

some of the encryption routines in each platform.

We were able to get remote communication to work in both .NET and J2EE fairly

easily. The goal was to get either a Java client and .NET server or vice versa to

communicate with each other. We tried using a open source project IIOP.NET to attempt

interoperability between .NET and J2EE. Unfortunately due to technical issues this was

not accomplished. Either further attempts with IIOP.NET or trying a commercial product

from Borland or Microsoft would be the future direction. I tried emailing the authors of

IIOP.NET for support but have gotten no reply. Maybe some funding or free trial for

either product might result in the accomplishing the task.

Another idea we became interested in throughout this project that might prove

interesting to study would be to merge two of our topics together. Specifically, we were

wondering what types of security mechanisms are available for use in Web Services.  As

Web Services are just XML sent over the SOAP protocol, are there ways to make that

XML secure?  How do we make sure that a Web Service is being used by an authorized

user?  Similarly, we could analyze the security mechanisms in RMI in J2EE and

Remoting in .NET. These types of questions provide an interesting synthesis of these two

areas of computing.

7. References

[ADO.NET 1] Overview of ADO.NEThttp://www.csharphelp.com/archives3/archive586.html [ADO.NET 2] ADO.NET and .NET frameworkhttp://www.perfectxml.com/apress/ADONETIntro.pdf

[CORBA/SOAP] Web Services/SOAP and CORBA, http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html

[CORWS] CORBA to WSDL/SOAP Interworking Specification. Object Management Group. http://www.omg.org/docs/ptc/03-01-14.pdf. January 2003.

[CTUT] Brief Tutorial on CORBA. Keahey, Kate.

[JAAS] Article on JAAS http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-jaas_p.html

[JAX-RPC] Article on JAX-RPChttp://java.sun.com/features/2003/01/jax_rpc.html

[JCA SPEC] Java Cryptography Architecture API Specification & Referencehttp://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html

[JDBC] JDBC Introduction[http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/intro.html#1018502]

[J2EE APP MODEL] J2EE Application Model http://www.java.sun.com/j2ee/appmodel.html

[J2EE INTRO] Introduction to J2EEWeaver, Mukhar, Crume Beginning J2EE 1.4, From Novice to Professional New York, NY Apress 2004

[J2EE SEC] Java SecurityPistoia, Nagaratnam, Koved, Nadalin Enterprise Java Security Building Secure J2EE Applications Addison Wesley, 2004

[J2EE SPEC] J2EE Specification, v1.4http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf

[J2EE WS] Java Web Services Developer Pack 1.6 Tutorialhttp://java.sun.com/webservices/docs/1.6/tutorial/doc/index.html

[.NET Intro] Includes some background info on .NET,David S.Platt Introducing Microsoft.NET 2002 Microsoft Press Redmond, Washington.

[.NET Oracle] .NET Application Development with Oracle,http://www.oracle.com/technology/pub/articles/mastering_dotnet_oracle/index.html

[.NET Report] Previous semester report, http://www.engr.uconn.edu/~steve/Cse298300/Fall02Projs/NetInitiative/NIFinalReport.doc

[.NET Web] Includes Web Services and Database information,Bob Willer Developing XML Web Services and server components with Microsoft Visual Basic.NET and C#.NET Redmond, WA Microsoft Press 2003.

[.NET remoting1] Remoting Source Code, http://www.devx.com/dotnet/Article/7002/0/page/3

[.NET remoting2] .NET Remoting Classeshttp://www.devarticles.com/c/a/ASP.NET/Understanding-.NET-Remoting/5/

[.NET remoting3] .NET Remoting Informationhttp://www.developer.com/net/cplus/article.php/1479761

[IIOP.NET] IIOP.NET project web pagehttp://iiop-net.sourceforge.net/

[.NET authorization] Authorization and Authentication Code,http://www.c-sharpcorner.com//Code/2002/April/DotNetSecurity.asp

[.NET encryption] Microsoft documentation on Crypto APIhttp://msdn.microsoft.com/library/?url=/library/en-us/dncapi/html/encryptdecrypt2a.asp

[.NET security] CSE Middleware Security paper,http://www.engr.uconn.edu/%7Esteve/Cse298300/DemurjianMWsecurity.pdf

[.NET security] Article discussing .NET Securityhttp://www.informit.com/articles/article.asp?p=102217&seqNum=3&rl=1

[.NET interoperability] .NET and Java interoperabilityhttp://www.devx.com/interop/Article/19928/1954?pf=true

[OMG] Getting Started with CORBAhttp://www.omg.org/gettingstarted/corbafaq.htm

[OMGS] OMG Security. Object Management Group. http://www.omg.org/technology/documents/formal/omg_security.htm. May 2005

[ORB] ORB Basics. Object Management Group. http://www.omg.org/gettingstarted/orb_basics.htm . May 2005.

[RMI] Java RMI Specification

http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmiTOC.html

[SECP] SECP Revised Submission. Objective Interface Systems, Inc. http://www.omg.org/docs/security/04-06-01.pdf . June 2004

[SSS] Security Service Specification. Object Management Group. http://www.omg.org/docs/formal/02-03-11.pdf. March 2002.

[TAO] Distributed Object Computing with CORBA Middleware, Schmidt, Douglas, http://www.cs.wustl.edu/~schmidt/corba.html. June 2005.

[VOGEL] Java Programming with CORBA. Vogel, Andreas. John Wiley & Sons, Inc. February 1998.

7. Appendices

7.1 ADO.NET architecture

7.2 CORBA IDL

The following is an example of a CORBA IDL [VOGEL].

   module helloWorld { 

      interface  GoodDay  { 

      string  hello(); 

   };

};};}; 

7.3 .NET Remoting

7.3.1 Server using System;using System.Runtime.Remoting;using System.Runtime.Remoting.Channels;

Data Reader DataRelationCollection

Parameters

Transaction Select Command

Insert Command

Delete Command

Update Command

Connection

Command

.NET Data Provider Connection DataTableCollection

DataSet

DataRowCollection

DataColCollection

ConstraintCollection

XML

using System.Runtime.Remoting.Channels.Tcp;namespace RemotingDemo {public class Demo {public static int Main(string [] args) {TcpChannel chan = new TcpChannel(8085);ChannelServices.RegisterChannel(chan);RemotingConfiguration.RegisterWellKnownServiceType(Type.GetType("RemotingDemo.MyRemoteClass,RemoteClass"), "Secret", WellKnownObjectMode.SingleCall);System.Console.WriteLine("Hit <enter> to exit...");System.Console.ReadLine();return 0;}}} 7.3.2 Client using System;using System.Runtime.Remoting;using System.Runtime.Remoting.Channels;using System.Runtime.Remoting.Channels.Tcp;namespace RemotingDemo {public class Client{public static int Main(string [] args){TcpChannel chan = new TcpChannel(8084);ChannelServices.RegisterChannel(chan);MyRemoteClass obj = (MyRemoteClass)Activator.GetObject(typeof(RemotingDemo.MyRemote-Class), "tcp://localhost:8085/Secret");if (obj == null)System.Console.WriteLine("Server not found.");else Console.WriteLine("The secret word is " + obj.SecretWord());Console.ReadLine();return 0;}}}

 7.3.3 Remote Objectusing System;namespace RemotingDemo {public class MyRemoteClass : MarshalByRefObject {public MyRemoteClass(){Console.WriteLine("MyRemoteClass activated");}public String SecretWord(){return "REMOTING";}}}

7.4 .NET Web ServicesThis was the code that was generated by the WSDL tool in .NET// <autogenerated>// This code was generated by a tool.// Runtime Version: 1.1.4322.2032//// Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated.// </autogenerated>//------------------------------------------------------------------------------// // This source code was auto-generated by wsdl, Version=1.1.4322.2032.// namespace STOCK { using System.Diagnostics; using System.Xml.Serialization; using System; using System.Web.Services.Protocols; using System.ComponentModel; using System.Web.Services; /// <remarks/> [System.Diagnostics.DebuggerStepThroughAttribute()] [System.ComponentModel.DesignerCategoryAttribute("code")] [System.Web.Services.WebServiceBindingAttribute(Name="StockQuotesSoap", Namespace="http://ws.in-vesbot.com/")]

public class StockQuotes : System.Web.Services.Protocols.SoapHttpClientProtocol { /// <remarks/> public StockQuotes() { this.Url = "http://ws.invesbot.com/stockquotes.asmx"; } /// <remarks/> [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://ws.invesbot.com/GetQuotes", RequestNamespace="http://ws.invesbot.com/", ResponseNamespace="http://ws.invesbot.com/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)] public System.Xml.XmlNode GetQuotes(string symbols) { object[] results = this.Invoke("GetQuotes", new object[] { symbols}); return ((System.Xml.XmlNode)(results[0])); } /// <remarks/> public System.IAsyncResult BeginGetQuotes(string symbols, System.AsyncCallback callback, object asyncState) { return this.BeginInvoke("GetQuotes", new object[] { symbols}, callback, asyncState); } /// <remarks/> public System.Xml.XmlNode EndGetQuotes(System.IAsyncResult asyncResult) { object[] results = this.EndInvoke(asyncResult); return ((System.Xml.XmlNode)(results[0])); } /// <remarks/> [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://ws.in-vesbot.com/GetMarketIndex", RequestNamespace="http://ws.invesbot.com/", ResponseNamespace="http://ws.invesbot.com/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)] public System.Xml.XmlNode GetMarketIndex() { object[] results = this.Invoke("GetMarketIndex", new object[0]); return ((System.Xml.XmlNode)(results[0])); } /// <remarks/> public System.IAsyncResult BeginGetMarketIndex(System.AsyncCallback callback, object asyncState) { return this.BeginInvoke("GetMarketIndex", new object[0],

callback, asyncState); } /// <remarks/> public System.Xml.XmlNode EndGetMarketIndex(System.IAsyncResult asyncResult) { object[] results = this.EndInvoke(asyncResult); return ((System.Xml.XmlNode)(results[0])); } /// <remarks/> System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://ws.invesbot.com/GetECN-Quotes", RequestNamespace="http://ws.invesbot.com/", ResponseNamespace="http://ws.invesbot.com/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)] public System.Xml.XmlNode GetECNQuotes(string symbols) { object[] results = this.Invoke("GetECNQuotes", new object[] { symbols});

Console.WriteLine((String)results[0]); return ((System.Xml.XmlNode)(results[0])); } /// <remarks/> public System.IAsyncResult BeginGetECNQuotes(string symbols, System.AsyncCallback callback, object asyncState) { return this.BeginInvoke("GetECNQuotes", new object[] { symbols}, callback, asyncState); } /// <remarks/> public System.Xml.XmlNode EndGetECNQuotes(System.IAsyncResult asyncResult) { object[] results = this.EndInvoke(asyncResult); return ((System.Xml.XmlNode)(results[0])); } }}Invocation:STOCK.StockQuotes sq= new STOCK.StockQuotes(); sq.GetQuotes("MSFT");

7.5 .NET Security

private void button1_Click(object sender, System.EventArgs e){try

{//By default deny access to the C Drive.....CodeAccessPermission UserPermission = new FileIOPermission(FileIOPermissionAccess.AllAc-cess,@"c:\");//Check whether the user is part of the administrator groupAppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);WindowsPrincipal principal = (WindowsPrincipal)Thread.CurrentPrincipal;WindowsIdentity identity = (WindowsIdentity)principal.Identity;bIsAdmin = principal.IsInRole(WindowsBuiltInRole.Guest);MessageBox.Show(bIsAdmin.ToString());//Its not, so deny access to the fileif(!bIsAdmin){UserPermission.Deny();}else{//Do the readdin = ReadTheFile.DoTheRead();}if(!bIsAdmin){//Reset deny permissions in current stack frameCodeAccessPermission.RevertDeny();}//If we got this far .... we read in the fileelse{String str;while ((str=din.ReadLine()) != null) {listBox1.Items.Add(str);}}}catch (SecurityException exception){//Failed to pass the security checks - so flag up error to user listBox1.Items.Add("Permission denied accessing file");} }

7.6 Database Connectivity7.6.1 .NETprivate void Form1_Load(object sender, System.EventArgs e)

{//odbcDataAdapter1.SelectCommand.CommandText=

"SELECT Lic_License_Number, Org_Name,Lic_Class, Lic_Status,Lic_Cancel_Date,Lic_License_Date,Org_TIN,Org_Status FROM csg.Organization,csg.License WHERE Org_Tin=Lic_Tin and Lic_Tin_Type = 'O' and lower(Org_Name) like '%a%'";oleDbDataAdapter1.SelectCommand.CommandText = "Select Org_Name,License_Number FROM License, Organization where License_Number=Org_TIN";

dataSet1.Clear();try{

DateTime st= System.DateTime.Now;oleDbConnection1.Open();oleDbDataAdapter1.SelectCommand.ExecuteReader();

//odbcDataAdapter1.Fill(dataSet1, "Organization");DateTime fin= System.DateTime.Now;Console.WriteLine(fin.Subtract(st));oleDbConnection1.Close();}

catch(Exception ex){ MessageBox.Show(ex.ToString());}oleDbDataAdapter1.Fill(dataSet1, "License");dataGrid1.SetDataBinding(dataSet1, "License");}}7.6.2 J2EE

import java.sql.*;

public class JDBCClient {

public static void main(String[] args) {

Connection conn = null;try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); }catch (Exception e) { e.printStackTrace(); System.out.println("error loading driver .. exit system");}

String filename = "c:/expenses.mdb";

String database = "jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ="; database+= filename.trim() + ";DriverID=22;READONLY=false}";

try { // conn = DriverLoader.getConnection(url,username,password); conn = DriverLoader.getConnection(database); DatabaseMetaData dbmd = conn.getMetaData(); System.out.println("DB name is " + dbmd.getDatabaseProductName()); System.out.println("DB version is " + dbmd.getDatabaseProductVersion()); System.out.println("DB driver name is " + dbmd.getDriverName()); System.out.println("DB driver version is " + dbmd.getDriverVersion());

Statement stmt = conn.createStatement();

int result; }

catch (Exception e) { e.printStackTrace();} finally { DriverLoader.close(conn);}

}}

7.7 J2EE Security

7.7.1 JaasTest.java

/* Java imports */import java.io.*;import java.util.*;

/* JAAS imports */import java.security.*;import javax.security.auth.*;import javax.security.auth.login.*;import java.security.PrivilegedAction;

/** * <p> * JaasTest uses JAAS and our custom RdbmsLoginModule * and ConsoleCallbackHandler. Prompts and reads from the * command line console line for username/password and * then authenticates using a JDBC database. * * @author Paul Feuer and John Musser * @version 1.0

*/

public class JaasTest {

public static void main(String[] args) {

boolean loginSuccess = false; Subject subject = null;

try { ConsoleCallbackHandler cbh = new ConsoleCallbackHandler();

LoginContext lc = new LoginContext("MyExample", cbh);

try { lc.login(); loginSuccess = true;

subject = lc.getSubject();

Iterator it = subject.getPrincipals().iterator(); while (it.hasNext()) System.out.println("Authenticated: " + it.next().toString());

it = subject.getPublicCredentials(Properties.class).iterator(); while (it.hasNext()) ((Properties)it.next()).list(System.out);

lc.logout(); } catch (LoginException lex) { System.out.println(lex.getClass().getName() + ": " + lex.getMessage()); }

} catch (Exception ex) { System.out.println(ex.getClass().getName() + ": " + ex.getMessage()); }

if (loginSuccess == true) { PrivilegedAction action = new SampleAction(); Subject.doAsPrivileged(subject, action, null);

} } }

7.7.2 RdbmsLoginModule.java

/* Java imports */import java.io.*;import java.util.*;

/* JAAS imports */import java.security.*;import javax.security.auth.*;import javax.security.auth.login.*;import java.security.PrivilegedAction;

/** * <p> * JaasTest uses JAAS and our custom RdbmsLoginModule * and ConsoleCallbackHandler. Prompts and reads from the * command line console line for username/password and * then authenticates using a JDBC database. * * @author Paul Feuer and John Musser * @version 1.0 */

public class JaasTest {

public static void main(String[] args) {

boolean loginSuccess = false; Subject subject = null;

try { ConsoleCallbackHandler cbh = new ConsoleCallbackHandler();

LoginContext lc = new LoginContext("MyExample", cbh);

try { lc.login(); loginSuccess = true;

subject = lc.getSubject();

Iterator it = subject.getPrincipals().iterator(); while (it.hasNext()) System.out.println("Authenticated: " + it.next().toString());

it = subject.getPublicCredentials(Properties.class).iterator(); while (it.hasNext()) ((Properties)it.next()).list(System.out);

lc.logout(); } catch (LoginException lex) { System.out.println(lex.getClass().getName() + ": " + lex.getMessage()); }

} catch (Exception ex) { System.out.println(ex.getClass().getName() + ": " + ex.getMessage()); }

if (loginSuccess == true) { PrivilegedAction action = new SampleAction(); Subject.doAsPrivileged(subject, action, null);

} } }

7.7.3 jaas.config

MyExample {

RdbmsLoginModule required driver = "sun.jdbc.odbc.JdbcOdbcDriver"url = "jdbc:odbc:testdb"debug = "false";

};

7.8 RMI

7.8.1 Hello.java

import java.rmi.Remote; import java.rmi.RemoteException; import java.util.Date;public interface Hello extends Remote { public String getMsg() throws RemoteException; public Date getDate() throws RemoteException; }

7.8.2 HelloImpl.java

import java.rmi.*;import java.rmi.server.UnicastRemoteObject;import java.util.Date;public class HelloImpl extends UnicastRemoteObject implements Hello { private String message; public HelloImpl(String msg) throws RemoteException { message = msg; } public String getMsg() throws RemoteException { return message; } public Date getDate() throws RemoteException {

return new java.util.Date(); }} 7.8.3 HelloServer.java

import java.rmi.Naming; import java.rmi.RemoteException;

public class HelloServer { public static void main(String[] args) {

String msg = "Hello Client Machine";try { HelloImpl obj = new HelloImpl(msg); System.out.println("HelloImpl object created"); Naming.rebind("Hello",obj); System.out.println ("HelloImpl object bound in registry");} catch (Exception e) { System.out.println( "Hello Server failed: " + e);}

} }

7.8.4 HelloClient.java

import java.rmi.Naming; import java.rmi.RemoteException;

public class HelloClient {

public static void main(String[] argv) {try { // "obj" is the identifier that we'll use to refer // to the remote object that implements the "Hello" // interface Hello obj = (Hello)Naming.lookup("//192.168.0.101/Hello"); System.out.println( obj.getMsg() ); } catch (Exception e) { System.out.println("Hello Client exception: " +

e.getMessage()); e.printStackTrace(); }

} }

7.9 Breakdown of Responsibilities

3.1 Database Connectivity3.1.1        ADO .NET (Frank)3.1.2        JDBC (Seth)3.1.3        CORBA (Phil)3.1.5        Example code and analysis (All) 3.2 Security3.2.1        .NET (Frank)3.2.2        J2EE (Seth)3.2.3        CORBA (Phil)3.2.5        Example code and analysis (All) 3.3 Web Services3.3.1        .NET (Frank)3.3.2        J2EE (Seth)3.3.3        CORBA (Phil)3.3.5        Example code and analysis (All) 3.4        Interoperability3.4.1        .NET (Frank)3.4.2       J2EE (Seth)3.4.3        CORBA (Phil)

7.10 Changes

The following changes have been made since our initial specification:

Changed the Multi-threading section to Interoperability.. Updated the database interoperability section to database connectivity. Added experimentation to database connectivity, web services and remote

communication. Changed the experiment section to analysis Focused on what we are examining for security and Web Services.

The main change was in our fourth topic. In the initial specification we didn’t have a clear direction in our research. This issue has been resolved and is now more focused. Additionally there is more focus in the other areas and the overall scope is more defined.