An Evaluation of Application Server Techniques. Written By Daniel Bernholc

Transkript

1 An Evaluation of Application Server Techniques Written By Daniel Bernholc

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

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

4 1 Introduction Background System Architectures Single-tier architecture Two-Tier Architecture Client/Server Architecture Three-Tier Architecture n-tier Architecture Distributed Objects What are distributed objects? How is a distributed object used? J2EE Services HTTP and HTTPS Servlets JSP JTA RMI-IIOP and Java IDL JDBC JMS JNDI JavaMail and JAF JAXP J2EE Connector Architecture JAAS Multitier Model Business Tier Enterprise JavaBeans (EJB) What is an EJB? Why use EJBs? EJB Types Web Tier Web Tier Architecture NET What is.net? The.NET Framework The Common Language Runtime (CLR) Application Development Technologies Web Services Windows Forms ASP.NET Class Libraries Other Services Transactions Security... 22

5 4.3.3 Database Connectivity System Architecture Comparison of.net vs. J2EE Overall comparison General Architecture Service-by-Service comparison JSP ASPX JDBC ADO.NET JTA MTS JAXP, JNDI, RMI Web Services JMS (system.messaging namespace,.net class library) JavaMail (system.web.mail namespace,.net class library) JAAS (system.security namespace,.net class library) Development and Development Tools Environment Application Monitoring Performance Future Test: J2EE distributed EJB s vs..net Web Services Purpose of test application Tools Application set up Client set up Communication between client and server Implementation of test Transactions Description of Test Conclusion Conclusions Personal opinions and findings Progress of the work Thanks to Bibliography... 48

6 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 background information from a historical point of view of the development of the enterprise application architecture. 3 J2EE description of the Java 2 Enterprise Edition platform. 4.NET description of 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 review of the results achieved. 8 Bibliography 1

7 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 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 Two-Tier Architecture The two-tier 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. 2

8 This technique was very common in the early days of the Internet breakthrough. In fact, many simple web applications still use this technique 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 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 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 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. 3

9 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. client application server application remote interface distributed object Internet Figure 1 Distributed object 4

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

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

12 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 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 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 JSP Mixing of content and presentation logic is not very desirable as web designers and programmers often 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 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 7

13 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 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 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 JMS The Java Messaging System supports two different messaging models: publish-subscribe messaging point-to-point messaging 8

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

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

16 assembly and deployment time. Features that can be configured are for example security checks and transaction management. (Nicholas Kassem, 2000) application client dynamic HTML pages client tier client machine JSP pages web tier J2EE server machine enterprise bean enterprise bean business tier database database EIS tier database server machine Figure 2 J2EE tier architecture 11

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

18 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 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. This is not always true, but is the general case. A message driven bean acts as a listener for the Java Messaging System (JMS) 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 13

19 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 number 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 Session Beans Table 1 Database table USER 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. 14

20 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 a stateless bean. EJB container pool Instance of UserManager client Instance of User User User database Figure 3 - Example of User 15

21 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 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 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). HTTP request response Servlet application tier Figure 4 Servlet only 16

22 JSP only - The presentation logic and content are mixed (figure 5). HTTP request response JSP application tier Figure 5 JSP only 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). request HTTP JSP JavaBean application tier response 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. 17

23 request Servlet application tier HTTP response JSP Figure 7 Servlet and JSP 18

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

25 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.) 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 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 Francis, 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. 20

26 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) Windows Forms Windows Forms is a class library for developing Windows graphical user interface applications. It is closely tied to the Windows operating system 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 21

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

28 of.net features regarding security. These include methods such as isauthenticated() and isinrole() 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 System Architecture It is possible to set up a system running.net in two different ways (figure 8). 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. 23

29 client tier HTML client tier HTML web tier presentation application web tier presentation middle tier application database database 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. 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. 24

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

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

32 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) ASPX code-behind legacy systems Web Services.NET components database Figure 9 -.NET architecture 27