Download DOCFIN

Enterprise Component Comparison:
An Examination of J2EE, CORBA, and .NET
Final Report
Seth Freeman
Phil Griffith
Frank Manni
12/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 enterprisewide 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.
VB.NET
C#
VJ#
VC++.NET
Web
forms
XML Web
Services
ASP.NET
……..
Window
Forms
.NET Framework class Library
Common Language Runtime (CLR)
Win 32
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,
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. JDBCODBC 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 platformspecific 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.
Principal, Windows and Generic.
There are only 2 classes for
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 windowbased 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.
Client Side
Middle Tier
Enterprise Information
Server
Web Application Servers:
JSP, Servlets, HTML, XML
RDBMS, ERP,
Legacy Apps
EJB Server, JNDI,
JMS, JavaMail
Figure 6. J2EE Application Configuration
3.2.2.2 Authentication
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 FormBased 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,
typically 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.
Application
LoginContext
RdbmsLoginModule
JNDILoginModule
LoginModules
RDBMS
LDAP Server
Kerberos Authentication
NT Authentication
Biometric Authentication
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)
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 securityconstraint 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
utilized by each J2EE application server. Typically, user/role mappings are stored in a
database, 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.
1
Directory
Service
2
Client
3.
Web
Service
4.
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
(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:







3.4
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.
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 interprocess 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 Uses the binary serialization formatter
default.
by default.
Suitable for Internet deployment and works well More suitable for deployment within an
with firewalls.
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 Not as interoperable as the HTTP
talk to a large number of services (deployed even channel.
in disparate platforms) that can speak SOAP.
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, noncompliant 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 predefined 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
evaluation 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
implementing 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. Finally, 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
authorization rather than encryption. These topics seemed more pertinent to the class and
the encryption capabilities are not so interesting as there are built in functionality. For
authentication in .NET, we used windows based authentication, which used the Windows
Identity and Windows Principal Object. The authentication was done using windows
account information 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
belongs 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
occurred. 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 download
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 performed.
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.
5.1
Conclusions
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.NET
http://www.csharphelp.com/archives3/archive586.html
[ADO.NET 2] ADO.NET and .NET framework
http://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-RPC
http://java.sun.com/features/2003/01/jax_rpc.html
[JCA SPEC] Java Cryptography Architecture API Specification & Reference
http://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 J2EE
Weaver, Mukhar, Crume Beginning J2EE 1.4, From Novice to Professional
New York, NY Apress 2004
[J2EE SEC] Java Security
Pistoia, Nagaratnam, Koved, Nadalin Enterprise Java Security Building Secure J2EE
Applications Addison Wesley, 2004
[J2EE SPEC] J2EE Specification, v1.4
http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf
[J2EE WS] Java Web Services Developer Pack 1.6 Tutorial
http://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.d
oc
[.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 Classes
http://www.devarticles.com/c/a/ASP.NET/Understanding-.NET-Remoting/5/
[.NET remoting3] .NET Remoting Information
http://www.developer.com/net/cplus/article.php/1479761
[IIOP.NET] IIOP.NET project web page
http://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 API
http://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 Security
http://www.informit.com/articles/article.asp?p=102217&seqNum=3&rl=1
[.NET interoperability] .NET and Java interoperability
http://www.devx.com/interop/Article/19928/1954?pf=true
[OMG] Getting Started with CORBA
http://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
.NET Data Provider
Connection
Transaction
Command
Parameters
DataSet
Connection
Select Command
Insert Command
Update Command
DataTableCollection
DataRowCollection
DataColCollection
ConstraintCollection
Delete Command
Data Reader
DataRelationCollection
XML
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;
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.MyRemoteClass),
"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 Object
using System;
namespace RemotingDemo
{
public class MyRemoteClass : MarshalByRefObject
{
public MyRemoteClass()
{
Console.WriteLine("MyRemoteClass activated");
}
public String SecretWord()
{
return "REMOTING";
}
}
}
7.4 .NET Web Services
This 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.invesbot.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.invesbot.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/GetECNQuotes",
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.AllAccess,@"c:\");
//Check whether the user is part of the administrator group
AppDomain.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 file
if(!bIsAdmin)
{
UserPermission.Deny();
}
else
{
//Do the read
din = ReadTheFile.DoTheRead();
}
if(!bIsAdmin)
{
//Reset deny permissions in current stack frame
CodeAccessPermission.RevertDeny();
}
//If we got this far .... we read in the file
else
{
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 Connectivity
7.6.1 .NET
private 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 Connectivity
3.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
Security
3.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 Services
3.3.1 .NET (Frank)
3.3.2 J2EE (Seth)
3.3.3 CORBA (Phil)
3.3.5 Example code and analysis (All)
3.4 Interoperability
3.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.