III - University of Connecticut



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.

1. J2EE

J2EE (Java 2 Platform, Enterprise Edition) is a specification to enable application developers to develop multi-tier enterprise-wide distributed applications. J2EE was developed by Sun Microsystems in collaboration with leaders in the enterprise software arena; it focuses on providing a software platform that promotes the development and deployment of reusable software components.

J2EE is an extension of J2SE (Java Platform 2, Standard Edition). J2SE consists of a robust set of API’s for application developers based on the Java programming language. Applications developed in J2SE are compiled into Java byte code and run on the Java Virtual Machine (JVM). The core Java API’s and the JVM together constitute the Java Runtime Environment (JRE) which is required on any hardware platform which wants to support J2SE. Figure 1 is a diagram of J2SE v1.5 which shows the relationship between J2SE, JRE, JVM as well as the numerous packages available.

Figure 1. Java 2 Standard Edition version 1.5

J2EE extends the J2SE by adding support for Enterprise JavaBeans components, Java Servlets, JavaServer Pages, XML technologies and Web Services. Enterprise Java Beans are server-side components used to encapsulate the business logic of an application. Java Servlets are Java programs used to extend the functionality of a server. JavaServer Pages (JSP) are HTML documents embedded with Java code, used to dynamically create HTML pages. XML technologies are used to allow the transfer of data between various components in a distributed application, and are realized through multiple packages including Java API for XML Processing (JAXP). Web Services are supported through Java packages such as Java API for XML-based RPC (JAX-RPC). This extra functionality provided in J2EE is what enables the development of enterprise-wide applications.

2.2 .NET

.NET, developed by Microsoft in 2002, is a platform designed for application developers to quickly develop Internet-based applications. .NET supports distributed application development by including database support through , legacy support through , as well as support for Web Services and XML. The .NET Framework is the infrastructure to support .NET technologies consists of the following components, illustrated in Figure 2.

Figure 2. Framework for .NET

The .NET Architecture is comprised mostly of two components.  One is the .NET Framework class library and the other is the Common Language Runtime (CLR).  The CLR is responsible for providing the run time environment and services to the .NET framework.  The CLR consists of many components including the garbage collector, 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 , 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 .    Overall, the  .NET framework provides a consistent language independent model for developing all types of applications, making it great environment for developers.

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.

[pic]

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

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

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

1. XML benefits

The .NET framework has made database an independent issue for developers by providing integration of XML with . Regardless of the database used by the developers because the code for querying the database is the same for all applications. 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 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 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, 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

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 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 . One advantage of the 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 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.

1. JDBC

Java Database Connectivity (JDBC) is an API that allows Java programs to work with databases. JDBC provides tools for application developers to allow clients to connect to databases, and then send commands to the database in the SQL language. JDBC contains a set of database-neutral classes and interfaces. These classes communicate with the database-specific code, referred to as a driver, which is developed by the database vendor or some third party. JDBC is contained in the java.sql package.

3.1.2.1 Connecting to Databases

The first step in working with databases is to open a connection to the database. Opening a connection is done through the DriverManager class, which ‘manages’ the drivers for different databases, and chooses the specific driver for the given database the client wishes to connect to. JDBC supports four categories of drivers that can be used to communicate with databases [JDBC]. These four types of drivers are:

▪ JDBC-ODBC bridge with ODBC driver

▪ Native-API partly-Java driver

▪ JDBC-Net pure Java driver

▪ Native-protocol pure Java driver

JDBC-ODBC bridge enables JDBC access to a database by mapping JDBC to ODBC and then using the ODBC driver. ODBC (Open Database Connectivity), developed by Microsoft, is a popular API for accessing databases, written in C. JDBC-ODBC bridge is typically only used when then no JDBC driver exists.

Native-API partly-Java driver maps JDBC to some native API for a database. For example, JDBC calls may be mapped to an API for Oracle, Sybase, or some other DBMS. This solution, like the JDBC-ODBC bridge requires some binary code be loaded on each client machine.

JDBC-Net pure Java driver converts JDBC calls to a DBMS-independent net protocol, which is sent to a middleware server that translates the net protocol into a DMBS-specific protocol. The middleware server typically resides on a different machine. This solution allows all-Java clients to connect to many different databases, yet requires the use of an additional server.

Native-protocol pure Java driver, referred to as a thin driver, translates JDBC directly into the database’s native protocol. This driver is completely written in Java, and allows the client application to directly call the DBMS server. There is no platform-specific code necessary, so this driver can be used on any platform with a Java virtual machine.

In JDBC 2.0 DataSources were introduced to allow programmers a more flexible way to create and use database connections [J2EE INTRO]. A DataSource is an object that implements the DataSource interface, and returns a Connection object to the client.

Prior to using a DataSource object, some server must create a DataSource object and bind it to a name in the directory service. Client applications then access the directory service through Java Naming and Directory Interface (JNDI), an API providing a collection of methods to interact with directory services. Through DataSource objects, the client does not need to know anything about the database, just the name that is associated with it. Furthermore, changes can be made to the database and/or drivers without any knowledge of the client application.

3.1.2.2 Statements

The Statement class is used to create, update, retrieve, and delete data from a database. Statement objects are created using the createStatement( ) method of the Connection class. Statement objects contain methods which pass SQL commands to the database, and return the results of the SQL commands. SQL commands such as create, insert, update, and delete can be passed as arguments to the executeUpdate( ) method of Statement objects. SQL commands to query the database are passed as arguments to the executeQuery( ) method of Statement objects.

JDBC also allows for the specification of multiple SQL commands to be executed together as a batch. The Statement object contains the method addBatch( ) which allows the programmer to group multiple SQL commands together. The method executeBatch( ) sends the entire batch of SQL commands to the database at once, and returns an array of integers corresponding to the result of the operation.

3.1.2.3 ResultSets

ResultSet objects are the results of an SQL query sent through an executeQuery() method of the Statement object. ResultSet objects contain methods to navigate through the rows in the ResultSet, as well as extract data from columns for a given row in the ResultSet. There are different types of ResultSet objects, and they can be classified based on how the allow the programmer to scroll through them, what happens when they are updated, and how long the ResultSet stays open.

3.1.2.3.1 Scrollable ResultSet

Since query results often contain multiple records, there must be a mechanism to move from one record to another. There are two types of ResultSet objects, NonScrollable and Scrollable, which differ in how they allow the programmer to do this.

Nonscrollable ResultSet objects only allow the client to move from the first row to the last row of the ResultSet object. The next( ) method of the ResultSet object allows the client to move to the next row.

Scrollable ResultSet objects allow the programmer to move forward and backwards through the results of the query, as well as skip to the beginning and end. Methods available to the Scrollable ResultSet object include next( ), previous( ), afterLast( ) and beforeFirst( ).

3.1.2.3.2 Updateable ResultSet

Prior to JDBC 2.0, ResultSet objects only contained functionality to move from one record to the next and read the data in the columns for each record. JDBC 2.0 introduced the ability to update the data in the database directly through the ResultSet object. Updateable ResultSet objects contain methods to update columns for a given record, insert new records, and delete records in the ResultSet object.

3.1.2.3.3 Holdable ResultSet

Prior to JDBC 3.0, ResultSet objects were typically released as soon as another Statement object was executed. JDBC 3.0 added the functionality that a ResultSet object could remain open when a new SQL command is executed by the Statement object. These ResultSet objects are referred to as Holdable.

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

[pic]

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?

1. .NET

The .NET framework provides solutions for implementing authentication, authorization, and cryptographic schemes. The two main components mentioned above, CLR and the class libraries help aid in these solutions. The CLR prevents unexpected behavior and limits code execution. Using just in time compilation, the native machine code can make use of the CLR’s security engine to process code to enforce some security measures. The class library contains classes concerning cryptographic protocols and authentication / authorization mechanisms, etc. These 2 components are the driving force behind Microsoft’s managed code idea that is demonstrated in the .NET Framework.

The framework encompasses several areas of security. These include evidence based security, verification process, Role-based security, code access security, and cryptography. Evidence based security, the verification process, and code access security all deal with ensuring proper behavior of machine code. This is the idea of managed code, which will not be the focus of this paper. The paper will focus more on encryption (Cryptography), authentication, and authorization (Role-based security) aspects of the framework.

The .NET framework implements role based access with its Principal and Identity Model. The Principal is simply the user of the application who is executing the code. Using the authentication measures mentioned below the principal’s Identity is verified. Then after verification the principal can be assigned roles. So each application will have its own principal object that contains its identity and list of roles. The roles will be most likely listed in a database that will be mapped to different users.

3.2.1.1 Authentication

The identity and principal objects are essentially an abstraction of a user and their roles. The identity consists of three properties Name, IsAuthenticated, and Type. There are four types of identity classes: passport, forms, windows, and generic. The first three are fairly well defined but the generic version is designed to be custom. The principal object is the holder of roles for the user. The principal object uses the Principal interface which works in conjunction with the Identity object. There are only 2 classes for Principal, Windows and Generic. The windows principal works with the windows identity, while the generic one works with the others.

.NET supports several different methods for authentication to determine credentials. Authentication is the first step for Role based security. Once ones identity is verified authorization procedures can be taken into account to determine the roles for the user. Authentication is classified under three types form based, passport, and window-based authentication.

Form based authentication is using web based (HTML) forms to verify unauthenticated requests which will then get redirected back to the server. The application will use a database or exchange server to verify credentials. Specifically in 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 , 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

_

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

_

 Public Overridable Sub DoSomething()

   ' ...

 End Sub

End Class

Source:

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

Using either of these 2 ways you can place limitation on methods or classes using the Principal object or Principal Permissions Object. You can also use security demands to place restrictions on the entire class or specific methods. Both methods are essentially the same, they differ in syntax and functionality. While they work a little different they accomplish the same task of authorizing users.

3.2.1.3 Encryption

Encryption is essentially built in through the available class libraries. .NET uses the Windows CryptoAPI to enable developers to make use of cryptography. These include algorithms, hashing, and signatures. The algorithms supported are public key RSA and DSA, and symmetric DES and Triple DES. These algorithms can be used with such other provided services to help fortify other built in security measures. For example using the cookie authentication mentioned above with encryption algorithms can even enhance the security of web applications. This is all accomplished using streamed data. Any streamed object (file stream) can be sent to an encryption object, which in turn can be streamed elsewhere to a network socket for example. The new direction is encryption of XML documents. The new XML digital signature (XMLDSIG) specification will allow for XML objects to be signed and encrypted for secure transportation. The .NET framework can handle several cryptographic solutions as seen above but its tie to the Windows Crypto API hurts its interoperability. Enterprise systems will comprise of heterogeneous components, which could be a cause for concern. The other concern is the protocols and algorithms for providing security are not extremely difficult to reverse engineer. This could have devastating future implications.

3.2.2 J2EE

Historically, security of Java applications was code-based. This is due to the fact that initial java programs were distributed across the Internet, i.e. applets, so measures had to be taken to ensure java code could not do anything malicious. To this end mechanisms such as code-signing, to verify the identity of the code developer and the integrity of the code, and bytecode verification, to ensure the code adheres to rules of the Java language, are utilized.

As the uses of Java migrated to the development of multi-tiered distributed application, the need to secure the resources of an application from users of the application created the need for user authentication and user authorization mechanisms. Specifically, role-based access control, whereby resources are accessed based on a users role within the application became necessary.

We will examine ways to achieve authentication and authorization declaratively and programmatically. Declarative security is enforced in J2EE through application configuration files, specifying resource constraints/permissions for users of an application. Programmatic security refers to security checks explicitly called within the application code. We will examine programmatic security as realized by the Java Authentication and Authorization Services (JAAS) API. Finally, we will examine the cryptography utilities provided through the Java Cryptography Architecture (JCA), Java Cryptography Extensions (JCE) and Java Secure Sockets Extensions (JSSE) APIs.

3.2.2.1 J2EE Application Configuration

The J2EE specification is used to develop multi-tiered distributed applications. These applications are stored within an Enterprise Archive (EAR) files. These files consists of EJB modules stored in Java Archive (JAR) files, web modules stored in Web Archive (WAR) files, application client modules stored in JAR files and deployment descriptor files [J2EE SEC]. Deployment descriptor files are XML files specifying the contents of the archive, deployment instructions and security settings. Each archive file (EAR, WAR, JAR) contain their own deployment descriptor. Figure 6 below shows an example architecture.

Figure 6. J2EE Application 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 Form-Based and HTTP authentication, cookies are often used to retain state information, similar to as in .NET.

Lastly, Certificate-Based Authentication verifies the authenticity of a user, 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.

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.

This role is for tellers

Teller

Figure 8. Teller Role defined within deployment descriptor of EAR

Once Roles have been defined, application deployers can map roles to methods within a Web Module. Within the deployment descriptor of a WAR, the security-constraint element specifies constraints on specific resources. For example, In Figure 9 below, the GET method of the Servlet associated with the relative URI /finance/account is only allowed to be called by Principals with the Teller Role.

Account servlet protected area

/finance/account

GET

Teller can access the URIs

Teller

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

[pic]

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.

[pic]

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

[pic]

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?

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 ), which contains information about published web services. Essentially this is a directory of known web services available so the client is able to know what is available. It is possible to deploy a web service without registering it in UDDI. But if you want a large number of people to make use of a service, you need UDDI so that clients can find it. An entry within a UDDI directory is simply an XML file containing information about the host and the service offered. An entry breaks down into three components. The first component describes the company offering the service: name address, etc. The second component includes categories of the web service. The third component describes the actual interface to the service with enough information to create a client application to use the web service. Services are defined through a document known as a Type Model. Generally the Type Model contains a Web Services Description Language (WSDL) file that describes a SOAP interface to the XML Web service. After contacting this server the client will receive the URL of the Web Service. After receiving the URL the client can contact the Web Service server and receive a discovery document that will enable the client to locate the service description in a WSDL file on the server. A WSDL file is an XML document that describes the SOAP messages and their format for the web service. WSDL in essence is the equivalent to IDL for CORBA. The syntax of a WSDL file is standard and programming language independent making it appropriate for describing XML Web services that can be accessed from multiple platforms. WSDL also defines the location of the service and what communications protocol is used to talk to the service. The WSDL file contains everything necessary to write a client program to make use of an XML Web service. THE UDDI and discovery document just help locate the WSDL files. Microsoft .NET is able to read a WSDL file and generate the code to communicate with an XML Web service.

Once a client knows what methods they can use and how to use them the client can actually begin to use the web service. First the client will call an available method of the Web Service by sending an XML file to the server with the SOAP message with the appropriate arguments. SOAP is a simple and flexible protocol that defines the XML format for web service messages. The server then processes the SOAP message and calls the method with the given arguments on the server. The server then takes the output of the method call and sends it back in a SOAP message where the client can process the results.

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

3.3.1.1 .NET Support

After seeing how web services actually work .NET is able to allow users to create, deploy, and use web services. has a built in 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.

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

4. Web Services Disadvantages

Web Services have the following disadvantages:

• Congestion at Port 80.

• Many competing SOAP standards.

• Difficult to encode polymorphism.

• No standard specification.

• No event services.

• Slower performance—data needs to be parsed

• WSDL files are not easy to read.

3. Interoperability

In this section we will compare the technologies in .NET, J2EE and CORBA that facilitate communication between heterogeneous applications. We are focusing on the following areas:

• Components – What classes/packages support interoperability?

• Functionality – How do applications designed for each platform typically communicate with heterogeneous/homogeneous components?

• Remote Communication – How are remote methods handled in J2EE and .NET?

3.4.1. .NET

The .NET remoting infrastructure takes an abstract view to inter-process communication. Meaning there is no focus on the underlying systems communicating just the global view of sending objects back and forth, similar to web services. The goal of a remoting system is to allow the ability to enable communication between objects in different application domains or processes, regardless of the protocols or formats being used on either side. To accomplish inter process communication there needs to be a remote object (on the server side) and applications that can listen/request the object. A remoting object is an object that can be accessed outside of its application. There are two proxies created on the client side the TransparentProxy and the RealProxy. The RealProxy is the object that transmits the method call to the server machine. The TransparentProxy is an object that contains a list of all classes, as well as the exposed methods of the remote object.

The remoting object can be used in two ways. The first way is that the remoting object is directly copied to the client side. From there the client can execute the objects methods directly on the local machine. This is a plausible method but usually not a desirable for several reasons. It will usually be the case that the client does not need all of an object’s methods. Chances are the client will only need a small subset of objects methods so copying the entire object will waste bandwidth and memory especially for large classes with lots of methods. Also the object will have private data that maybe be used by the public methods. This would allow for users to access the private data resulting in some security issues.

The second method is the method of using object references is the method that is used for remote communication. The remoting object on the server side sends a reference of the server object to the client rather than a copy of the object itself. The client sends any method calls to the server side object to be executed there and not on the local machine. The server then processes this request and uses the remoting object to execute the method on the server side. The results are then sent back to the client. In this way only the method call, the method arguments, the results, and possibly exceptions are sent to the client. This way bandwidth is used more effectively and the entire object doesn’t need to be sent just the necessary information listed above. This way also limited the exposure of the class, which is beneficial for security.

At the code level remote objects are accessed through channels. In .NET there are two existing types of channel classes HttpChannel and TcpChannel. Each one supports the protocol that their name suggests. Microsoft .NET does allow for custom channels where the coder can create a new channel type or extended a built in one like HTTP or TCP. For example making an IIOP channel would allow for interaction between .NET and CORBA orbs, which is currently not supported in .NET. As mentioned before inter-process communication requires a remote object. A remote object is any object that inherits from the class MarshalByRefObject. Not both the client and server applications must inherit from this class as well. One limitation of the inter process communication is that the data must be serializable so it can be sent across the network. This is not a problem for built in data types like String, numbers, etc. as they are serializable by design. The problem may occur in custom classes that have been created. However this problem can be resolved easily by inheriting from the ISerializable interface. Additionally including a serializable attribute in the class can do it.

The server of a remote object can also choose the duration of the object’s lifetime and activation policy using the RemotingServices.RegisterWellKnownType class. The lifetime and activation options include Single Call, Singleton, and Client Activated Objects (CAO). The Single Call option means that an object doesn’t maintain any state. This means that for every client request to the remote server object a new instance of the object is created as a result. This is the activation option for web services because the stateless nature achieves good load balancing which leads to high scalability. The Singleton objects is where the same instance of the object is used to service requests from clients. This type is used there is a need for consistency among shared data or resources for all of the clients. For example, say you wanted to maintain a hit counter that tracked the number of hits on a server resource. The third option is the notion of Client Activated Objects (CAO) where the client activates the remote object by instantiation instead of invoking a method. The client calls Activator.CreateInstance to create an object. Sending an activation message to the server where the remote object is instantiated does this. A reference is transmitted to the client. The same object on the server processes every request the client makes. This option is more like the Singleton type rather than the single call type. But the remote object is activated not at the point in time when the first method is called but rather at the point of the instance creation on the server.

Selecting the properties for a remoting object such as channel and formatter comes down to choosing the tradeoff between performance and interoperability. The .NET framework contains two serialization formatters. The binary formatter converts an object's state into a binary stream, which is a bit faster. And it also contains a SOAP formatter that converts an object into an XML string representation. An advantage of the remoting architecture in .NET is that it does not require the use a specific formatter for an explicit channel type. For example one could use the Binary formatter with the HTTP channel or use the SOAP formatter with the TCP channel or vice versa. The customizable channel and formatter architecture allows you to select channels with appropriate formatters depending on your needs and specifications

.

|HTTP Channel |TCP Channel |

|Uses the SOAP serialization formatter by default. |Uses the binary serialization formatter by default. |

|Suitable for Internet deployment and works well with firewalls. |More suitable for deployment within an internal |

| |network/LAN |

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

| |binary payload. |

|High interoperability. Channel can be used to talk to a large number of|Not as interoperable as the HTTP channel. |

|services (deployed even in disparate platforms) that can speak SOAP. | |

Source: /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 framework. The project is called . 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 has actually been completed and is downloadable at . 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.

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

The OMG has specified a CORBA Interoperability Architecture. This allows components with different implementations, such as different ORBs or distributed, non-compliant systems, to communicate. However, implementation differences may not be the only reason why two systems do no communicate. Administrative differences, such as security policies, may not permit communication [CTUT].

3.4.3.1 Domains

To aide in this problem, CORBA has defined the concept of a domain. A domain is a group of objects that for some reason do not communicate with other objects. For one domain to communicate with another, a bridging mechanism between the two domains must be defined. This mechanism potentially could handle different types of communication and therefore needs to be flexible.

3.4.3.2 Bridging

Two types of bridging are generally used. Mediated bridging occurs when at the boundary of each domain, objects are translated into a standard protocol or some other form agreed upon by the two domains. Intermediate bridging is when the objects are directly transformed from one domain to another. The full bridge is where if within one CORBA environment, all of the mediation stays within that environment. Otherwise, if the mediation differs from the standard, that is a half bridge [CTUT].

Bridges can from domains that are all within an ORB (in-line bridging) or not (request-level bridging). In-line bridging is simpler to implement, and just needs more stub and skeleton code or additional services in the ORB [CTUT].

3.4.3.3 Request-Level Bridging

Request level bridging is more interesting than in-line bridging because it deals with how CORBA interoperability occurs across different platforms. The following steps make up request-level bridging.

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

2) The DSI, using the bridge, translates the requests.

3) The DSI invokes the request through DII of the Server. Any results are passed back.

To do this, the bridge must have access to the Interface Repository, or have pre-defined knowledge of the object specifications. Also, The standard method for transferring this information is GIOP [SECP].

4. Analysis

4.1 Databases (J2EE vs. .NET)

Using the State Insurance Company’s licensing application the performance 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 anization, 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 anization, 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 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 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 , 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.

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

Throughout our research, we tried to implement a simple program on a CORBA platform. This program would simply be a “Hello World” application, and in it, a Java client would request a C++ object. However, this implementation proved to be more difficult than we anticipated.

We tried using two different implementations of CORBA: Borland Enterprise Server with Visibroker and TAO (The Ace ORB). However, both of these implementations had their problems. Visibroker lacked example documentation, but was extremely simple to install. Once installed, we had no problems creating an IDL and compiling it. We used idl2java (see appendix 7.2) We also had no problems adding functionality to the methods defined by the IDL. However, when trying to set up an ORB with a functioning object, we had problems having that object run on the server.

TAO, on the other hand, had excellent examples [TAO]. However, the installation of TAO proved to be extremely problematic, and we were not able to get it to

install on a Windows platform.

5. Conclusions

5.1 Databases (J2EE vs. .NET)

For .NET there is a detailed description of the interface. This includes the functionality, the role of XML including the benefits, and the components associated with . 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.

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 to attempt interoperability between .NET and J2EE. Unfortunately due to technical issues this was not accomplished. Either further attempts with or trying a commercial product from Borland or Microsoft would be the future direction. I tried emailing the authors of 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

[ 1] Overview of



 

[ 2] and .NET framework



[CORBA/SOAP] Web Services/SOAP and CORBA,

[CORWS] CORBA to WSDL/SOAP Interworking Specification. Object Management Group. . January 2003.

[CTUT] Brief Tutorial on CORBA. Keahey, Kate.

[JAAS] Article on JAAS



[JAX-RPC] Article on JAX-RPC



[JCA SPEC] Java Cryptography Architecture API Specification & Reference



[JDBC] JDBC Introduction

[]

[J2EE APP MODEL] J2EE Application Model

[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



[J2EE WS] Java Web Services Developer Pack 1.6 Tutorial



[.NET Intro] Includes some background info on .NET,

David S.Platt Introducing 2002 Microsoft Press Redmond, Washington.

[.NET Oracle] .NET Application Development with Oracle,



[.NET Report] Previous semester report,

[.NET Web] Includes Web Services and Database information,

Bob Willer Developing XML Web Services and server components with Microsoft Visual and C#.NET Redmond, WA Microsoft Press 2003.

[.NET remoting1] Remoting Source Code,



[.NET remoting2] .NET Remoting Classes



[.NET remoting3] .NET Remoting Information



[] project web page



[.NET authorization] Authorization and Authentication Code,



[.NET encryption] Microsoft documentation on Crypto API



[.NET security] CSE Middleware Security paper,



[.NET security] Article discussing .NET Security



[.NET interoperability] .NET and Java interoperability



[OMG] Getting Started with CORBA



[OMGS] OMG Security. Object Management Group. . May 2005

[ORB] ORB Basics. Object Management Group. . May 2005.

[RMI] Java RMI Specification



[SECP] SECP Revised Submission. Objective Interface Systems, Inc. . June 2004

[SSS] Security Service Specification. Object Management Group. . March 2002.

[TAO] Distributed Object Computing with CORBA Middleware, Schmidt, Douglas, . June 2005.

[VOGEL] Java Programming with CORBA. Vogel, Andreas. John Wiley & Sons, Inc. February 1998.

7. Appendices

7.1 architecture

7.2 CORBA IDL

The following is an example of a CORBA IDL [VOGEL].

   module helloWorld { 

      interface  GoodDay  { 

      string  hello(); 

   };

};};}; 

7.3 .NET Remoting

7.3.1 Server

 

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

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

//

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

//

//------------------------------------------------------------------------------

//

// 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 ponentModel;

using System.Web.Services;

///

[System.Diagnostics.DebuggerStepThroughAttribute()]

[ponentModel.DesignerCategoryAttribute("code")]

[System.Web.Services.WebServiceBindingAttribute(Name="StockQuotesSoap", Namespace="")]

public class StockQuotes :

System.Web.Services.Protocols.SoapHttpClientProtocol {

///

public StockQuotes() {

this.Url = "";

}

///

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("",

RequestNamespace="", ResponseNamespace="",

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]));

}

///

public System.IAsyncResult BeginGetQuotes(string symbols,

System.AsyncCallback callback, object asyncState) {

return this.BeginInvoke("GetQuotes", new object[] {

symbols}, callback, asyncState);

}

///

public System.Xml.XmlNode EndGetQuotes(System.IAsyncResult

asyncResult) {

object[] results = this.EndInvoke(asyncResult);

return ((System.Xml.XmlNode)(results[0]));

}

/// [System.Web.Services.Protocols.SoapDocumentMethodAttribute("",

RequestNamespace="", ResponseNamespace="",

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]));

}

///

public System.IAsyncResult

BeginGetMarketIndex(System.AsyncCallback callback, object asyncState) {

return this.BeginInvoke("GetMarketIndex", new object[0],

callback, asyncState);

}

///

public System.Xml.XmlNode EndGetMarketIndex(System.IAsyncResult

asyncResult) {

object[] results = this.EndInvoke(asyncResult);

return ((System.Xml.XmlNode)(results[0]));

}

///

System.Web.Services.Protocols.SoapDocumentMethodAttribute("",

RequestNamespace="", ResponseNamespace="",

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]));

}

///

public System.IAsyncResult BeginGetECNQuotes(string symbols,

System.AsyncCallback callback, object asyncState) {

return this.BeginInvoke("GetECNQuotes", new object[] {

symbols}, callback, asyncState);

}

///

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");

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");

}

}

6. Database Connectivity

1. .NET

private void Form1_Load(object sender, System.EventArgs e)

{

//odbcDataAdapter1.mandText= "SELECT Lic_License_Number, Org_Name,Lic_Class, Lic_Status,Lic_Cancel_Date,Lic_License_Date,Org_TIN,Org_Status

FROM anization,csg.License WHERE Org_Tin=Lic_Tin and

Lic_Tin_Type = 'O' and lower(Org_Name) like '%a%'";

oleDbDataAdapter1.mandText = "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");

}

}

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. J2EE Security

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;

/**

*

* 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);

}

}

}

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;

/**

*

* 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);

}

}

}

3. jaas.config

MyExample {

RdbmsLoginModule required

driver = "sun.jdbc.odbc.JdbcOdbcDriver"

url = "jdbc:odbc:testdb"

debug = "false";

};

8. RMI

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;

}

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();

}

}

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);

}

}

}

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.

-----------------------

LoginModules

RDBMS, ERP,

Legacy Apps

EJB Server, JNDI,

JMS, JavaMail

Web Application Servers:

JSP, Servlets, HTML, XML

Enterprise Information Server

Middle Tier

Client Side

RdbmsLoginModule

JNDILoginModule

RDBMS

LDAP Server

NT Authentication

Kerberos Authentication

Biometric Authentication

LoginContext

Application

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download