Daniel Bernholc

TRITA-NA-E04007

An Evaluation of Application Server Techniques

NADA

Numerisk analys och datalogi Department of Numerical AnalysisKTH and Computer Science100 44 Stockholm Royal Institute of Technology

SE-100 44 Stockholm, Sweden

Daniel Bernholc

TRITA-NA-E04007

Master’s Thesis in Computer Science (20 credits)at the School of Mechanical Engineering,Royal Institute of Technology year 2004Supervisor at Nada was Tommy Palm

Examiner was Stefan Arnborg

An Evaluation of Application Server Techniques

Abstract This report, An Evaluation of Application Server Techniques, treats two contemporary techniques; J2EE and .NET. J2EE is short for Java 2 Enterprise Edition and is a standard describing what services a J2EE certified server has to offer. .NET can be described in two ways, either as a software platform or a framework for developing .NET applications. In this report both techniques are described in the sense that it is pointed out what services they provide and how these services are used. The techniques were compared ‘head to head’ by service and specific features and pieces of code are shown to provide an understanding for how each service is used in both techniques. To further compare the two techniques a small application was developed for both a J2EE server and .NET. The purpose of implementing this application was to test how the techniques would cope with distributed transactions and also to get some performance metrics. The conclusion of the work with this report was, of course, not that J2EE was better than .NET or the other way around. Rather it was found that it is important to know the main properties of the desired application. What services will this application be providing? Is it probable that the application will grow in size in terms of users taking advantage of it? Will the development of the application be an ongoing process or will it be a finalized product? There are many questions that need answers before deciding which technique is the most suitable to meet the demands of the particular application. Not only the properties of the application need to be taken into account, it is also of great importance what types of resources are to be used in terms of labor, hardware and software tools. Perhaps the party about to develop an application already has a rack of Sun machines and 15 Java gurus employed? In a case like this it is obvious to choose a server based on the J2EE standard even though the application itself may be more suited for a .NET environment. One general conclusion has been drawn; .NET is often better fitted for web centric applications while J2EE can be preferred for applications where more logic resides on the application tier.

En utvärdering av applikationsservertekniker - Sammanfattning Denna rapport, En utvärdering av applikationsservertekniker, behandlar två aktuella tekniker, J2EE och .NET. J2EE är en förkortning av Java 2 Enterprise Edition och är en standard som beskriver vilka tjänster en J2EE-certifierad server måste tilhandahålla. .NET kan beskrivas på två olika sätt, antingen som en mjukvaruplattform eller som ett ramverk för att utveckla .NET-applikationer. I den här rapporten beskrivs båda teknikerna i bemärkelsen att den pekar ut de tjänster de erbjuder samt hur dessa tjänster används. Teknikerna har jämförts grundligt för varje tjänst och speciella egenskaper och kodavsnitt har tagits fram för att förmedla ett förstående för hur varje tjänst används i båda teknikerna. För att ytterligare jämföra teknikerna utvecklades en liten applikation för både J2EE och .NET. Syftet med implementeringen av applikationen var att testa hur teknikerna hanterade distribuerade transaktioner samt att få fram prestandadata. Slutsatsen av arbetet med denna rapport blev givetvis inte J2EE var bättre än .NET eller tvärt om. Snarare upptäcktes det att det är viktigt att veta vilka de huvudsakliga egenskaperna hos den önskvärda applikationen är. Vilka tjänster ska applikationen tillhandahålla? Är det sannolikt att antalet användare som utnyttjar applikationen kommer att växa? Kommer utvecklingen av applikationen att vara en pågående process eller en mynna ut i en slutgiltig produkt? Många frågor måste besvaras innan det är möjligt att avgöra vilken teknik som är den lämpade. Det räcker inte att bara ta applikationens egenskaper i beaktande, utan även behovet av resurser i bemärkelsen arbetskraft, hårdvara och mjukvaruverktyg måste beaktas. Kanske har gruppen som är på väg att utveckla en applikation ett skåp Sun-maskiner och 15 javautvecklare anställda? I ett sådant fall är det uppenbart bäst att välja J2EE även om själva applikationen egentligen är bättre anpassad för en .NET-miljö. En generell slutsats har dragits; .NET är ofta bättre anpassad för applikationer där merparten av logiken ligger i webblagret medan J2EE kan föredras när logiken är mer koncentrerad i applikationslagret.

1 Introduction.................................................................................................................... 1 2 Background .................................................................................................................... 2

2.1 System Architectures .............................................................................................. 2 2.1.1 Single-tier architecture.................................................................................. 2 2.1.2 Two-Tier Architecture .................................................................................. 2

2.1.2.1 Client/Server Architecture................................................................... 3 2.1.3 Three-Tier Architecture ................................................................................ 3 2.1.4 n-Tier Architecture ....................................................................................... 3

2.2 Distributed Objects ................................................................................................. 3 2.2.1 What are distributed objects?........................................................................ 4 2.2.2 How is a distributed object used? ................................................................. 4

3 J2EE ................................................................................................................................ 6 3.1 Services................................................................................................................... 6

3.1.1 HTTP and HTTPS ........................................................................................ 7 3.1.1.1 Servlets................................................................................................ 7 3.1.1.2 JSP....................................................................................................... 7

3.1.2 JTA ............................................................................................................... 7 3.1.3 RMI-IIOP and Java IDL ............................................................................... 8 3.1.4 JDBC............................................................................................................. 8 3.1.5 JMS............................................................................................................... 8 3.1.6 JNDI.............................................................................................................. 9 3.1.7 JavaMail and JAF ......................................................................................... 9 3.1.8 JAXP ............................................................................................................. 9 3.1.9 J2EE Connector Architecture ....................................................................... 9 3.1.10 JAAS ......................................................................................................... 10

3.2 Multitier Model .................................................................................................... 10 3.2.1 Business Tier .............................................................................................. 11

3.2.1.1 Enterprise JavaBeans (EJB) .............................................................. 11 3.2.1.2 What is an EJB? ................................................................................ 12 3.2.1.3 Why use EJBs?.................................................................................. 12 3.2.1.4 EJB Types ......................................................................................... 12

3.2.1.4.1 Entity Beans ............................................................................. 13 3.2.1.4.2 Session Beans .......................................................................... 14 3.2.1.4.3 Message Driven Beans ............................................................ 15

3.2.2 Web Tier ............................................................................................................ 15 3.2.2.1 Web Tier Architecture ............................................................................. 15

4 .NET .............................................................................................................................. 17 4.1 What is .NET? ...................................................................................................... 17 4.2 The .NET Framework........................................................................................... 17

4.2.1 The Common Language Runtime (CLR) ................................................... 18 4.2.2 Application Development Technologies .................................................... 18

4.2.2.1 Web Services ..................................................................................... 18 4.2.2.2 Windows Forms ................................................................................ 19 4.2.2.3 ASP.NET........................................................................................... 19

4.2.3 Class Libraries ............................................................................................ 20

4.3 Other Services ...................................................................................................... 20 4.3.1 Transactions ................................................................................................ 20 4.3.2 Security....................................................................................................... 20 4.3.3 Database Connectivity................................................................................ 21 4.3.4 System Architecture.................................................................................... 21

5 Comparison of .NET vs. J2EE .................................................................................... 23 5.1 Overall comparison .............................................................................................. 23 5.2 General Architecture ............................................................................................ 24 5.3 Service-by-Service comparison............................................................................ 26

5.3.1 JSP – ASPX ................................................................................................ 26 5.3.2 JDBC – ADO.NET ..................................................................................... 28 5.3.3 JTA – MTS ................................................................................................. 30 5.3.4 JAXP, JNDI, RMI– Web Services ............................................................. 30 5.3.5 JMS – (system.messaging namespace, .NET class library) ........................ 32 5.3.6 JavaMail – (system.web.mail namespace, .NET class library) .................. 33 5.3.7 JAAS – (system.security namespace, .NET class library) .......................... 33

5.4 Development and Development Tools ................................................................. 33 5.5 Environment ......................................................................................................... 34 5.6 Application Monitoring ........................................................................................ 34 5.7 Performance.......................................................................................................... 35 5.8 Future.................................................................................................................... 35

6 Test: J2EE distributed EJB’s vs. .NET Web Services.............................................. 36 6.1 Purpose of test application.................................................................................... 36 6.2 Tools ..................................................................................................................... 36 6.3 Application set up ................................................................................................. 37 6.4 Client set up .......................................................................................................... 37 6.5 Communication between client and server........................................................... 38 6.6 Implementation of test.......................................................................................... 39 6.7 Transactions .......................................................................................................... 40 6.8 Description of Test ............................................................................................... 40 6.9 Conclusion............................................................................................................ 41

7 Conclusions ................................................................................................................... 42 7.1 Personal opinions and findings............................................................................. 42 7.2 Progress of the work ............................................................................................. 43 7.3 Thanks to… .......................................................................................................... 43

8 Bibliography ................................................................................................................. 44

1

1 Introduction This report was written as a thesis for a master of engineering degree. It was commissioned by NADA and TradeDoubler AB. The intention of this report is to provide readers with overview information as well as information from a technical point of view on application server techniques. The intended audience is anyone with an interest in application server techniques. Those who already possess a deeper knowledge of J2EE and/or .NET may skip the background and descriptive parts as they are intended for those who have no or a somewhat limited knowledge in these areas. The main part of interest of this report is the comparison between J2EE and .NET, two different but yet similar application server techniques. The report can be used for guidance when in the process of selecting an appropriate technique for a certain project. Even if the particular technique of interest is not discussed in this report it could be worth going through the report as it could give some help in what to think about when trying to select an appropriate technique. The report has been divided into eight chapters:

1 Introduction – short description of what the report is about. 2 Background – gives some background from a historical point of view of the

development enterprise application architecture. 3 J2EE – describes the Java 2 Enterprise Edition platform. 4 .NET – describes the Microsoft .NET platform 5 Comparison of .NET vs. J2EE – comparison of the two platforms from different

perspectives. 6 Test: J2EE distributed EJB’s vs. .NET Web Services – test of implementation and

performance. 7 Conclusion – A review of the results achieved. 8 Bibliography

2

2 Background This part provides some background and history to better understand the use of and need for application server techniques. First a little information about different system architectures and how they have evolved through time is presented, then follow a few points about distributed objects, which are central parts of application servers.

2.1 System Architectures This section describes a few types of system architectures. The purpose is to provide some information about alternative techniques not covered in this report.

2.1.1 Single-tier architecture The single-tier architecture is based on a mainframe computer with terminals connected to it. The terminal is basically nothing but a screen, a keyboard and a connection to the mainframe. All logic concerning user interface, business logic and storing of data is based on the mainframe. The terminal is merely a port to view and manipulate data. This approach is still in use, but no new systems are built this way. Some mainframes have become legacy systems of multi-tier architectures. The main advantage of single-tier architecture is that all code is stored and run from a single location. However, the disadvantages – slow display performance, expensive mainframes and unattractive user interfaces – outweigh the advantages in many cases. This kind of architecture was the only one available during the 1960s and 1970s. When the first personal computers entered the market in the 1980s this technique started to slowly fade away. However, the personal computer is also a type of single-tier architecture as long as it is not connected to any server. The problem with this architecture was that information was scattered in thousands of places in the corporate landscape and the information soon became inconsistent. This called for a new type of architecture, namely the client/server architecture.

2.1.2 Two -Tier Architecture This type of architecture consists of two parts: a client workstation and a server. The code for the user interface resides on the workstation while business logic and the storing of data are handled by the server. This model often provides a good user interface and improved display performance. The downside is difficulty to scale the system. Usually this is done by simply adding more users to a server, but as the number of users grows performance drops and eventually this result in frequent system crashes. This technique was very common in the early days of the Internet breakthrough. In fact, many simple web applications still use this technique.

3

2.1.2.1 Client/Server Architecture As more people gained access to personal computers in the 1980s information became decentralized as everyone had information stored on their own computer. In many cases there were needs to have some information store where data could be accessed from anywhere. The answer to this problem was the client/server architecture. This model is a variation of the two-tier architecture as it also contains a client workstation and a server. It differs in such a way that the business logic is shared by the workstation and the server. In fact, most often the major part of the business logic runs at the client. This solution offers better performance than the original two-tier solution, but on the other hand it makes it more difficult to upgrade business logic as not only the server needs to be updated, but also the client. A simple software upgrade might cause thousands of clients not to function properly since they have not obtained the last upgrade, which might be necessary to interact with the server.

2.1.3 Three-Tier Architecture The three-tier architecture contains a client workstation, an application server and a data storing facility. The user interface is located on the client, the business logic resides on the application server and the data itself is most commonly stored in a database. Since the important business logic is stored in one place it is easy to manage. The user interface is handled by the client, which gives the same good performance as the client/server architecture offers.

2.1.4 n-Tier Architecture As in the case of three-tier architecture the user interface runs on the client, the business logic on the application server and the data is stored in databases. The difference is that the business tier is divided into different layers. A common division is a presentation layer, a business logic layer and a data layer, but there could be fewer or more layers, hence the name, n-tier. An example of an n-tier application is shown in figure 2 on page 20.

2.2 Distributed Objects Distributed objects have a key part in the techniques this report describes. The intention with this section is to answer some important questions about distributed objects.

4

2.2.1 What are distributed objects? The following quote gives a somewhat technical explanation to the question “what are distributed objects?”. “A distributed object is a piece of code that can live anywhere on a network. They are packaged as independent pieces of code, which can be accessed by remote clients via method invocations. The language and compiler that are used to create distributed objects are transparent to their clients. Clients do not have to know where on the network, a distributed object resides, or what machine it is on, whether it is the same machine or another. It can be executed on a totally different operating system. Distributed objects are therefore able to message each other anywhere in the world.” (Asaipillai, 2002) The relationship between a client and a distributed object is shown in figure 1.

Figure 1 – Distributed object

2.2.2 How is a distributed object used? A distributed object can be pictured as a software entity that performs a particular task. The object could perform a simple task such as returning some data or perhaps execute some rather complicated calculations.

5

An example of how a distributed object could be used: Company A has an online store selling toys. They have all functionality necessary to process an order but the ability to validate the customer's credit card. Instead they are paying Company B to accomplish this task. Company B is specialized in performing such tasks for their clients. So, when a client orders a product from company A, the credit card information is sent over a secure line to company B. The credit card information is processed and validated and a response containing the result of the validation is sent back to company A where the customer's order proceeds if the result of the validation was positive and is disrupted if the result was negative. On a more technical level the answers to two questions are needed: How does a client connect to a distributed object? And, how does the client use the services it provides? First of all a clarification of the term “client”: a client could be anything that takes advantage of the services the distributed object provides. It could, for example, be an applet, an application or another distributed object. Basically three things are necessary to be able connect to and use the services of a distributed object. For the connection an address to the network where the object is hosted is needed. To be able to connect to the server also some authorization information may be needed. A username and password are often sufficient. Now, to use the services of the object some kind of interface is necessary. This interface is a list of the methods the object provides and the input and output parameters of those methods.

6

3 J2EE Java 2 Enterprise Edition is a specification for implementing and deploying enterprise applications. It specifies what services J2EE enterprise application servers have to provide. This part of the report explains what J2EE is, what services it includes and what tools these services provide the developer with. Furthermore the business tier with Enterprise JavaBeans and the web tier with Java ServerPages and Servlets are discussed.

3.1 Services When the J2EE specification was written the main concern was to provide a framework for services that were reliable, scalable, secure and highly available. The platform was designed through an open project in cooperation with some enterprise application systems vendors. The result was a specification addressing the core issues of enterprise applications and the services these require to function as enterprise platforms. The set of required services necessary to acknowledge a J2EE application server is listed below with a short description of what service(s) they provide. (Bill Shannon, 2001)

• HTTP - Java Servlets and Java ServerPages (JSP) • HTTPS - HTTP protocol over the Secure Socket Layer (SSL), other than that

same as HTTP. • Java Transaction API (JTA) - Provides support for managing and coordinating

transactions. • RMI-IIOP - Allows for programming independent of underlying protocol. • Java IDL - Allows J2EE application components to invoke external CORBA

objects using the IIOP protocol. • JDBC API - Allows Connectivity with relational database systems. • Java Message Service (JMS) - Provides a way to asynchronously send and receive

messages. • Java Naming and Directory Interface (JNDI) - Interface used by application

components to access and to provide naming and directory services. • JavaMail - Allows an application component to send Internet mail. • JavaBeans Activation Framework (JAF) - The JavaMail API uses the JAF API, so

it must be included as well. • Java™ API for XML Parsing (JAXP) - Provides support for the industry standard

SAX and DOM APIs for parsing XML documents. • J2EE™ Connector Architecture - Allows resource adapters that support access to

Enterprise Information Systems to be plugged in. • Java™ Authentication and Authorization Service (JAAS) - Enables services to

authenticate and enforce access controls upon users.

7

Vendors producing J2EE products are required to include the services listed above. However, the specification does not restrict inclusion of additional services in J2EE products. If all vendors were to include only the services specified, portability of code between different vendors’ products would be good. Also, the party taking advantage of J2EE products would not be dependent of a specific vendor. Of course it is possible for the developer to code in such way that vendor specific services are omitted and thus making the code portable between different J2EE servers. The disadvantage is that many useful services the vendor specific products provide would be lost. Some of these services would be very time consuming and costly to develop or would have to be acquired from a third party.

3.1.1 HTTP and HTTPS The HTTP and HTTPS are two protocols providing the same service with the only difference that HTTPS does it over a secure protocol.

3.1.1.1 Servlets

A servlet is a java class specialized for web access. A servlet can be called directly from a web browser and respond with, for example, HTML, PDF or images. However, mostly servlets are used to process request from JSP pages and pass them on to the underlying application. The reverse applies to responses.

3.1.1.2 JSP

Mixing of content and presentation logic is not very desirable as often the web designer and programmers possess different knowledge. Java ServerPages provide a good solution of avoiding this problem. They allow the web designer to develop pages in HTML with a minimum of logic for dynamic content processing. Often the web designers are provided with JavaBeans components and custom tags for adding dynamic content to JSP pages. The first time a JSP page is called it is compiled into a servlet. This is nothing that the developer needs to take into account as the web container does it all automatically.

3.1.2 JTA The Java Transaction API is used for transaction management in Java. In J2EE applications it may be used in two different ways. Either it can be used inside the code by the developer to manually demarcated transaction boundaries or it can be specified in the property files of the Enterprise JavaBeans how transactions should be supported. Each

8

bean or even method of a bean may have individual specification on how to handle transaction support. The four support levels are:

• Not Supported –not included in any transactions. • Supported – will be included in existing transactions. • Required – will be included in existing transactions. If a transaction does not yet

exist, a new one is started. • Requires New – always starts a new transaction.

The Enterprise JavaBean specification defines three different approaches to manage transactions:

• Client-managed transactions – client explicitly handles the transaction boundaries. • Container-managed transactions – the EJB container handles transactions. • Bean-managed transactions – the EJBs explicitly control transactions.

3.1.3 RMI-IIOP and Java IDL Remote Method Invocation over Internet Inter-Orb Protocol gives J2EE the distributed computing capabilities of CORBA. Developers can write remote interfaces in Java and then implement these in another language, as long as this language is supported by a mapping. In a similar manner clients may be coded in a different language than Java if they use the Java Interface Definition Language.

3.1.4 JDBC Java Database Connectivity allows application servers to work with database manager systems (DBMS) by establishing a connection and then manipulating data by creating, updating, retrieving or deleting operations. To be able to use the capabilities of the JDBC API a driver to get a bridge to the DBMS is necessary. Usually the DBMS vendors provide drivers. Some drivers for the more common DBMS’s are often included with J2EE servers.

3.1.5 JMS The Java Messaging System supports two different messaging models:

• publish-subscribe messaging • point-to-point messaging

The publish-subscribe model uses so called topics. The publishers send messages to a certain topic and all those subscribing to the specific topic will receive the message. This model can be used when a group of applications are working together.

9

The point-to-point involved message queues. The senders send their messages to a queue and the receiver picks up those messages from the queue when it is ready. When different processes in a system communicate with each other this model is often used. One of the features of JMS is that connection factories are used to create connections to a specific JMS provider. Another feature is that JMS provides support for distributed transactions.

3.1.6 JNDI For a distributed application to work it needs a way to find out where the different objects are located and how they are accessed. The Java Naming and Directory Interface is used to create a binding between a certain name and an object. Then the object can be found in a distributed environment by looking it up by its name with JNDI.

3.1.7 JavaMail and JAF The JavaMail API is a set of classes that allows an application to perform the following functions:

• create a message • create a session object used for authentication and access control of the message

store • send messages • retrieve messages from the message store

The JavaBeans Activation Framework is used by JavaMail for a few different purposes including containing the data of the message and viewing and printing a message.

3.1.8 JAXP The Java API for XML Parsing enables applications to parse and convert XML documents. JAXP is a key part of Java Web Services. One of the features of JAXP is the possibility to use different XML processors without having to do any changes to the code.

3.1.9 J2EE Connector Architecture This service allows different types of Enterprise Information Systems (EIS) such as legacy systems, mainframe databases and transaction processing systems to be integrated with the J2EE application server. The J2EE Connector Architecture offers resource adapters working between the J2EE application server and the EIS with three different system contracts; connection management, transaction management and security management.

10

3.1.10 JAAS The J2EE platform provides the service Java Authentication and Authorization Service, which has a few different authentication mechanisms.

• Basic authentication – the web server authenticates a user or a program by obtaining the credentials, usually user name and password, from the web client.

• Digest authentication – the same as basic authentication but with password encryption.

• Form-based authentication – the web container provides an application specific form for logging on.

• Certificate authentication – the client uses a public key to provide its identity.

3.2 Multitier Model J2EE has been designed to run on multitiered systems. The J2EE model defines a client tier, a middle tier and an enterprise information system (EIS). The client tier usually provides the user with a graphical interface. This could be done as a separate client application or perhaps as a web browser. In some cases, for example, another J2EE application server could function as a client taking advantage of the services provided by this application, although this scenario might as well be considered as the other server uses the first one as a type of legacy system. The Enterprise Information Store (EIS) most commonly is a database system. This is where all the data is stored. J2EE is the foundation for the middle tier in this three-tier architecture. The middle tier consists of sub tiers. The business tier is the main tier. In addition there could also be a web tier in systems with that design Figure.2. These tiers run inside, so called, containers. A Container is a runtime environment providing specific services. For example, the web container provides the HTTP and the HTTPS services. The business tier containing the Enterprise JavaBean (EJB) container provides services such as JDBC, JTA and JNDI. The containers also provide mechanisms for configuring application behaviour during assembly and deployment time. Features that can be configured are for example security checks and transaction management. (Nicholas Kassem, 2000)

11

Figure 2 – J2EE tier architecture

3.2.1 Business Tier The business tier is where the application logic resides. This tier is also called application tier or middle tier depending on what literature is read, but all refer to the same tier.

3.2.1.1 Enterprise JavaBeans (EJB) “Enterprise beans are the J2EE™ components that implement Enterprise JavaBeans™ (EJB™) technology. Enterprise beans run in the EJB container, a runtime environment within the J2EE server. Although transparent to the application developer, the EJB container provides system-level services such as transactions to its enterprise beans. These services enable you to quickly build and deploy enterprise beans, which form the core of transactional J2EE applications.” (Monica Pawlan, 2002) The intended purpose of the following text is to give a somewhat deeper insight into the concept of Enterprise JavaBeans.

12

3.2.1.2 What is an EJB? An EJB is a server-side component written in Java. It contains the business logic of an application. Remote clients can access the business logic by invoking the methods of an EJB. It consists of three parts; the bean class, a home interface and remote interface. In addition, a configuration file is needed. The bean class contains the implementation of the business methods. There are some methods that are required and have to follow certain syntax. Other than these, the developer adds own business methods. The remote interface defines the business methods implemented in the bean class. The home interface defines the bean’s life cycle methods, such as create, and remove. The configuration file is written in the eXtensible Markup Language (XML). This file may contain configurations for many beans. This is where the specifications for how a bean uses the services provided by the EJB container reside. In some application servers the vendor has included services outside the scope of the J2EE specification. In these cases a second configuration file is need to specify how a bean should take advantage of these services.

3.2.1.3 Why use EJBs?

• EJBs provide application developers with a simpler way of writing complicated applications. Since the EJB container provides system-level services transparently, the developer may concentrate on writing business logic code instead of having to spend much time on, amongst other things, transaction management code or security checks.

• All application logic is gathered in the beans. This allows the client part of the

application to contain nothing but presentation logic.

• Enterprise beans are portable components. The same bean may be used as part of many different applications.

• Since beans can be distributed across multiple machines and the location where

the actual bean resides is transparent to the client it is easy to add new hardware when the number of clients grows. In other words, beans provide good scalability.

3.2.1.4 EJB Types There are three kinds of EJBs: entity beans, session beans and message driven beans. Each of these bean types has a different purpose. Session beans are intended to perform tasks for a client. An entity bean represents a data object existing in persistent storage. An easy way of thinking about this is that an entity bean represents a table row in a database.

13

This is not always true, but is the general case. A message driven bean acts as a listener for the Java Messaging System (JMS).

3.2.1.4.1 Entity Beans An entity bean reflects a business object. Consider a person creating a user account at some web site. This user has attributes like name, age, address, primary language amongst others. All these attributes are present in a database table called USER (table 1). Each row in this table holds the data for one user. Each instance of the entity bean UserBean (figure 3) represents one row from the table USER. UserBean provides methods for creating, retrieving, updating and deleting data for a user. An entity bean is a persistent object. If the application is stopped and started again the bean instance will be recreated when called, just as it was before the application was stopped. This means that as long as the database is intact the bean can survive a system crash or a stop for application maintenance. An entity bean can have one of two different types of persistence, bean-managed or container-managed. With Bean-Managed Persistence (BMP) the developer is responsible for writing code for database access. With Container-Managed Persistence (CMP) the container automatically provides database access. The developer specifies the SQL statement the container should use in a configuration file. (Ed Roman, 1999) As the EJB container provides transaction management the access to entity beans can be shared. If two clients are manipulating the same data simultaneously the transaction will fail and the update will be lost but the data will remain consistent. This requires the database table to have a timestamp field.

USER

Column name Type Note UserId Int For easier identifying of a user LastChanged timestamp For transactions, shared access FirstName varchar LastName varchar BirthDate Date Address1 varchar Address2 varchar City varchar ZipCode varchar Country varchar PrimaryLanguage varchar

Table 1 – database table USER

14

3.2.1.4.2 Session Beans The client does not usually interact directly with an entity bean. Instead, the entity beans are wrapped in session beans. Session beans provide methods for modifying data held by entity bean instances. These methods are often more ‘business like’ than the update/retrieve methods provided by entity beans. Imagine a session bean, UserManagerBean (figure 3). This bean provides a method userHasMoved taking the address, city, zip code and country as input parameters. It finds out what the primary language is in the new country, finds the instances of the entity bean, UserBean, corresponding to the user and invokes UserBean’s update methods. There are two types of session beans, stateful and stateless. Stateful session beans maintain a conversational state during a client interaction. The client keeps a conversation with the same bean instance during a session. Stateless beans are used by clients for single method invocations. The same instance of a stateless session bean could be called by chance, but the client would have no chance of knowing it is the same instance and thus would not know what values it contains. It should never be assumed that a stateless bean holds values between calls. Stateless beans are usually kept in a pool. This pool contains a configurable number of beans, for example, one hundred beans. When a client calls a bean in the EJB container, a bean instance is selected at random from the pool to perform the tasks assigned by the client. UserManagerBean is stateless.

Figure 3 - Example of User

15

3.2.1.4.3 Message Driven Beans Message driven beans have a different architecture than session and entity beans. This kind of enterprise bean is not accessed by interfaces as it only has a bean class. The beans act as listeners for JMS. They allow the application to process messages asynchronously. In many ways, the message driven beans are similar to stateless session beans. They retain no state in between calls, the instances can be placed in a pool and a single instance can be used to process messages from multiple clients.

3.2.2 Web Tier By definition a web application is a collection of HTML/XML documents, servlets, JSP pages and perhaps some other resources. The web container is the runtime environment for a web application. It provides Servlets and JSP pages with a naming context and life cycle management.

3.2.2.1 Web Tier Architecture There are many ways to architect a web application. Below, a few different alternatives are presented. Be aware that these are not the only possibilities, but merely a selection of design patterns chosen to provide a basic understanding of possible architectures of the web tier. Servlet only – The presentation logic and content are mixed.

Figure 4 – Servlet only

JSP only - The presentation logic and content are mixed.

Figure 5 – JSP only

16

JSP and JavaBean – The presentation logic resides in the JSP and the JavaBean generates the content. The interaction between the JSP and the JavaBean is handled by set and get methods implemented in the JavaBean.

Figure 6 – JSP and JavaBean

Servlet and JSP - The presentation logic resides in the JSP and the content is generated by the servlet. The servlet sends the response to a JSP, which passes it on to the client who posted the request. This design has many different servlets as part of the application. Figure 7 also applies to a design pattern with only one servlet for the entire application. In the previous examples servlets and JSPs have been specialized and thus many servlets/JSPs are required. This pattern is called “front controller” and is recommended by SUN as best practice. It works almost the same as explained above with the exception that a very general servlet only forwards the requests without handling any presentation logic at all.

Figure 7 – Servlet and JSP

17

4 .NET This section first gives an overview to what .NET is. Then it is explained what parts are included in the .NET framework such as the Common Language Runtime and ASP.NET. It is also described what services the different parts provide and how these services are used.

4.1 What is .NET? There are many different suggestions to what .NET really is. Depending on what literature is read, a completely different explanation may be found. Beneath, follows a quote that gives a summarized answer to the question. “.NET is a “software platform”. It is a language-neutral environment for writing programs that can easily and securely interoperate. Rather than targeting a particular hardware/OS combination, programs will instead target .NET, and will run wherever .NET is implemented. .NET is also the collective name given to various bits of software built upon the .NET platform. These will be both products (Visual Studio.NET and Windows.NET Server, for instance) and services (like Passport, HailStorm, and so on). The components that make up .NET-the-platform are collectively called the .NET Framework.” (Bright 2002) The development of applications can be divided into three parts; web tier, middle tier and data tier. The web tier is the presentation layer and written in ASP.NET. The middle tier is coded in one of four languages; C++, C#, VB.NET or Jscript.NET. Different parts of the middle tier can be coded in different languages.

4.2 The .NET Framework One of the cornerstones of .NET is the .NET Framework. The .NET Framework provides an environment for developing applications. It can be divided into four parts:

• Common Language Runtime (CLR) - Runtime environment • Application Development Technologies - ASP.NET, Windows Forms, Web

Services • Class Libraries - data access, XML support, directory services, regular

expressions etc. • Base Class Libraries - collections, thread support, code generation, IO, security

etc.

18

4.2.1 The Common Language Runtime (CLR) When an application developer writes a piece of code and compiles it, the compiler translates the code into an Intermediate Language (IL). The IL is not machine code and not like Java byte code, rather, it is a language that is compiled, converted into machine code and then executed. In addition to IL compilers emit metadata describing the data types used and version information. The generated code is considered to be managed code. Unmanaged code is code that is not compiled into IL and does not carry the extra metadata. This code can run under the CLR but the CLR cannot guarantee safe execution as in the case for managed code. Services provided by the CLR are garbage collection, code verification and code access security. With the first version of .NET there are four languages that can be compiled into managed code; VB.NET, Jscript.NET, C# and MC++. VB.NET and Jscript.NET have evolved from VB and Jscript respectively. C# (pronounced C-sharp) is an entirely new language optimised for the development of .NET applications. MC++ (managed C++) is the same as C++. (The separation is made because C++ can be executed as unmanaged code as well.)

4.2.2 Application Development Technologies There are three technologies for developing applications in .NET. Each technology has its own purpose. ASP.NET is used to develop web pages with dynamical content. Windows Forms is a technology used to produce applications for the windows platform with graphical user interfaces. Web Services provide remote, platform independent services to various clients.

4.2.2.1 Web Services A Web Service is an application that is able to provide some sort of service remotely. The application usually provides some simple service such as authentication of a user or validation of a credit card but really could provide almost any imaginable service. A Web Service can be coded in any language supported by the CLR. Basically it is a class like any other with the exception that the class and some methods are declared as web service and web methods respectively. With the declaration of a web service it is also possible to declare some properties (Juval Löwy, 2001 and Richard Andersson, Brian Franc is, Alex Homer, Rob Howard, Dave Sussman, Karli Watson, 2001):

• Name – the name the Web Service is referred by. • Description – a description of the Web Service. • Namespace – the default namespace for the Web Service.

19

Each web method may also have a set of properties specified:

• BufferResponse - specifies whether the response should be buffered. • CacheDuration - the number of seconds the response should be stored in

cache. • Description - a description of the web method. • EnableSession - specifies whether session state is enabled. • MessageName - the name used for the Web method • TransactionOption - specifies the transaction support. Currently the only

two options that work the way they are supposed to are RequiresNew and NotSupported.

When a Web Service has been developed it is registered in a universal directory for web services according to the Universal Description, Discovery, and Integration (UDDI) specification. When another party need some service they can check this directory to see if a service of the kind they need is available, if so, they may take advantage of that service. Before a Web Service can be integrated in the application a proxy object on the client side needs to be created. Using a command line tool or VS.NET the proxy object and a file with properties will be created. The latter is editable and for example the URL of the Web Service can be changed. Now, the web methods of the Web Service are ready to be used. Data to and from the service is transferred in XML format over SOAP (Simple Object Access Protocol).

4.2.2.2 Windows Forms Windows Forms is a class library for developing Windows graphical user interface applications. It is closely tied to the Windows operating system.

4.2.2.3 ASP.NET ASP.NET is used to write web pages. A developer may choose to write the code for presentation logic together with the code for application logic or to separate these into two different files. As mixing presentation logic with application logic tends to get confusing when a file grows it may be better to use the latter approach. This approach is called “code behind”. Each web page consists of two files; the ASP.NET file containing presentation logic and a file written in one of the languages supported by the CLR. This file contains the business logic or in some cases is just an interface to the real application logic, which is located in other parts of the system. Dividing presentation logic and application logic makes it simpler for development teams where some people are specialized in writing code for presentation while others write the code for application logic.

20

4.2.3 Class Libraries The .NET Framework provides class libraries and base class libraries. The class libraries include classes for data access, XML support directory services, regular expressions and queuing support. The base class library in the .NET Framework covers many areas, some of these are; collections, thread support, code generation, input/output, reflection (provides support to load and examine assemblies) and security. Since the base class library is quite extensive a tool is provided to be able to locate specific classes.

4.3 Other Services Below, some of the services .NET provides are described.

4.3.1 Transactions Transaction management in .NET can be handled in a few different ways. One way is to specify that you wish to use transactions directly in the ASP.NET code. The default behaviour is that the transaction will be automatically committed unless an error is raised. The boundary of the transaction will be all code that the page contains. It is also possible to manually commit and roll back transactions and thus setting the boundaries too. If the system uses components and it is desirable to manage transactions within the components, this is handled semi-automatically. The type of transaction (disabled, not supported, supported, required, requires new) needs to be specified. The same applies to the transactions boundaries. When taking advantage of Web Services these may also be specified as transactions. The type of transaction is specified. If an error is raised the transaction fails, otherwise it is considered successful. A transaction can also be used directly in the data access code. The transaction is handled manually.

4.3.2 Security .NET provides a few different ways to authenticate users. Internet Information Services (IIS), Windows 2000, Passport (centralized, web-based authentication service provided by Microsoft) or forms provide mechanisms for authentication. All these but Passport are tied to the Windows operating system in one way or another. The option forms, requires the developer to provide code for login forms but then the developer may take advantage of .NET features regarding security. These include methods such as isAuthenticated() and isInRole().

21

4.3.3 Database Connectivity The technology to connect to and manipulate data in data stores in .NET is called ADO.NET (ActiveX Data Objects). ADO.NET uses a disconnected strategy. Instead of keeping a connection open, data is transferred to the client, the connection closed and the data is manipulated. Then a new connection is opened and the manipulated data is uploaded. Some database managing systems have the capability use XML for data exchange. ADO.NET is well prepared for this.

4.3.4 System Architecture It is possible to set up a system running .NET in two different ways. One way is to concentrate all logic, both application and presentation, to the web tier. The other architecture is to separate the application logic and put it in a middle tier. The two different approaches have both advantages and disadvantages.

Figure 8 - .NET tier architecture It is important to note that no distinction between logical and physical architecture has been made here. It can be assumed that each tier is hosted on one or more separate machines, thus, the first alternative requires at least three machines working together and the second at least four.

22

The first alternative makes use of the “code behind” option where ASP.NET code and c# (could also be VB.NET, Jscript.NET or C++) is separated into two different files. Each ASP.NET file represents a different web page. The application logic is implemented in the c# files and is directly related to the ASP.NET file. The second alternative uses a similar architecture. ASP.NET and the “code behind” c# is used, however, the c# files on the web tier contain no real logic. Instead, this logic is implemented in classes on the middle tier. The first alternative usually provides better performance due to less network traffic. The exception is if the application logic is very CPU intensive. Then a design with the application running on two, more specialized machines is preferable. When it comes to development the first alternative is probably more suitable for smaller projects. The code is not very reusable, but is concentrated to one place and if it needs some smaller modifications it is easy to perform these. However, when projects grow larger it is important to get a good overview of the entire system and have better options of scalability and reusability. The second alternative provides this since this design is more hierarchical while the first has a flat design.

23

5 Comparison of .NET vs. J2EE This section describes what was found during the research, which was done by reading and comparing books, reports, tutorials and specifications about the two techniques. First a general comparison of the two platforms is made and then each service of one platform is compared to a corresponding service of the other platform.

5.1 Overall comparison There no is simple answer such as “Technique X is best”. Both J2EE and .NET have their strengths and weaknesses. It is easy to realise that one technique may be the most suitable under some circumstances while another technique may fulfil its task better in other circumstances. The point of if this paper is to provide guidance in the choice of technique when given a set of parameters; hardware environment, developer skills, application design, performance requirements, other systems (database manager systems, legacy systems) and, of course, the desired end product and/or service. It is not easy to do a fair comparison of the two techniques. Even though the end product provides exactly the same services there may be large differences in how the product has been implemented. J2EE has been around for some time now, while .NET is completely new. J2EE is an open standard and has been developed by many different parties. There is extensive documentation about the platform and there are many different ideas on how to take advantage of the J2EE technique when developing different products with different architectures. A single company, Microsoft, provides .NET and thus, a sole party has influenced the development of the .NET platform. The documentation of .NET is provided by Microsoft or by parties very much influenced by Microsoft. Even though different ideas for application architectures exist, the number of different ideas is limited, probably due to the two facts that .NET is new and Microsoft is the sole provider.

24

5.2 General Architecture Really, there is nothing as a “general” architecture as each application is unique, however, different design patterns exist and when in the process of determining the architecture of an application one of these patterns is usually adopted. If a great generalization is done, it could be said that .NET is more web centric and has a flatter design compared to J2EE applications, which are more hierarchical in their structure and more centered around the application tier. But note once again that this is a very general view and the architecture of an application really is not constrained to a certain design in any of the two application server techniques discussed in this paper. In the figures below a typical design for each of the techniques is presented. In the .NET architecture depicted in Figure 9, the application logic could be concentrated inside the code-behind classes or, code-behind could serve as an interface to the .NET components where the application logic would reside in a different scenario. (Steve Kirk, David Chappell, 2002)

Figure 9 - .NET architecture

25

Normally in J2EE applications the application logic resides in enterprise session beans, either stateless or stateful depending of the use. JavaBeans and servlets could be compared to the code-behind in .NET with the exception that no application logic should be put in JavaBeans/servlets. Enterprise entity beans interact with the DBMS, hold the data and provide transactional support. Sometimes the support provided by entity beans is not necessary or would demand interaction with bundle of different entity beans. In those cases the entity beans can be bypassed by letting session beans interact with the database directly.

Figure 10 - J2EE architecture

26

5.3 Service-by-Service comparison As the J2EE specification clearly defines what services a J2EE compliant server should provide this part of the comparison has been done by looking at each service required by the J2EE specification and then finding the corresponding service in .NET. Both .NET and J2EE servers may provide other services but since these services are not defined in the J2EE specification they have not been included. In some cases there might not be a service directly correspondent in .NET but by combining two or more services specified by J2EE a similar service provided by .NET may be achieved.

5.3.1 JSP – ASPX Java ServerPages and Active Server Pages X are very similar. Both are intended to provide a mix of plain HTML and some presentation logic. It is important to realize that even though it is possible to access most functions of an application directly from a JSP or an ASPX page this is not how it should be done in any larger application. The goal should always be to try to separate the logic for presentation and application. Even presentation logic should, when possible, be separated into different parts making a distinct separation of code written by a graphical designer and an application developer. Often the job for an application developer is to provide different pieces of customized code that the graphical designer can use without having to understand the logic behind it. Optimally the designer should only have to know how to use a set of “tools” provided by application developers and of course, what parts of the application will process the incoming requests. An interesting question at this point is: what happens when a request is posted? It is interesting since the answer will show similarities as well as differences between J2EE and .NET. When it comes to J2EE the request can be handled in a few different ways:

• A general dispatcher servlet determines what part of the application should process the request.

• More or less specialized servlets handles part of the processing and uses other parts of the application for processing the request.

• A JavaBean used more or less the same way as above alternative. The difference is that a JavaBean has get and set methods corresponding to the parameters the JSP let’s the client specify.

The way of processing a request in .NET is quite similar to the JavaBean approach of J2EE with one major difference: it is event driven. Each ASPX has a code-behind file where different control methods are added, for example Page_Load and Button_Click. The same effect can be achieved with J2EE by using methods such as onLoad() or onClick() provided by JavaScript, but it is not an integrated part of JSP as it is in the case of ASPX.

27

In the case of JSP the application developer may add plain Java code within special JSP tags to handle for example different listings requiring some logic. It is also possible to code Tag Library Definitions (TLD) fo r these tasks. TLDs provide a clean and easy way for a designer to include some logic without having to know how to code Java. To present a list of users may look something like code 1 the JSP/Java approach.

Code 1 – dynamic list JSP

The object userList is of type java.util.ArrayList and user is an own designed class with get and set properties for the different attributes a user may have. User could, for example be initiated with a java.sql.ResultSet which is the output of a database query. The TLD approach would generate the exact same HTML output as the first example and could look something like code 2.

Code 2 – dynamic list TLD

The logic in the TLD file would look similar to the example of Java mixed with HTML. Accomplishing the same with ASPX could also be done in different ways. One way would be to code something that would look very similar to the JSP/Java example. Another possibility is quite similar to the TLD example with one major difference; no HTML is needed. ASPX provides many special tags and in this case code 3 gets the job done.

Code 3 – dynamic list ASPX

... <TABLE> <% for (int i=0;i<userList.size();i++) { User user = (User)userList.get(i) %> <TR><TD><%=user.getName()%></TD><TD><%=user.getAge()%> </TD></TR> <% } %> </TABLE> ...

<%@ taglib uri=”/mytld.tld” prefix=”mytld” %> ... <mytld:create_user_table value=’<%=userList%>’/> ...

<%@ Page language="c#" Codebehind="mypage.cs" Inherits="myApplication.myClass" %> ... <asp:DataGrid id="myDataGrid" runat="server"></asp:DataGrid> ...

28

The data is bound to the data grid in the code-behind file. The data binding looks like is shown in code 4.

Code 4 – data binding ASPX

In this case userList is of type System.Data.DataView. A DataView can be obtained by filling an instance of the System.Data.DataSet object with the output generated by a database query and then convert it into a DataView. The ASPX programmer has a choice of a few different languages that may be integrated with the HTML code the same way as Java and HTML may be mixed in a JSP page.

5.3.2 JDBC – ADO.NET Just like JDBC allow J2EE servers to work with database manager systems ActiveX Data Objects allows .NET to do the same. ADO.NET is an integrated part of .NET and no extra components are necessary to connect to a Microsoft SQL Server v7.0 (or higher), however, if using a different DBMS is desirable an ODBC driver is required. As in the case of JDBC drivers, some are free while others have to be purchased. Establishing a connection is quite similar regardless of technique. A connection string containing the URL of the data source, database name, username and password is created. Some additional properties may be passed in the same string. A connection is then established by providing the connection string. Below follow two examples showing how to connect to a mySQL DBMS from J2EE and .NET respectively. J2EE

Code 5 – DBMS connection J2EE

The driver classes mus t be in the classpath to be able to use the driver from the code.

... myDataGrid.DataSource = userList; myDatagrid.DataBind(); ...

Class.forName("org.gjt.mm.mysql.Driver").newInstance(); Connection con = DriverManager.getConnection( "jdbc:mysql://myserverUrl/username=foo&password=bar/test"); con.Open(); // query goes here con.close();

29

.NET

Code 6 – DBMS connection .NET To access the driver from the code it must first be registered as an ODBC data source. When a connection has been established the next step is to perform a query. J2EE The JDBC API allows the programmer to create a so-called PreparedStatement. A PreparedStatement is a pre-compiled SQL statement. This means that the DMBS will not have to compile the statement and thus provides a performance benefit instead of letting the DBMS compiling the statement every time it is queried. It is, of course, also possible to run a query without preparing it first.

Code 7 – DBMS query J2EE

code 7 will return a java.sql.ResultSet.

OdbcConnection con = new OdbcConnection("driver={mysql}; Data Source=myserverUrl;User Id=foo;Password=bar;Initial Catalog=test;"); con.Open(); // query goes here con.close();

String SELECT = "select name, age from user where userid > ?"; PreparedStatement ps = con.prepareStatement(SELECT); ps.setInt(userId); ResultSet rs = ps.executeQuery();

30

.NET The way a SQL query is executed depends very much on how the result is going to be handled, but basically a string is used as statement for all queries. Here are two examples returning different output formats.

Code 8 – two DBMS queries .NET

The first option will return a System.Data.DataSet while the other returns a System.Data.SqlDataReader. Depending on what the developer intends to do with the information retrieved from the database one output format may be more suitable in some cases while a different format may be wanted in other circumstances.

5.3.3 JTA – MTS The Microsoft Transaction Server, which is a part of the Windows operating system, manages transaction support. The MTS, which was released two years prior to the J2EE specification, has been made part of .NET. MTS and J2EE container-managed transactions provide almost exactly the same service. While transactions support in J2EE allows somewhat more flexibility for the developer it is also more complex to work with. Imagine a scenario where different parts of the system use different management of transactions.

5.3.4 JAXP, JNDI, RMI– Web Services It seems sensible to bundle Java API for XML Parsing, Java Naming and Directory Interface and Remote Method Invocation and compare it with Web Services. XML is very much integrated with many parts of .NET, but the probably most obvious case when it’s used is Web Services. The exchange of data is handled over the SOAP protocol and the data format used is XML. There is no real counterpart to JNDI in Web Services. JNDI is used to store information about where components reside. When a client requests a directory service it locates and

string SELECT = "select name, age from user where userid < " +userId; SqlDataAdapter da = new SqlDataAdapter(SELECT, con); DataSet ds = new DataSet(); da.Fill(ds, "user"); string SELECT = "select name, age from user where userid < " +userId; SqlCommand sqlCmd = new SqlCommand(); sqlCmd.Connection = con; sqlCmd.CommandText = SELECT; SqlDataReader reader = sqlCmd.ExecuteReader();

31

retrieves the requested component. A Web Service is registered by the developer according to the Universal Description, Discovery, and Integration (UDDI) specification. When a client wishes to take advantage of a Web Service, the registry is searched. When an appropriate service is found a proxy object is created, which is served on the client application. The proxy object is used for communicating with the actual Web Service. RMI also uses proxy objects for communication with distant objects. J2EE To take advantage of a remote object in J2EE the home and remote interfaces of the enterprise bean one intends to use are needed. Then some code in the Java files as well as the configuration files needs to be written. This code may vary somewhat, depending on the J2EE server used. The servers have their own context factories and may use different protocols for communicating with remote objects. Also, the configuration files are specific to each J2EE server even though they usually are very similar. Code 9 shows how a reference to a remote enterprise bean is created with the Weblogic J2EE server:

Code 9 – reference to remote enterprise bean J2EE

uamHome is a reference to the home interface of the UserAuthenticationManager bean. The home interface contains methods for the beans lifecycle management. The following code creates an instance of a bean and then executes a business method declared in the beans remote interface.

Code 10 – execute method of enterprise bean J2EE

... Properties properties = new Properties(); properties.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); properties.put(Context.PROVIDER_URL, "t3:// myJ2EEserver"); Context ctx = new InitialContext(properties); Object objref = ctx.lookup("com.daniel.exjobb.session.UserAuthenticationManagerHome"); UserAuthenticationManagerHome uamHome = (UserAuthenticationManagerHome) PortableRemoteObject.narrow(objref, UserAuthenticationManagerHome.class); ...

... UserAuthenticationManager uam = uamHome.create(); boolean userAuthenticated = uam.AuthenticateUserByUserName(userName, password); ...

32

In the configuration files the JNDI name, com.daniel.exjobb.session.UserAuthenticationManagerHome, of the remote bean used has to be specified. .NET Before the implementation of a Web Service can begin some code is needed. A tool included in .NET generates this code. The generated files are a .wsdl (Web Service Definition Language) file and a c# file. The code for integrating a remote Web Service in .NET is quite simple.

Code 11 – reference web service and execute method .NET

An instance of the Web Service object Authenticate is created. remotehost is a directory for this particular Web Service the developer has created and authenticate is the name of the namespace the developer is currently working in. Then the method authenticateByUserName(string userName, string password) provided by the Web Service is executed. Some may say that comparing Web Services with RMI is like comparing apples with pears, but essentially they work the same way and have the same function: to provide some sort of service remotely. It is possible to create and use Web Services in J2EE environments, but since Web Services are not part of the J2EE specification they have not been included in this paper. .NET also provides an older technology called COM+ which is more like RMI than Web Services. The reason for not bringing in COM+ in this comparison is that Web Services is such central part of .NET that it seemed very important to include it in some comparison with J2EE. Since J2EE does not yet include web services in its specification the most adequate comparison is the one between JAXP, JNDI, RMI vs. Web Servivces.

5.3.5 JMS – (system.messaging namespace, .NET class library) .NET the system.messaging namespace provides classes that allow you to connect to, monitor, and administer message queues on the network and send, receive, or peek messages. JMS provides basically the same functionality. The fact that J2EE provides message driven beans means that the messages received by these beans are wrapped and can easily be included in transaction or other services a J2EE application server provides.

authenticate.remotehost.Authenticate userAuthenticationService = new authenticate.remotehost.Authenticate(); bool userAuthenticated = userAuthenticationService.authenticateByUserName(userName, password);

33

5.3.6 JavaMail – (system.web.mail namespace, .NET class library) J2EE includes the JavaMail API build up on a set of classes and interfaces that comprise an electronic mail system. .NET has the system.web.mail API providing the same kind of service.

5.3.7 JAAS – (system.security namespace, .NET class library) Both J2EE and .NET have very similar options on how to authenticate and authorize a user. Web server, application server and form based authentication are used by both techniques. .NET has a fourth option: Passport, which is an integrated web service for authenticating users. Both techniques provide authorization based on a concept of different security roles. The APIs have methods like isUserInRole() or isAuthenticated(). Each resource may be specified to only allow users with certain security roles such as system administrator for example.

5.4 Development and Development Tools J2EE There is a jungle of different tools for developing J2EE applications. There are IDEs (Integrated Development Environment), graphical design tools and build tools and many others. An IDE is primarily used to write code. It usually provides editing features as syntax highlighting and auto completion. IDEs also provide different ‘plug- in-services’. This means that different plug- ins can be downloaded to provide help for certain tasks. Two examples of IDEs are NetBeans and Jbuilder, where the former one is an open source project and is free. Many java developers find these IDEs to be more of a burden than assets as they often are quite slow and may be difficult to configure. Therefore java developers can often be found using ordinary text editors. A very important tool necessary for any larger project is a build tool. A build tool provides help for compiling, building and distributing applications. Since large application may consist of several thousand classes it may be rather time consuming to compile all these when only a few have been altered. It is not necessary to recompile all files when changes have been made in only one or a few classes. The build tool checks the timestamp of each file and only compiles those who have changed. When building an application, files are usually packaged into application archive files, separated into Web Application aRchives (.war) and Java Application aRchives (.jar). Together these form Enterprise Application aRchives (.ear). To distribute an application means to copy the necessary files to various servers and deploy them. A tool providing all this functionality is ANT and is used by almost all J2EE application developers. ANT is an open source project and it is free.

34

.NET A very central part of the .NET platform is Visual Studio .NET (VS.NET). This tool is an IDE including almost everything for developing applications. VS.NET is working online with the web server, database and web services. Using VS.NET it is possible to develop the graphical layout of an application by dragging and dropping components onto the application. It is also possible to add other components such as database connection objects to the application by dragging and dropping. This is of course only an alternative to writing the code by hand. VS.NET is a very complete development environment and there are not many alternatives. One alternative is to write all code with a simple text editor and using the command line tools that are integrated in .NET separately, for example compiling a proxy object necessary for web service clients. Even though VS.NET is a quite expensive tool it is recommended to use it as it will save the developer a vast amount of time compared to using the command line tools.

5.5 Environment To run a J2EE application a Java Virtual Machine (JVM) is needed. These are often included with the application server. There are JVMs for many different operating systems (OS) including Windows, UNIX and Linux making J2EE a multi platform system. .NET is restricted to run under the Windows OS as the .NET Common Language Runtime (CLR) only exists for Windows. Open source projects exist which allows for a .NET similar product to be run on UNIX/Linux. Many J2EE application servers include support for running the servers in a clustered environment. This is not required by the J2EE specification. The Internet Information Services server, which is part of the .NET suite, also provides clustering support.

5.6 Application Monitoring When an application has been developed and is up and running the system needs to be monitored somehow. Things kept on eye on during production are for example CPU utilization, number of ongoing transactions and client requests per second. Some J2EE vendors include monitoring tools with their application servers but it is nothing that is required by the J2EE specification. It is also possible to buy stand-alone tools to monitor the system. No monitoring tool is included with .NET directly but can be purchased as an extra component.

35

5.7 Performance Different more or less independent parties have done much research in the area of comparing different application server techniques performance wise. It is often difficult to evaluate the results of these tests as a test can be set up in an unlimited number of ways and be measuring different aspects of an application server technique. The most common scenario is that an application server vendor performs a test and for some reason it always seems that their product is the one showing the best results. This is the reason why no actual figures of these tests are presented in this report. Anyone involved in the .NET – J2EE debate has hardly been able to avoid “the Pet Store” example. Pet Store is an application provided by Sun as an example to enlighten Java developers of different “best practises” using J2EE. Microsoft took this application and recoded the application for .NET. Then they performed some tests and came to the conclusion that .NET demands less code and gives better performance compared to the same solution for J2EE. Now some J2EE server vendors optimised the Pet Store application for their server and claim that their solution gives the better performance.

5.8 Future It is never easy to predict the future, however, in the world of software development there are often many hints about features to come in earlier releases. Often functions have been prepared but not yet implemented or the implementations may already exist but just haven’t been officially released. One such example is Web Services for J2EE. Some J2EE application server vendors have already included web services in their product even though it is not required by the J2EE specification. Web services is a very hot topic at this point in time that it may almost be guaranteed that the next version of the J2EE specification will include web services as a required service. .NET is still a very new product and some features have not yet been fully implemented. It seems reasonable to guess that these features will work as they are specified in future releases. A second guess is that .NET will slowly move over from being a web centric platform to a more business centric model. The reason for this belief is that the design for enterprise applications could be a bit cumbersome with a web centric model. Often these models have many specialised components which prohibit them from being reused in any other purpose than the one it was first designed for.

36

6 Test: J2EE distributed EJB’s vs. .NET Web Services This chapter describes a test made comparing two different techniques but performing the same service, namely to be able to register, authenticate and update user credentials. The implementation, the transaction support and performance of the tests are compared.

6.1 Purpose of test application The authentification application running on the server provides four simple services.

- Register user - Authenticate user - Get user credentials - Update user credentials (not implemented)

It is easy to realize that this simple application can provide a great service to many clients. Instead of having each client develop the ir own user management system the server application can be used by many clients. The typical client is a site that requires visitors to authenticate themselves before taking advantage of some services that particular site provides. Another advantage is that if many sites are connected to the user authentication application the user will not have to remember many different usernames and passwords, but only one. When the user changes some data, for example the address, the change will be valid for all sites. The latter functionality has not been implemented in this particular test, but it would be easy to do so if the application would go into production.

6.2 Tools To perform these tests a number of tools were required. They are all listed below: J2EE Client environment: Microsoft Windows 2000 Weblogic 6.1 service pack 2 Server environment: Microsoft Windows 2000 Weblogic 6.1 service pack 2 Microsoft SQL Server 2000 Microsoft SQL Server 2000 driver for JDBC

37

.NET Client environment: Microsoft Windows 2000 Microsoft .NET Framework v1.0.3705 Microsoft Internet Information Services server Visual Studio .NET Server environment: Microsoft Windows 2000 Microsoft .NET Framework v1.0.3705 Microsoft Internet Information Services server Visual Studio .NET Microsoft SQL Server 2000

6.3 Application set up J2EE The authentification application consists of three parts: two EJBs and the database. The database has two tables of interest, one with user credentials and one working as a log for requests to the application. One EJB is an entity bean corresponding to a row of the table holding user credentials data. The other EJB is a stateless-session bean. This bean has two purposes, work as a wrapper for the entity bean and log requests. .NET The authentification application is set up as a web service, which uses the same database as the J2EE application for information storage.

6.4 Client set up J2EE When a user enters a site the user is asked to identify him. The user passes his username and password to the client site. The client site picks up this input and passes it on to the server application over a secure connection. The authentification application checks the database for a corresponding username and password. If the password matches the username the authentication application replies to the client site that the authentication was correct. If the password doesn’t match the username the response is that the authentication was incorrect. If the authentication was acknowledged, the user is forwarded to a page where the user’s credentials are shown. To be able to take advantage of the service provided by the authentication application the client site needs the following:

38

• URL to authentication application • JNDI name of the authentication application stateless-session bean. • Home and remote interface of the authentication application stateless-session

bean. The client application also offers a web interface for new users to register themselves. .NET The client application has the same functions as the J2EE client application. The URL of the web service is needed. When it’s known the client can connect to the web service and create a proxy object of it. The proxy object contains information about what methods the web service has and where it can be found.

6.5 Communication between client and server To ensure that only recognized client sites take advantage of the authentication application and that data is transferred over the Internet securely, a solution with SSH tunnelling was implemented. It works like this: The client is provided a URL and a port; the port is unique for each client. (This limits the number of clients to the number of ports available) The clients “allowed IP’s” are registered in a machine that handles the tunnelling. This means that the port and the IP address identify a client. All requests on the client assigned ports are tunnelled to a single port; the port that the Weblogic server utilizes. The authentication application processes the data and replies through the same port. The same goes for the .NET application; the only difference is that it has been configured to use a different port, which tunnels traffic to a Microsoft Information Services server.

Figure 11 - Physical set up

39

6.6 Implementation of test J2EE Client: 3 JSP-pages 1 JavaBean 1 stateless-session EJB Server: 1 JavaBean 1 stateless-session EJB 1 entity EJB 2 db - tables The client application is a site, which doesn’t provide any real functionality but the ability to register, log in and view the user credentials given during registration. Each of these functions is served by a separate jsp-page. Each jsp-page is working together with a JavaBean. The same JavaBean is used for all jsp-pages. This JavaBean provides simple set and get methods as well as methods, such as registerUser() and authenticateUser() connecting to the ejb running in the client application. The ejb is a standard stateless-session bean. It has all the methods required by the J2EE specification and some business methods very much like those in the JavaBean. These methods connect to the stateless-session bean running in the server application. This bean is almost identical to the stateless-session bean at the client. The differences are that it has some methods to log requests and that it passes the data on to an entity bean running in the server application. The entity bean has no real business methods at all. It has the methods required by the J2EE specification and some set and get methods. The required methods handle interactions with the database. .NET Client: 3 ASPX-pages 3 “code-behind” C# files Server: 1 ASMX-Web Service 2 db – tables The client application serves three different pages, a registration page, a login page and a page where a user’s credentials are presented. Each of these pages is an aspx-page. An aspx-page looks like straightforward HTML with a few special tags. It also has a directive to a “code-behind” file. This file contains some application logic and is event driven. Example methods are page_load() and button_click(). Within these methods there is logic to connect to the web service using the proxy object and performing methods serviced by the web service. The web service has methods accessible from the “outside”. These methods are declared as web methods. These methods may have attributes as description, session handling and transaction support amongst others. The web service also has private methods only accessible inside the web service. These methods are used for logging and some as help

40

methods performing simple tasks such as obtaining a user id or getting a database connection.

6.7 Transactions J2EE This test was primarily developed to test how ejb’s work in a distributed environment. The second objective was to test transactions. The test defines two transactions during an interaction, firstly a transaction spanning both the client and the server (Tx1), Secondly a transaction running within the transaction spanning both servers (Tx2). This means that if Tx2 fails and rolls back, it will make sure that Tx1 is also rolled back. See fig 12. .NET The intention was to use exactly the same transaction boundaries as in the J2EE application and everything was set up to reflect the same transaction attributes. But with some further investigation it became clear that Tx1 was not spanning the entire transaction as it was meant to be. This version of .NET Web Services does not support distributed transactions as they are specified in the headers of the web methods. Supposedly there are some ways to enable a web service to participate in transactions but even after intense coding and testing the transactions would not work as intended.

fig. 12 – transaction boundaries

6.8 Description of Test The test has been designed in the following manner: A program, Microsoft Application Test Center generates a script according to a recorded user session. The script contains three requests. The first one is to load the login page. The login page has two text fields where the user name and password are entered. It also has a button. When this button is pressed the second request is sent to the server and the user name and password are evaluated. If the login is correct, the user is automatically redirected to a page where the user’s credentials are shown. If instead the login fails the user is directed back to the login page and given a message that the login was not authenticated.

41

6.9 Conclusion After performing these tests it was possible to draw a few different conclusions. Developing the test application was faster and easier with .NET. The major reason was the ease of use of the development tool Visual Studio .NET which was the only tool needed. To produce the J2EE application three separate tools were used: an editor, a compiler and a build tool. The configuration of these tools was more cumbersome than configuring Visual Studio .NET. Performance wise both techniques gave almost exactly the same results, which is very strange. It seems possible that the performance tests were set up in such way that the applications themselves were not the bottlenecks but some other part, such as the load generating tool or the bandwidth. To assure that performance is tested fairly new tests need to be made. A fair test regarding transactions could not be done, since the implemented .NET solution did not support distributed transactions.

42

7 Conclusions This chapter summarizes the conclusions drawn in this report. It also gives some background to the work of writing the report. It is never easy to do a good comparison in areas such vast as entire application server platforms. Different application servers have different features and even though the end product or service of the application is the same, the way of getting there can be quite different. It is important to remember that not only the application can be coded in different ways, but more importantly, that the entire architecture can vary very much. If someone is about to start programming an application and doesn’t know what application server platform to use, hopefully this report could provide some help. If, for example, the application is a simple book store perhaps the reader of the report will come to the conclusion that .NET will suit the reader’s application the best. Some other reader may be on the verge to start developing an application to integrate systems with different purposes such as a billing system, a web store and a human relations system and this reader may come to the conclusion that a J2EE based application server will suit his needs more adequately.

7.1 Personal opinions and findings Personally I believe that the most important findings during my research can be narrowed down to the following points:

• It is easier to develop applications for .NET than for J2EE much due to the fact that .NET provides a great tool, Visual Studio .NET, which is the only tool needed to develop .NET applications.

• .NET is more suitable for web centric applications than J2EE. • J2EE is more suitable for business centric applications than .NET. • If you want to remain OS independent, choose J2EE. • If distributed transactions are a key factor of the application, be careful with .NET

Web Services. The description of these findings may seem very crude and so it is. They are my own personal conclusions and may not follow the same line as other people’s findings. I would actually be very disappointed if someone just accepted these as facts or the general opinion. If you have read this report, compared it with other sources and came to the same conclusions as I did so may be it, but if you just glanced at the report and read the bulleted points of the conclusions chapter you may very well make a disastrous choice selecting an inappropriate application server technique. It is much more important to understand the architecture of the intended application and what services it is to use. When this has been decided it is time to choose the appropriate application server technique.

43

7.2 Progress of the work The first intention was not to write a report on application server techniques but merely concentrate on the web tier and the different technologies that exist for this purpose, such as JSP, ASP, PHP, CGI and perhaps few others. After some research was made in this area it was decided that it actually was more interesting to see what was behind all this. So, new research begun and new areas of interest were found. Now the first thought was to provide a report that would give someone about to develop an enterprise application a guide exactly to what was needed or wasn’t needed in terms of application server technique, hardware resources and development resources. Now, this was quite difficult to do so instead it was decided that this report would cover what services two application server techniques provided, namely J2EE and .NET and compare these services.

7.3 Thanks to… … My supervisor at NADA Tommy Palm for providing me with interesting material and feedback, taking time for meetings and reading the report numerous times. … My supervisor at TradeDoubler Lennart Häggkvist for interesting discussions and feedback in the J2EE area. … My supervisor at TradeDoubler Ola Udén for allowing me to do the work and using TradeDoubler’s resources such as computers and literature. … My professor at NADA Stefan Arnborg for accepting this work as a master’s thesis. … My teacher at Grafisk Teknik Björn Hedin for getting my eyes up on this interesting area of computer programming. … All others that have given me interesting input in the area of application server techniques.

44

8 Bibliography

1. Richard Andersson, Brian Francis, Alex Homer, Rob Howard, Dave Sussman, Karli Watson, 2001, Professional ASP.NET, Wrox press Ltd, Birmingham, UK, ISBN 1-861004-88-5

2. Christopher Asaipillai, 2002, The History of Distributed Object Oriented Technologies, http://www.metronet.co.uk/weegee/OOD.htm, last visited 20020310

3. Peter Bright, 2002, What is .NET?, http://arstechnica.com/paedia/n/net/net-1.html, last visited 20020415

4. Nicholas Kassem, 2000, Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition, Addison-Wesley, Palo Alto, CA, USA, ISBN 0201702770

5. Steve Kirk, David Chappell, 2002, Application Design guidelines: from N-tier to .NET, http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch001.asp, last visited 20020423

6. Juval Löwy, 2001, .NET Services Components, http://www.oreillynet.com/pub/a/dotnet/excerpt/com_dotnet_ch10/?page=7, last visited 20020519

7. Monica Pawlan, 2002, Distributed Multitiered Applications, http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Overview2.html#68378, last visited 20020325

8. Ed Roman, 1999, Mastering Enterprise JavaBeans, John Wiley & Sons, published simultaneously in Canada, ISBN 0471417114

9. Bill Shannon, 2001, J2EE specification, http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf, last visited 20020325