J2EE Platforms and Microsoft by wuzhenguang


									                                   J2EE Platforms and Microsoft .NET
                                      Technologies in Perspective
                                                                                                          Prof. Judith
      Cobus Smita                     John Mullerb                   Dr. Jay van Zylc
            Department of Computer Science, University of Pretoria, Pretoria 0002, South Africa, cobus.smit@cs.up.ac.za
           Department of Computer Science, University of Pretoria, Pretoria 0002, South Africa, john.muller@cs.up.ac.za
             Department of Computer Science, University of Pretoria, Pretoria 0002, South Africa, jay@systemiclogic.com
                              Department of Computer Science, University of Pretoria, Pretoria 0002

Structuring of the platform technologies for the development of enterprise scale applications and services requires
clearly defined boundaries. J2EE and the .NET framework are similar in their structuring and implementation of
distributed solutions as well in the behavior of their technologies. Logical separation of the technologies can be
achieved by defining a theoretical model that considers all abstract and technical dimensions of application
development. This paper compares the technological structuring of J2EE and .NET using a separation continuum.
This continuum brings an important context to enterprise and service architectures as well as the contemporary
technologies that lead to the realization of those architectures.
Keywords: J2EE, .NET, Separation Continuum, Horizontal Continuum

1    Scope
This paper explores the range of technologies provided by the J2EE specification and the Microsoft.NET
framework. The J2EE technologies include vendor implementation of the J2EE specification. This document
currently focuses on the Sun Microsystems standard specification as described in (Appendix A - J2EE and .NET
Configuration Specifications). The technologies will be mapped to a separation continuum [Van Zylb] described in
section 3. This document excludes transaction management methods provided by J2EE and .NET. Transaction
management is regarded as procedures that are built on the technologies described in this document. Also, many
different software servers (both reference and industrial) exist that can serve as host containers for components and
services. This document additionally excludes descriptions of many different server technologies as the main focus
is to establish model driven classification of the J2EE and .NET platforms. Server technologies will however be
briefly discussed as part of the section on connections (section 4.4).

2    Definitions
The description of the range of technologies provided by any two entities requires focus. This focus could be
described in terms of system architectures. The architectures in turn structure the provided technologies to different
logic and physical distribution tiers. J2EE and .NET both possess technologies to support industry-scale enterprise
and service architectures. J2EE and Microsoft .NET do not have an exact (one-to-one) technological mapping. Clear
definitions are then also required to describe the two platforms and related concepts, to place them in a business-
solution related context.
    Mapping the J2EE and the .NET framework to the horizontal continuum [Van Zylb] (section 3) requires a clearer
understanding of what each of the separate entities represent. This can be accomplished through basic definitions:

API - An Application Programming Interface (API) is a mechanism that allows a programmer to programmatically
request a defined interface service from an application or library. [Def API]

Framework - Frameworks (libraries) are designed for application by a wide range of programming languages and
tools. Frameworks include mechanisms that allow automation of certain parts of the application and technical
development process, as well as minimization of software deployment. [ECMA 335]

J2EE Specification - J2EE is an enterprise design specification created by Sun Microsystems in collaboration with e-
Business platform providers such as BEA, IBM and Oracle. The Java Community Process (JCP) was created to
further develop the J2EE platform. The J2EE specification allows vendors to implement J2EE as an enterprise
application of Java [MWC].

J2EE platforms - J2EE is a collection of APIs built on a single Java platform called the Java runtime. Java utilizes
the Java Virtual Machine (JVM) for application execution. Application execution is interpreted by the JVM. The
Enterprise Edition allows the creation of local and distributed solutions through the use of the bundled and
extendable API modules. J2EE platforms are introduced when vendors implement the J2EE specification bundled
with their own set of productivity tools.

Microsoft .NET framework - Microsoft’s .NET framework is a set of libraries providing functionality in multiple
areas from web services to standard applications. The framework itself is not a standard but contains programming
technologies based on standards like Common Language Infrastructure (CLI). The framework consists of many
languages that are built on the .NET implementation of the CLI called the Common Language Runtime (CLR).
Application execution is not interpreted, but all supported languages are compiled to an intermediate representation,
which in turn is compiled to the operating systems’ native code. The framework itself is the programming model of
the .NET platform and is used for the construction and deployment of both local and distributed services and
applications. [Developer Guide - Overview]

The technical perspectives of J2EE and .NET refer to all aspects relating to user interfacing through to data handing
and persistent storage. Subsequent sections will introduce a technological mapping structure and evaluate J2EE and
.NET accordingly.

3    Architectural Perspectives and Separation of Concerns
A well-defined structure is required to place different technologies in context. Separate logical and physical tiers
exist in the distributed component and services environment. These basic tiers are similar, if not identical when
conceptualizing large solutions. Before introducing service based architecture, it is worth illustrating how the basic
enterprise tiers within a distributed component environment function on a logical level:

                                                User Tier

                                            Workspace Tier

                                             Enterprise Tier

                                              Resource Tier

                                      Figure 1: Taken from [Herzum, Sims]
User tier - The user tier is the visual representation of the business component. The user tier is responsible for all
communication and provision of graphical interface controls to the user.

Workspace Tier - The workspace tier (being the next logical separation) supports the user tier by enabling indirect
access to the enterprise and resource tiers. The workspace tier can also employ local business logic. The workspace
tier is not necessarily a physical tier.

Enterprise Tier - The enterprise tier processes core business characteristics including elements like business rules,
validation and inter-system and component-based communication.

Resource Tier - The resource tier can be described as the tier responsible for managing shared resources and
providing physical access. Users of the resource may be other systems, components or actual clients.

The tiers in Figure 1 can be further logically subdivided to give a different perspective on the same basic tiers,
illustrated in Figure 2 (adaptation from the J2EE model).
    Business systems are large and complex in nature, with isolated business silos containing data and applications
that are very different in nature [Van Zyla]. The integration of these silos can be complex. Different layers can
interact with each other in a component-based environment. This model is limited, because of the cohesiveness of
the interaction. Relationships may include interaction with legacy systems or other different types of systems. The
distributed components within business components are tightly coupled, while a more loosely-coupled solution is
required to expose the services of these different distributed components. It is proposed that all software elements
are seen as software-as-services [van Zyla]. Service based architecture (SBA) [Van Zyla] can then be used to
integrate these loosely coupled systems. The distributed components of the business component also fit into a
component execution environment (CEE) [Herzum, Sims]. When SBA is used, the concept of deploying software to
a specific infrastructure (as in CEE) is no longer required [Van Zyla]. The SBA does not attempt to replace the
business component model, but rater place it in a SBA perspective.

                   Application                      Dynamic                             Client
                    Clients                          HTML                                tier

                                                                                      Web Tier
                    Enterprise                      Enterprise
                   Beans/COM                       Beans/COM

                     Database                       Database

                                         Figure 2: J2EE Logic Tier Model

                        Service A
                                                                                               Service B

       Loose coupling

                            Process Manager
       via standard

                                                                                        Business Components consisting of
                                                                                             distributed components

                          Figure 3: Service Based Architecture, adopted from [Van Zyla]

Service A in Figure 3 may consume the services provided by multiple distributed components within the business
component. Components that are not necessarily part of a specific business component may also be accessed.
Service A may access these different components through a process manager. The functions required to provide the
actual service are coupled via standard transport technologies. Service B illustrates yet another service accessing a
database from its resource distributed component(s).

Comparing the intricate details of language specifications within J2EE and the .NET framework is beyond the scope
     scope of this paper. Rather than venturing beyond the scope, it is more important to analyze the relationships
                                          between the tiers presented in Figure 1
    Figure 1: Taken from [Herzum, Sims] and view it within the SBA.
    It is required to establish the different technical levels on which J2EE and .NET will be evaluated. The concept
of different levels of abstraction introduces the separation continuum (see Figure 4, page 4).
    The separation continuum can be defined as “a systemic view of a system to understand its parts and their
relationship, through understanding vertical and horizontal continuums needed where abstraction and
implementation are on the vertical continuum, and human and machine facing aspects to have attributes of
adaptability, context and relevance are on the horizontal continuum.” [Van Zylb]

                                              Figure 4: The Separation Continuum [Van Zyla]

    The continuum described above is separated into a horizontal and vertical continuum. The horizontal continuum
is focused on the “customer facing aspects” and “the infrastructure facing aspects”, where the vertical continuum
considers the different levels of abstraction for a given business model. This paper will use the different aspects
describes in the horizontal continuum to structure .NET and J2EE technologies.

     According to the horizontal continuum, J2EE and .NET provide similar and yet significantly different
technologies on the following levels:
    i.   User interfaces (User tier) - This is the interface used by the user to interact with a system
   ii.   User interface controllers (User/Workspace Tier) - The controller manages the behavior of the interfaces
         that connect to the business logic layer.
  iii.   Connection between the tiers (All tiers) - The connections refer to the ability of the user interface to
         connect to a server that directs the way the interface is used.
  iv.    Business logic (Workspace/Enterprise Tier) - Business logic refers to the ability to have a cluster of
         services exposed to the user interface.
   v.    Data (Resources and applicable tiers) - The data layer refers to the ability to reliably store data used in the
         business logic layer [Van Zylb].

The horizontal continuum and its elements are illustrated in Figure 5 (page 5). As the continuum moves horizontally
from the visual to non-visual sphere, the different elements are encountered. These elements occur strictly on the
technical levels of the continuum – these levels are also referred to as the implementation levels.
    The subsequent sections in the paper will analyze the comparison between J2EE and .NET according to mapping
of the provided technologies to the horizontal continuum, and how the technologies realize and interconnect the
separate tiers. Not all tier interactions are applicable to every solution. Standalone applications and distributed
architectures utilize the interconnections between the indicated tiers as best suited to the business solution.

                                       UI           UIC       BL      C          D

                           Figure 5: The horizontal continuum (adapted from [VanZyl b])

The following sections will capture each of the comparative elements and expand them by describing the
technologies provided by J2EE and .NET

4     J2EE and .NET Technologies in the Horizontal Continuum
This section as described above focuses on provided technologies in the horizontal continuum. Illustrations are
provided (where appropriate) to assist clearer technological classifications. Where J2EE and .NET share
technologies (e.g. open standard technologies) additional shared categorization will be introduced. Basic
descriptions of the function of each of the tiers are given to support the context.

4.1    The User Interface

                                                          Differing Technologies
                             Shared Technologies
                                                          J2EE            .NET

                              HTML                      Swing / JFC    Web Forms
                              XML                       Java Beans     Window Forms
                              WML                       Applets        MFC
                              DHTML                                    ActiveX
                                         Table 1: User Interface Technologies

The user interface operates on the user tier. The user tier can, depending on the application structure, access different
tiers (if necessary) in order to fulfill the business function. J2EE and .NET provide shared as well as separately map-
able technologies (mapped to the separation continuum described in section 3).


                              Figure 6: The User Interface. Adopted from the [Van Zylb]

4.1.1     Web Standards: Shared Technologies
Web standard interface technologies are generated from interface controller processes located on a server
(client/server models). HTML (as an example) can be produced by .J2EE interface-controller technologies like Java
Server Pages (JSP), Servlets and .NET technologies like Active Server Pages (ASP.NET)). [J2EE Tutorial] and
[ASP.NET Developer Guide].

                                             Shared UI Controller
                                             Technologies                               Other elements of
                    Mobile                                                              the horizontal
                    Device                                                              continuum

                                     Figure 7: HTML generated from Server Tier

    The boundary indicated in Figure 7 describes the logic separation the user interface controller has from business
logic on the physical server.


                    XML + XSL



                              Figure 8: The User Interface. Adopted from the [Van Zylb]

Figure 8 illustrates open standards that form part of the user interface dimension. These technologies supply user
interfaces to a range of clients including browsers and mobile devices.

4.1.2   J2EE Interface technologies
J2EE provides the following user interface technologies:

                      Java Foundation


                        Java Beans

                              Figure 9: The User Interface. Adopted from the [Van Zylb]

Swing/ Java Foundation Classes (JFC) - The JFC and Swing API provide a wide variety of graphical user controls
that can be used in both standalone and distributed applications (with reference to the use of Swing/JFC Applets in
the distributed environment).
    These components are written without operating system-specific code. This facilitates a flexible graphics API
without directly relying on the native windowing system. This is achieved by a Java Runtime Environment (JRE)
produced specifically for separate operating systems. Swing is a graphical user interface (GUI) component kit that is
part of the Java Foundation Classes (JFC), integrated into the Standard Edition Java platform (J2SE). [Swing JFC]

Java Beans - Java Beans are a reusable software component that can be manipulated using bean builder tools. The
Java Bean components can be used in various different graphic applications and are interchangeable [Java Bean].

Applets - Applets are Java applications that run within a browser environment (requiring an additional Java add-on
option for the internet browsers). Applets can utilize the full range of graphic libraries offered by the Java SDK
version on which it is built. Applets have the appearance of standalone applications (using JFC/Swing) but are used
in a distributed environment. Applets possess standalone application characteristic in the sense that the application
load (processing normally handled by servers) can be delegated to applets.

4.1.3   .NET Interface Technologies
Microsoft .NET provides the following interface technologies:

                         Window Forms


                            Figure 10: The User Interface. Adopted from the [Van Zylb]

Window Forms - Window forms form part of the .NET standalone applications. These applications can access back-
end (resource and enterprise) tiers without necessarily having to pass through intermediate middle-tiers. The form
libraries can be accessed by the multiple supported .NET framework languages (like Visual Basic 7.0, C#).

Microsoft Foundation Classes (MFC) - MFC provides functionality that extends beyond just interface technologies.
MFC provides graphical components that can be used in standard interface application. MFC, though still existent, is
replaced by Window forms.
   The MFC Library is a collection of classes that can be used in building application programs. The classes in the
MFC Library are written in the C++ programming language. It provides an overall framework for developing
applications. There are MFC Library classes for all graphical user interface elements (windows, frames, menus, tool
bars, status bars, and so forth), for building interfaces to database, for handling events such as messages from other
applications, for handling keyboard and mouse input, and for creating ActiveX controls. [Def MFC]

ActiveX - An ActiveX control is an embeddable object that can be re-used by many application programs within a
computer or among computers in a network. The technology for creating ActiveX controls is part of Microsoft's
overall ActiveX set of technologies, chief of which is the Component Object Model (COM). ActiveX controls can
be downloaded as small programs or animations for Web pages, but they can also be used for any commonly-needed
task by an application program in the latest Windows and Macintosh environments. In general, ActiveX controls
replace the earlier OCX (Object Linking and Embedding custom controls). An ActiveX control is roughly
equivalent in concept and implementation to the Java applet. [Def ActiveX]

4.2    Interface Controller

                   J2EE                                            .NET

                   Thin Client          Thick Client               Thin Client           Thick Client
                   Servlets           JFC Applications      ASP.NET         MFC Applications
                   JSP                Applets                               Windows Forms
                   JavaServer Faces
                                 Table 2: User Interface Controller Technologies

This section describes the User Interface Controller dimension of the horizontal continuum illustrated in Figure 10.
The interface controller can be described as a logically separated mechanism that generates/presents the user
interface, responds to user interactions, and accordingly acts as “mediator” between business logic in subsequent
tiers. The update made by the controller is then updated on the user tier (Figure 12).


          Figure 11: The User Interface Controller in the Horizontal Continuum. Taken from [Van Zylb]

   The interface controller can operate on the client tier and the server tier, depending on the integration of the
multi-tiers (thick vs. thin clients). The interface controller can also be seen from the perspective of pattern
implementations (MVC, MVC2). In the Model View Controller (MVC) the controller can be seen as handling
model state updates and view changes. [MVC] and [Java Blueprints]

                                         s               User                Uses

                                                View                  Interface

                                                         Model spanning
                                                         back-end tiers
                                        s                                           Modifies

         Figure 12: Graphic description of the User Interface Controller using MVC. Adopted from [MVC]

4.2.1   J2EE Interface Controller
The industry relies on many types of development patterns to rapidly implement proven solutions. One such pattern
(mentioned in the introduction) is the Model-View-Controller.

                                                            Model and controller
                                                            technologies are provided
                                                            by servlets, JSP and
                                               M            JavaServer faces

                                       V                C

                    Figure 13: Logic view of Model-View-Controller (Adopted from [Kassem])

    Two major separations can be made when considering, controller technologies – thin, thick and standalone

Thick Clients or Standalone
JFC/Swing - A thick client can make use of JFC/Swing applications to implement controller logic. Applets can be
used in the browser environment, where the interface controller is embedded within the application itself.
JFC/Swing controls the controller processes much like server tiers control enterprise controller processes.
Thin Clients
Java Servlets - Servlets, as the name suggest, are like server-side applets that handle requests and constructs
responses. Interface control logic is implemented in Java and is encoded in the servlet.

Java Server Pages (JSP) - J2EE provides Java Server Pages (JSP) that function on the workspace tier. JSP executes
as a servlet and is well-suited for creating both static and dynamic display content.

JavaServer Faces - With JavaServer faces, reusable components can be assembled in a page, connected to
application data sources, and wired to client-generated events handled on server-side event handlers [JavaServer

Figure 13 illustrates where J2EE controller technologies will fit into a design pattern instance of the model-view-
controller. JSP, Servlets and Java Server faces. JSP, Servlets and JavaServer Faces are presented in HTML on the
user interface on the user tier.

4.2.2    The .NET interface controller
The .NET interface controller may be located on different tiers (user or workspace) depending on the client type.
Client types include:

                                                               Model and controller
                                                               technologies are
                                                               provided by ASP.NET.

                                        V                  C

  Figure 14: Logic view of Model-View-Controller with .NET controller technologies. (Adopted from [Kassem])

Thick client or Standalone
Window Forms - The .NET framework has its own set of graphic libraries for creating standalone or thick client
applications. Interface controller processes are built into the graphic libraries and enables using of standard event
models or custom built MVC type processes.

Microsoft Foundation Classes (MFC) - The MFC is a set of libraries written in the programming language C++.
MFC supports graphics and event systems that act as the interface controllers. MFC can be for application building
and can be used via C++. The MFC is not part of the core .NET framework, but is only provided with Microsoft
Visual Studio .NET. The controller logic is normally merged with the user interface in standalone applications.
Thin client
ASP.NET Webforms - Webforms are constructs that are hosted on the server side of enterprise applications. Web
forms can contain web or html controls. These controls can be run on the server and accordingly handle all events
attached to them at the server. HTML is generated through ASP.NET to serve the user tier browsers.
    ASP.NET also enables the use of actual ASP syntax within the code that could also optionally serve as the
controller logic.

Figure 14 brings the interface controller technologies provided by .Net into perspective, by applying MVC.

The technologies provided by both J2EE and .NET serve the purposes of the interface controller concept. The
interface controllers can also contain logic to ultimately access the business logic dimension of the horizontal

4.3    Business Logic

                J2EE                                        .NET
                Enterprise Java Beans (EJB)                 COM and COM+ as Enterprise Services
                Java stored procedures                      Stored Procedures
                Servlets                                    MFC Applications
                JSP                                         Windows Forms
                JFC Applications                            ActiveX
                                        Table 3: Business Logic Technologies

Business logic can be described as the processes that execute mainly on the either or both the controller and business
logic dimensions on the horizontal continuum [Van Zylb]. The business logic includes core business aspects like
business rules, validation and interaction among components. Business logic can also be implemented on standalone
applications that bypass the business tiers and communicate directly with the resource tier.


           Figure 15: Business Logic dimension in the Horizontal Continuum. Adopt ed from [Van Zylb]

4.3.1    J2EE Business Logic
Enterprise applications typically access business logic through interface controller processes. In the context of J2EE
this would typically mean that components and services are called, though the initiation of actions by users.

JSP and Servlets - Depending on the structure of the enterprise application, business logic can be contained within
JSP pages or Servlets. If a typical separation between controller logic and actual business logic exists, JSP or
Servlets are able to access these tiers through J2EE container technologies. This concept is simplistically illustrated
in Figure 16.

                                         JSP, Servlets and          Enterprise Java
                                         JavaServer Faces               Beans

       Figure 16: Access of Business across logic Tiers. Adopted illustration using [Kassem] and [Van Zylb]

Figure 16 also introduces the concept of connections described in the section 4.4. JSP and Servlets can access
Enterprise Java Beans using interfaces.

Enterprise Java Beans (EJB) - EJBs are components that implement business rules and ultimately form part of
transaction sequences to realize the concept of business. EJBs can come in different forms – each of the forms
represents a stateless of stateful transaction type. Stateful EJBs can store data about transactions persistently or just
keep state during single transactions. Message EJBs will be discussed in the section on connections. EJB also
possess mechanisms that allow access to the functionality that they implement. These mechanisms consist of remote
interfaces and interfaces allowing the EJBs to be activated for use. EJBs exist on J2EE software servers and can be
accessed on the servers through the described interfaces. J2EE enables EJBs to manually implement persistent
storage accesses or automatically execute database related operations through the EJB container illustrated in Figure

Stored procedures - Stored procedures are procedures that could contain program flow, logic and queries against
databases. EJBs work tightly with the data dimension in the horizontal continuum and can delegate logic to the data

4.3.2    .NET Business Logic
Several technologies exist that can be used to implement the business logic aspect within .NET applications. The
Component Object Model (COM and COM+) is one such technology that defines the fundamental structure for
technologies (using COM) to implement business logic. Certain interoperability and migration possibilities exist
between .NET and COM+, enabling COM+ to function within the .NET environment. COM+ is called Enterprise
Services within the .NET framework. The following business logic options are provided:

Browser Assemblies - Business logic, when implemented in the interface controller dimension can be created by
using the ASP.NET code behind sections for ASP.NET pages. ASP.NET separates the graphics from the logic, yet
enables the implementation of both on the same level. [Chappel, Kirk]. ASP.NET logic can access business logic
though Enterprise Services interoperability.

                            Business                                            Business
                            Logic through                                       Logic through
                            assemblies                                          managed
                                            ASP.NET              Enterprise

            Figure 17: Business Logic in the UIC and BL dimensions in .NET. Adopted from [Van Zyla]

Enterprise Services - Interoperability and execution in the .NET framework requires management. This management
refers to the concept of runtime management in the common language runtime (CLR) described in section 1.
Component Object Model (COM+) components that contain business functionality are by nature unmanaged. To
ensure interoperability, .NET requires Common Language Specification compliance - Enterprise Services are
provided for managed COM+ in the CLR. To access to COM services it is required to register the component in the
Windows registry – this will allow exposure of COM services through COM interfaces within the context of
Enterprise Services. [Enterprise Services COM+] and [MWC]

Stored Procedures - When considering business-logic implementation on the back-end tiers, stored procedure can be
used. When accessing the database one can store the programs locally and create applications that send the
commands to a server and process the results, or stored procedures can be utilized. Stored procedure executes on the
resource tier level. Application A illustrates ASP.NET on the middle tier for business logic, and the use of stored
procedures on the resource tier. Application B represents standalone Windows form applications that have the
ability to access high level tiers. .NET does not provide client side web access to high level tiers as a rule, instead
ActiveX and COM+ can be used to provide client business logic. [Chappel, Kirk]

4.4     Connections

              Shared Technologies                                  Differing Technologies

              Connection Protocols:      Messaging Protocols:      J2EE                .NET
              HTTP                       SOAP                     JDBC                 .NET Remoting
              TCP/IP                                              RMI-IIOP             DCOM
                                                                  JNDI                 MSMQ
                                                                  JMS                  ADO.NET
                                         Table 4: Connections Technologies

Connections function like “glue” between different logical and physical distribution tiers. Figure 18 indicates the
position of the connection dimension in the horizontal continuum. The different logic dimensions in the continuum
can be connected using the following base technologies:


                   Figure 18: The Connections Dimension in the Horizontal Continuum [Van Zylb]

     Internet and web service based technologies - This category includes all the connection technologies that are
      based on open standard and are designed for distributed communication between different types of systems.
     Underlying connection technologies inherent to platform infrastructures - These technologies are high
      dependency connection technologies. Typically these technologies are platform specific and are contained
      within the underlying platform infrastructures to allow different system platform entities to communicate.
     Database connectivity technologies - Database connectivity technologies include all technologies that are used
      to access and interpret CRUD (Create, Read, Update, and Delete) database operations. These connection
      technologies are typically used between the business logic and data dimension as illustrated in the horizontal
      continuum (Figure 5). Service Based Architectures (SBA) [Van Zyla] and the degree of coupling were
      introduced in section 3. SBA is built on top of more technical implementation layers as illustrated in the
      separation continuum (Figure 4) [Van Zylb]. The connection technologies can be further subdivided using
      additional coupling categories:
     Tightly coupled connection technologies - This includes database and infrastructure connection technologies
 Loosely coupled connection technologies - This includes internet and web service based technologies.
The following subsection will describe the connection categories as well as the degree of coupling.

4.4.1    Internet and Web Services Connection Protocols
Internet and web service communications allow connection on service architecture levels as indicated in Figure 19.
Service architectures can be constructed using loosely coupled technologies provided by open standards and
additional platform specific mechanisms.

                     Figure 19: Service Architectures in the Separation Continuum [Van Zyla]

Shared Internet and web service Connection technologies
   Hypertext Transfer Protocol (HTTP) - HTTP is a set of rules (a protocol) for exchanging text, graphic images,
    sound, video, and other multimedia data types on the World Wide Web. HTTP is an application protocol. Web
    servers contain HTTP daemons that handle HTTP requests. Requests are commonly generated from a browser
    environment where a request is built and sent over the Internet Protocol (IP) indicated by Universal Resource
    Locaters (URLs). [Def HTTP]. The HTTP protocol is used to connect distributed clients (the user interface
        In distributed applications, HTTP is the common connection technology used between client tiers and
    server tiers. Figure 22 also indicates the addition of wireless devices. Although the J2EE core packages do not
    include mobile extensions, J2ME extensions allow interaction with the J2EE server.
        These clients also utilize browser technology for HTTP communication. .NET mobile extensions also allow
    mobile connection via HTTP in Figure 21.
   Transmission Control Protocol over Internet Protocol (TCP/IP) - The TCP protocol over IP is used to route
    information between different nodes in a network. IP handles the actual data delivery while TCP controls the
    reassembly of individual data units. TCP is a connection-oriented protocol, which implies that a connection is
    established and maintained until such time as the message or messages to be exchanged by the application at
    each end have been exchanged. [Def TCP]. This is also a physical network transport protocol and can be
    considered the base on which all internet and web services connections are routed on. The choice of this
    protocol normally lies with the operating system settings and not with the J2EE or .NET

The concept of HTTP and TCP/IP is illustrated in figure 16.

                                                   connection                            Server

                                                  Routed using
                                                   TCP/IP or

                                      Figure 20: HTTP using TCP/IP routing

Simple Object Access Protocol (SOAP) - SOAP can be described as a method of communication between any two
platforms using HTTP and XML as the mechanisms of information exchange. SOAP provides the definition of an
XML document which can be used for exchanging structured and typed information between peers in a distributed
environment. SOAP is a stateless, one-way message exchange paradigm, but applications can create more complex
interaction patterns (e.g., request/response, request/multiple responses) by combining such one-way exchanges with
features provided by an underlying transport protocol and/or application-specific information. SOAP is also
designed to be extensible. SOAP provides a full description of the expected actions taken by a SOAP processor on
receiving a SOAP message. [Def SOAP] and [SOAP]SOAP is similar to the IIOP (described in 4.4.2), a protocol
that is part of the Common Object Request Broker Architecture (CORBA).

Web Service Description Language (WSDL) - WSDL is a service definition structure based on XML. Higher level
dependant systems can use WSDL to describe services in terms of inputs, outputs and types for transmission
purposes. WSDL is standard a description [W3C WSDL] and allows multiple organizations owning different highly
integrated systems to expose their services publicly. These services are listed via service brokers like Universal
Description Discovery and Integration (UDDI). Figure 21 illustrates the concept of organizations listing their
services with a service broker.


                                           Services A      Services B

                                 Organization A                         Organization B
                                     J2EE                                   .NET

                                    Figure 21: Registering services with UDDI

J2EE and .NET provide mechanisms (builder and compiler tools) to expose WSDL descriptions from their separate
platforms. J2EE and .NET also provide ways to interpret WSDL and utilize the descriptions in the form of proxy
generation processes. WSDL can be interpreted by the native system and broker listed services can be called or
accessed via proxies in native platform languages.
J2EE Specific Internet and web service connection technologies
A holistic view of the internet connections can be seen in Figure 22 Section 4.4.1 described the shared internet and
web service connection technologies provided by both platforms.
   The logical dimensions of the horizontal continuum are clear when studying sections 4.1 through to 4.3. The
connections in J2EE according to Figure 22 are:

Electronic Business XML (ebXML) - Figure 23 shows ebXML as a connection technology to other systems in the
user interface and user-interface-controller dimensions as well as the back-end business logic and data dimensions.
EbXML is a project focused on using XML to standardize the secure exchange of business data. EbXML is designed
to enable a global electronic marketplace in which enterprises can transact business through the exchange of XML-

based messages. EbXML relies on the Internet standards such as HTTP, TCP/IP, MIME, SMTP, FTP, UML, and
XML and can be implemented and deployed on many computing platforms [def ebXML]. Figure 23 describes a
process of communication between two companies using ebXML. SOAP as a messaging protocol can currently only
transport specific data types – ebXML aims to address this limitation by defining a standard for complex business
data types.

                                              Applet                                      Wireless
                        Other Systems       Applications        Web Browsers              Devices
       Client Tier

                           WS Technology          IIOP                        HTTP

                              Servlets                                         JSP
                                                                   EJB                                 Connections


        Systems              Proprietary          SQL           Proprietary          WS Technology

                          Repository         Databases           legacy and            Other Systems
                                                                ERP systems

            Figure 22: J2EE internet/web service connections. Adapted illustration taken from [MWC]

                Business Scenarios                      1
                 Business Profiles
                                                            Request Business Details
                                                                                                               COMPANY A

                                                                                              Build Local System
              ebXML                        3                                                  Implementation
                                                Register Implementation Details
                                                Register COMPANY A Profile













                                                                                         nB                                   S

                                                                                       eo                              ON

                                                                              5      re                              TI




                                                                                                          TR              6
                                                                                                   S  S
                     COMPANY B                                                              SI
                                               ebXML compliant

Figure 23: High level overview of the interaction of two companies conducting eBusiness using ebXML (taken from
                                                [ebXML overview]).

J2EE RPC/Messaging - The technologies described below are contained within APIs on the component and object
implementation levels. JAX-RPC and JAX-R are described here as they are used for service architecture level

The Java API for XML-based RPC (JAX-RPC) - RPC (Remote Procedure Call) mechanism enables a remote
procedure call from a client to be communicated to a remote server. In XML-based RPC, a remote procedure call is
represented XML based protocols. An XML-based RPC server application can define, describe and export a web
service as an RPC based service. WSDL (described earlier) specifies an XML format for describing a service as a
set of endpoints operating on messages. An abstract description of such service can be bound to an XML based
protocol and underlying transport. A service client invokes an RPC service. The JAX-RPC supports creation of a
dynamic proxy for invoking a service endpoint. A dynamic proxy class supports a service definition interface
dynamically at runtime without requiring any code generation of a stub class that implements a specific service
definition interface.

Java XML Registry - There are different Java technologies that can be combined to provide support for web services.
JAX-RPC (described above) provides support for web service calls using SOAP/HTTP. JAX-RPC defines the
mapping between Java classes and XML. The J2EE specification defines the deployment of web service clients and
web service endpoints in J2EE, as well as the implementation of web service endpoints using enterprise beans. The
Java API for XML Registries (JAXR) provides client access to XML registry servers [J2EE 1.4 Specification].
JAXR eliminates the dependence of specific registry implementations. [JWSU – Haines]

Java API for XML Processing (JAXP) - JAXP is utilized to interpret XML documents and is important because
interaction between Web Service is mainly in XML document format. These XML documents contain sufficient
document type definitions (DTD), root and sub-elements as well as comments and processing instructions (when
more than one host is used in communications). [JWSU - Haines]

Java API for XML Binding (JAXB) - JAXB serves as a mechanism to enable two-way mapping between XML
documents and objects.

   JAXB uses DTD and XML binding schemas to generate a set of classes that are able to modify XML document
content in terms of the DTD. [JWSU - Haines]

Java API for XML Messaging (JAXM) - JAXM facilitates XML document exchange. JAXM supports SOAP-style
messaging and can be used in conjunction with different transport protocols like HTTP and MSMQ. Inherent
support is provided for simple HTTP transport. [JWSU - Morrison].
.NET specific Internet and web service connection technologies
Figure 24 similarly explores internet and web service based connection technologies for .NET [MWC]

                                            Window Form                                  Wireless
                         Other Systems      Applications          Web Browsers           Devices
        Client Tier

                            WS Technology                                       HTTP

                                              .NET Managed Components                                  Connections

                                                  Integration Server

         Systems           WS Technology          SQL             Proprietary      WS Technology

                         .NET Passport       Databases            Mainframes           Other Systems

    Figure 24: NET Internet and Web Services Connection Technologies. Adapted illustration taken from [MWC]

    Specific technologies inherent to the internet and web service connections for .NET basically include BizTalk
    BizTalk Server - BizTalk is an initiative to promote XML as the common data exchange language for e-
     commerce and application integration on the Internet. BizTalk servers connect businesses owning different
     system technologies. XML is a platform-neutral way to represent data transmitted between computers – the
     BizTalk Framework describes how to publish XML schema data structures and how to use XML messages to
     integrate software programs. The BizTalk Server enables integration with third party systems through adapter
    ASP.NET and .NET remoting - ASP.NET has support for SOAP-callable XML Web services. Both the .NET
     Remoting HTTP channel and the ASP.NET support for XML Web services implement SOAP. The two
     implementations are distinct, however, and each is intended for a specific purpose. .NET Remoting focuses on
     preserving the exact semantics of the common language runtime, and so is the best used when the remote
     system is also running the .NET Framework. ASP.NET focuses on providing standard XML Web services, and
     is preferable when the remote system is .NET-based or any other platform. ASP.NET is faster than the .NET
     Remoting HTTP channel.

4.4.2    Connection technologies inherent to platform components and infrastructures

 Figure 22 and Figure 24 also illustrates connection technologies that are more platforms specific. In the context of
                      enterprise applications implemented on component based paradigms (

Figure 1: Taken from [Herzum, Sims]), more dependant or tightly coupled connection technologies reside within the
platform infrastructures.
    The following subsections will describe J2EE and .NET connections using the component architecture indicated
in the separation continuum (Figure 25).

                                 Figure 25: The Separation Continuum [Van Zyla]

J2EE infrastructure and component connection technologies
J2EE provides a vast number of built in or additional packages that provide the enterprise (or component) tiers with
different ways to communicate. Some of the following technologies are also displayed in Figure 22 and Figure 24.

J2EE Servers - The scope of this paper does not extend to describing different servers implemented by different
vendors. J2EE is a specification aimed at creating J2EE cross compatibility for different J2EE implementations
which justifies describing the standard specification technologies only. The term server explained here refers to the
underlying infrastructure that components exist in. J2EE server provides differs containers for different type of
software components. Figure 25 illustrates J2EE container infrastructures.

                                                          J2EE Server

                           Applet         Web Container          EJB Container   Application
                          Container                                              Container

                           Applets            Servlets,                 EJBs       Application
                                                JSP                                  Client

                                           Additional Container APIs

                  Figure 26: J2EE Server and Containers. Adopted from [J2EE 1.4 Specification]

    As Figure 26 illustrates, J2EE Containers are built on the Java 2 Standard Edition (J2SE). The additional APIs in
the separate containers enable J2EE functionality. The additional APIs will be described in the context of component
and inter-component connections.
   IIOP - Applets are downloadable applications with JFC/Swing support. Browser technologies normally use
    HTTP to connect, while standard application or applets can use Internet Inter-ORB Protocol (IIOP). IIOP is a
    connection protocol that enables different technologies (different programs constructed in different
    programming languages) to communicate over the Internet. IIOP is part of an industry standard, the Common
    Object Request Broker Architecture (CORBA) [def IIOP]. Software bridges between IIOP and other
    technologies not based on CORBA can also be constructed to ensure interoperability. Figure 22 illustrates the
    concept of IIOP connection. IIOP is considered a component layer technology as it does not make use of open
    internet standards (XML-Based).
   RMI-IIOP – Remote Method Invocation over Internet Inter-Orb Protocol - RMI is used in Client-Server type
    applications - server application create a remote object and reference to the object. Clients can access the object
    and its related functions by using the reference. RMI run over RMI-IIOP delivers Common Object Request
    Broker Architecture (CORBA) distributed computing capabilities to J2EE. RMI over IIOP enables the creation
    of remote interfaces in the Java programming language and implement them using only Java technology and the
    Java RMI APIs. These interfaces can be implemented in any other language that is supported by an OMG
    mapping and a vendor supplied ORB for that language. Similarly, clients can be written in other languages
    using IDL derived from the remote Java technology-based interfaces. Using RMI over IIOP, objects can be
    passed both by reference and by value over IIOP.
   JNDI – Java Naming Directory Interface - The Java Naming and Directory Interface (JNDI) is a standard
    extension to the Java platform, providing Java technology-enabled applications with a unified interface to
    multiple naming and directory services. As part of the Java Enterprise API set, JNDI enables seamless
    connectivity to heterogeneous enterprise naming and directory services.

                                        Figure 27: JNDI taken from [JNDI]

       Figure 27 shows the basic layering of the directory and naming service. JNDI provides access to directory
    objects (such as printers) through multiple naming facilities. Applications can attach their own object to a
    namespace and JNDI handles lookup and retrieval services transparently. [JNDI]
   JMS – Java Messaging Service - The Java Message Service is an API that allows applications to create, send,
    receive, and read messages. The JMS API defines interfaces and associated semantics that allow programs and
    systems to communicate with other messaging implementations. The JMS technology connects different
    systems via its messaging system.
         Mechanisms provided allow binding of destinations and connection factories into a JNDI namespace. JMS
     clients can look up administered objects and then establish a logical connection to the same objects through the
     JMS provider.

                                        Figure 28: Taken from [JMS]

      Figure 28 illustrates the basic JMS architecture. The JMS [JMS] application elements can be described as
-          A JMS provider is a messaging system that implements the JMS interfaces and provides administrative
        and control features.
-          JMS clients are the programs or components that produce and consume messages.
-          Messages are the objects that communicate information between JMS clients.
-          Administered objects are preconfigured JMS objects created by an administrator for the use of clients.
-          Native clients are programs that use a messaging product's native client API instead of the JMS API.
      Two message domains are supported, namely point-to-point (PTP) message domains and Publish/Subscribe
  Messaging Domain.

                                        Figure 29: Taken from [JMS]

     PTP applications are built around the concept of message queues, senders, and receivers. Each message is
  addressed to a specific queue, and receiving clients extract messages from the queues established to hold their
  messages. Queues retain all messages sent to them until the messages are consumed or until the messages
  expire. Each message has only one consumer.
-          A sender and a receiver of a message have no timing dependencies. The receiver can fetch the message
        whether or not it was running when the client sent the message.
-          The receiver acknowledges the successful processing of a message. In publish/subscribe applications
        clients address messages to a topic. Publishers and subscribers are generally anonymous and may
        dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the
        messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages
        only as long as it takes to distribute them to current subscribers (Figure 30)

                                          Figure 30: Taken from [JMS]

   Resource Adapters - Resource adapters are system-level software components [Herzum, Sims] that implements
    network connectivity to external resource managers. A resource adapter can extend the functionality of the
    J2EE platform either by implementing one of the J2EE standard service APIs, or by defining and implementing
    a resource adapter for a connector to an external application system. Resource adapters interface with the J2EE
    platform through the J2EE service provider interfaces (J2EE SPI) [J2EE 1.4 Specification].
   JCA – J2EE Connector Architecture - The J2EE Connector architecture provides a solution of connectivity
    between the many application servers and Enterprise Information Systems (EIS) already in existence. JCA
    enables all vendors that conform to JCA to eliminate the creation of custom code when required to add
    connectivity to new Information Systems.

                                      Figure 31: Taken from [JCA Sharma]

.NET infrastructure and component connection technologies
The .NET framework also uses a server technology as the underlying infrastructure. The Internet-Information
Services (IIS) server acts as the hosting structure for ASP.NET web applications, XML web services and remote
objects. The basic architecture is illustrated in Figure 32.


                                          ASP.NET            Remote objects

                                       .NET Framework                    IIS

                                                    Windows OS

                                    Figure 32: IIS Server framework and .NET

Servers - .NET includes many Enterprise servers to enable communication with legacy and other systems. A brief
description of these servers is given below:
   SQL Server 2000 - as the relational database.
   Exchange 2000 Server - is a messaging and collaboration platform used for developing and running core
    business services and is tightly integrated with Windows operating Systems.
   Commerce Server 2000 - allows development and deployment of customizable online e-commerce solutions.
   Application Center Server 2000 - Application Center Server 2000 allows the management of clustered servers.
   Host Integration Server 2000 - provides access to selected legacy systems running on other platforms.
   Internet Security and Acceleration (ISA) Server 2000 - offers firewall and Web caching capabilities.
   BizTalk Server 2000 - is an XML-based collaborative e-business solution for integrating applications, trading
    partners and business processes via the Internet (mentioned earlier)

                                       Figure 33: .NET Remoting structure

      Remoting enables the access to remote objects as if the objects were locally retrievable.
          .NET Remoting provides both a TCP channel and an HTTP channel for communication mainly between
      client and web tiers [Srinivasan]. .NET Remoting provides the following features:
    -          A framework that allows objects to interact with one another across application domains
    -          A number of services, including activation and lifetime support, and communication channels that
            transports messages to and from remote applications.
    -          Formatters that are used for encoding and decoding messages before they are transported by the

                                    Client            HTTP/S                          Remoting
                                                       OAP                             Object


                     Figure 34: .NET Remoting using HTTP/SOAP. Taken from [Srinivasan]

XML encoding is used where interoperability with other remoting frameworks is essential. All XML encoding uses
the SOAP protocol in transporting messages from one application domain to the other. Binary encoding can be used
as an alternative.

                                    Client             TCP/                          Remoting
                                                      Binary                          Object


                     Figure 35: .NET Remoting using HTTP/SOAP. Taken from [Srinivasan]

    Typical .NET Remoting scenarios:
          Client                             Server                                  Payload           Protocol

          .NET Component                     .NET Component                          SOAP/XML          HTTP
          .NET Component                     .NET Component                          Binary            TCP

                                             .NET Web Services                       SOAP/XML          HTTP

                                             Unmanaged                               NDR
          .NET Component                     Classic COM                             (Network Data     DCOM
                                             Component                               Representation)
          Classic COM                                                                NDR               DCOM
                                             .NET Component
                                              Table 5: Taken from [Srinivisan]

   Distributed Component Object Model (DCOM) - DCOM is a set of concepts and program interfaces in which
    client objects can request services from server objects on other computers in a network. DCOM is based on the
    COM, which provides a set of interfaces allowing clients and servers communication on the same computer.
    DCOM is not part of the core framework. .NET remoting can be considered to be the DCOM of the .NET
    framework, yet several architectural differences exist [Chappel, Kirk]
         Processing can be done on separate and more specialized servers using DCOM interfaces. DCOM interfaces
     allow Remote Procedure Calls (RPC) to specialized server objects, which in turn do processing and sends the
     result back to the caller of the procedure. Results can (depending on the structure of the tier interaction) pass
     results to a client for viewing.

       DCOM can operate on a multiple variety of networks, including enterprise, public and other than public
    type networks. DCOM utilizes TCP/IP and HTTP as a means of transfer and connection between systems. [Def
   Microsoft Message Queuing (MSMQ) - MSMQ enables applications running at different times to communicate
    across diverse networks and systems that may be temporarily offline. Applications send messages to queues and
    read messages from queues. MSMQ provides guaranteed message delivery, routing, security, and priority-based
    messaging. It can be used to implement solutions for both asynchronous and synchronous scenarios.

4.4.3    Database connectivity technologies
Database connections are normally established using driver APIs. This subsection will consider J2EE and .NET
database connection technologies.
J2EE Database Connectivity Technologies
   JDBC: Java Database connectivity - JDBC is an API that allows access to tabular data sources. It provides
    cross- Database Management System (DBMS) connectivity to a wide range of SQL databases, and it also
    provides access to other tabular data sources, such as spreadsheets or flat files. JDBC can be used as a
    connection technology between the client and web tier to the resource tier.

                                Figure 36: JDBC Connectivity. Taken from [JDBC]

JDBC API contains two major sets of interfaces: the first is the JDBC API for application writers, and the second is
the lower-level JDBC driver API for driver writers. JDBC technology drivers fit into one of four categories.
Applications and applets can access databases via the JDBC API using pure Java JDBC technology-based drivers, as
shown in Figure 36 [JDBC].
   -         JDBC-ODBC Bridge plus ODBC Driver: This combination provides JDBC access via ODBC drivers.
          ODBC binary codes (like database client code) - must be loaded on each client machine that uses a
          JDBC-ODBC Bridge.
   -         A native-API partly Java technology-enabled driver: This type of driver converts JDBC calls into calls
          on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Like the bridge driver, this style of
          driver requires that some binary code be loaded on each client machine.
   -         Pure Java Driver for Database Middleware: This style of driver translates JDBC calls into the
          middleware vendor's protocol, which is then translated to a DBMS protocol by a middleware server. The
          middleware provides connectivity to many different databases.
   -         Direct-to-Database Pure Java Driver: This style of driver converts JDBC calls into the network
          protocol used directly by DBMSs, allowing a direct call from the client machine to the DBMS server and
          providing a practical solution for intranet access.

   Java Data Objects (JDO) - JDO is an API for transparent database access. JDO provides transparent accesses to
    the underlying data store, without database-specific code. JDO is a technology that is complementary to the
    JDBC API. JDO standardizes object databases and object/relational mappings for the Java programming
    language, allowing the programmer to use classes in the Java programming language instead of copying data
    between different data models.
        JDO is a suitable implementation for persistent helper classes for Session Beans, as delegate classes for
     Bean Managed Persistence Entity Beans, and for delegate classes for Container Managed Persistence (CMP)
     Entity Beans [JDO].
NET Database Connectivity Technologies
   ADO.NET - The .NET framework provides data and connection capabilities in the form of Active Data Object
    (ADO.NET). .NET introduces ADO.Net as the primary data access mechanism to access data in traditional
    database tables as well as other non-relation data sources.
         ADO.Net uses XML as the native data format and the data stored in datasets is internally represented as
     XML. Data can be passed to.NET applications from non .NET resources without using XMLDOM, SAX or
     XML parsers.
         Data sets provide disconnected data representations that can hold results from a variety of different sources.
         ADO.NET components factors out data access from data manipulation. There are two central components
     of ADO.NET that accomplish this: the DataSet, and the .NET data provider, which is a set of components
     including the Connection, Command, DataReader, and DataAdapter objects (Figure 37).

                                         Figure 37: ADO.NET Architecture

    Data sets allows the transport of data to clients over the Web using XML Web services, as well as the
    marshalling of data between .NET components using .NET Remoting services. Data sets also provide the
    ability to transmit results to and from a remote client or server in an open XML format, with the schema
    defined using the XML Schema definition language (XSD).
        Data adapters provide a bridge between data sets and the data source. A data adapter is used to populate a
    data set with results from a database, and to read changes out of a data set and resolve changes back to the
    database. Using a separate object (the data adapter), to communicate with the database allows the data set to
    remain generic with respect to the data it contains, and allows control over when and how commands are
    executed and changes are sent to the database [ADO.NET].

4.5     Data

                                                   Different Technologies
                Similar Technologies
                                                   J2EE                       .NET

                Various databases are supported    IBM Cloudscape             Microsoft SQL Server
                                            Table 6: Data Technologies

      The data aspects of J2EE and .NET concern supported structures located in the data dimension (component
                            architectures would have data dimensions on the resource tier in

Figure 1: Taken from [Herzum, Sims]). Many connection technologies can also be seen as a part of the resource tier
and its interaction with the enterprise tier (JDBC, JDO, and ADO.NET).


                 Figure 38: Data dimension on the Horizontal Continuum. Adopted from [Van Zylb]

The connection aspects of J2EE and .NET concern the technologies used to access and manage database connections
and connection technologies between other tiers for data transfer. These aspects are describes in section 4.5.1 and
4.5.2. This section focuses on databases.
    The range of databases supported by J2EE and .NET is large. A separation between two main types of databases:
     Driver supported databases
     Data sources other that SQL data

Databases require drivers to allow interpretation of results and communication as described in section 4.4.3. Open
Database Connectivity (ODBC) allows connection to any database supplier that provides a connection driver.

4.5.1   J2EE Databases
J2EE allows the addition of a range of database drivers to access a vast variety of databases and other data sources.
A database that is used with the reference implementation of J2EE is the relational database from IBM called
Cloudscape. Different vendors implement J2EE to construct enterprise level components, services and applications.
These application builder environments also include support for enterprise level databases.

4.5.2    .NET Databases
The main enterprise level database supported by .NET is Microsoft SQL server. The Microsoft operating system
provides a large driver database that can be used by the framework to access supported databases.

5    Summary
When examining the different sections (4.1 through 4.5), it becomes clear through the descriptions of the different
technologies that there are many similarities and differences between J2EE and the .NET framework.
   J2EE and .NET according to the continuum - The interface, interface controller, business logic, connection and
    data technologies of J2EE and the .NET framework are similar because many of the technologies provided, use
    the same protocols and communication patterns as well as implementation concepts.
         Differences between J2EE and .NET the two frameworks are more apparent when analyzing the
     categorization and distribution of technologies over n-tier applications and when viewed using the separation
     continuum. J2EE service architecture based technologies are APIs part of the specification, and .NET
     technologies are integrated into one large API.
   Service Based Architecture and Component Architecture Perspectives - As the industry is moving towards more
    loosely coupled technologies to increase interoperability, Service Based Architectures become more important.
    The structures on which these services are build (component and object oriented technologies) are also
    important and can be view in relation to services using the separation continuum. J2EE and .NET address
    connectivity and data encapsulation for the enterprise by providing both service architecture level connective
    technologies as well as technologies that inherently support the produced services.
   Vendor Tools - Many of the technologies presented in this paper require automation to effectively address time-
    to-market demands. Developer environments (BEA WebLogic and IBM WebSphere built on J2EE and
    Microsoft Visual Studio.NET built on the .NET framework) enable high level assembly and deployment of
    business solutions. The assembly and deployment includes the automation and integration the technologies
    using development tools.
   Evolution - Development environments and the technologies used within the environments evolve rapidly.
    Earlier editions of J2EE relied on extension packages to enhance J2EEs capabilities. Most of the extension
    features have been integrated into newer versions of J2EE, making J2EE and the .NET framework more alike.
    All networking and internet based technologies are part of the .NET framework.

In summary as can be seen from a technological perspective, J2EE and .NET each provide unique solutions to a
maturing distributed environment. Posing the question of what new technologies might emerge in the future, only
improvements on past experience and adoption of bleeding edge technologies will tell.

6   Table of Comparison

         User Interface Technologies

                                                                   Differing Technologies
         Shared Technologies
                                                                   J2EE            .NET
         HTML                                                      Swing / JFC     Web Forms
         XML                                                       Java Beans      Window Forms
         WML                                                       Applets         MFC
         DHTML                                                                     ActiveX

         User Interface Control Technologies

         J2EE                                          .NET

         Thin Client             Thick Client          Thin Client      Thick Client
         Servlets                JFC Applications      ASP.NET          MFC Applications
         JSP                     Applets                                Windows Forms
         JavaServer Faces

         Business Logic Technologies

         J2EE                                            .NET
         Enterprise Java Beans (EJB)                     COM and COM+ as Enterprise Services
         Java stored procedures                          Stored Procedures
         Servlets                                        MFC Applications
         JSP                                             Windows Forms
         JFC Applications                                ActiveX

         Data Technologies

                                                  Different Technologies
         Similar Technologies
                                                  J2EE                      .NET

         Various databases are supported          IBM Cloudscape            Microsoft SQL Server
         Connection Technologies

         Shared Technologies                                         Differing Technologies

         Connection Protocols:             Messaging Protocols:      J2EE              .NET
         HTTP                              SOAP                      JDBC              .NET
         TCP/IP                                                      RMI-IIOP          Remoting
                                                                     JNDI              DCOM
                                                                     JMS               MSMQ
                                                                     JCA               ADO.NET

7    References
[ADO.NET], .NET Framework Developer's Guide, Microsoft Visual Studio .NET: Enterprise Architect MSDN
distribution,                         ADO.NET                            Architecture.                       http://ms-
[ASP.NET Developer Guide], .NET Framework Developer's Guide, Introduction to ASP.NET. http://ms-
[Chappel, Kirk], Chappell D., Chappell & Associates. Kirk S., Microsoft Corporation. Application Design
Guidelines:                       From                        N-Tier                      to                     .NET.
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnbda/html/bdadotnetarch001.asp (last visited:
December 2002).
[Def                 ActiveX],               Supportive               definition               of            ActiveX.
http://searchwin2000.techtarget.com/sDefinition/0,,sid1_gci211521,00.html, web site: http://www.whatis.com (last
visited: December 2002).
[Def        API],      Supportive      definition      of     Application       Programming        Interface     (API).
http://searchwin2000.techtarget.com/sDefinition/0,,sid1_gci213778,00.html, web site: http:// www.whatis.com (last
visited: December 2002).
[Def DCOM], Supportive definition of Distributed Component Object Model (COM), DCOM.
http://searchvb.techtarget.com/sDefinition/0,,sid8_gci213883,00.html, web site: http://www.whatis.com (last visited:
December 2002).
[Def DHTML], Supportive definition of Distributed Hypertext Markup Language (DHTML).
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci212022,00.html, web site: http://www.whatis.com
(last visited: December 2002).
[Def         HTTP],         Supportive        definition        Hypertext        Transfer       Protocol      (HTTP).
http://searchsystemsmanagement.techtarget.com/sDefinition/0,,sid20_gci214004,00.html,                 web          site:
http://www.whatis.com (last visited: December 2002).
[Def ebXML] Electronic Business XML. http://searchcio.techtarget.com/sDefinition/0,,sid19_gci532347,00.html,
web site: http://www.whatis.com, (last visited: December 2002).
[Def        MFC],        Supportive       definition      of      Microsoft        Foundation       Class      Library.
http://searcwin2000.techtarget.com/sDefinition/0,,sid1_gci214094,00.html, web site: http://www.whatis.com (last
visited: December 2002.)
[Def       SOAP],       Supportive      definition     of     Simple      Object      Access      Protocol    (SOAP).
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214295,00.html, web site: http:// www.whatis.com
(last visited: December 2002).
[Def         TCP],        Supportive       definition      of       Transfer        Control       Protocol      (TCP).
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214172,00.html, web site: http:// www.whatis.com
(last visited: December 2002).
[Developer Guide - Overview], NET Framework Developer's Guide, Overview of the .NET Framework, Microsoft
Visual         Studio        .NET:        Enterprise       Architect        MSDN          Distribution.      http://ms-
[ebXML overview], ebXML, Technical Architecture Specification v1.0.4. web site: http://www.ebXML.org.
Document: ebTA.doc, http://www.ebxml.org/specs/index.htm#white_papers (last visited: December 2002).
[Enterprise       Services     COM+],       Enterprise     Services     and      COM+        in    .NET.     http://ms-
[ECMA-335], Standard ECMA-335. http://www.ecma.ch/ecma1/STAND/ecma-335.htm (last visited: December
[Farley],          Farley         J.,        Picking          a        winner:          J2EE          vs.        .NET.
http://www.sdmagazine.com/documents/s=733/sdm0103a/0103a.htm (last visited: December 2002).
[Herzum, Sims], Herzum P., Sims O., Business Component Factory: A comprehension Overview of Component
based development for the Enterprise. ISBN 0-471-32760-3.
[Java                                 Beans],                                 Java                              Beans.
http://developer.java.sun.com/developer/onlineTraining/Beans/Beans1/simpledefinition.html (last visited December
[Java Blueprints], Model-View-Controller Architecture. http://java.sun.com/blueprints/patterns/MVC-detailed.html
(last visited: December 2002).

[JavaServer Faces], J2EE Technologies: Java Server Faces. http://java.sun.com/j2ee/javaserverfaces/ (last visited:
December 2002).
[J2EE Overview], Java 2 Enterprise Edition Overview. http://java.sun.com/j2ee/overview.html (last visited:
December 2002).
[J2EE Tutorial], Stephanie Bodoff, Dale Green, Kim Haase, Eric Jendrock, Monica Pawlan, Beth Stearns. The
J2EE™ Tutorial. http://java.sun.com/j2ee/tutorial/1_3-fcs/ (last visited: December 2002).
[J2EE 1.4 Specification], J2EE 1.4 Specification Public draft. http://java.sun.com/j2ee/download.html#platformspec
(last visited: December 2002).
[JAX-RPC], Java API for XML based RPC (JAX-RPC). http://java.sun.com/xml/jaxrpc/primerarticle.html (last
visited: December 2002).
[JCA], J2EETM Connector Architecture, Specification Lead, J2EETM Connector Architecture.
http://java.sun.com/j2ee/connector/ (last visited: December 2002).
[JDBC],         The      JDBCTM        API         Universal     Data       Access        for    the       Enterprise.
http://java.sun.com/products/jdbc/overview.html (last visited: December 2002).
[JDO], Java Data Object (JDO). http://java.sun.com/products/jdbc/related.html (last visited: December 2002).
[JMS], Basic JMS API Concepts. http://java.sun.com/products/jms/tutorial/1_3_1-fcs/doc/basics.html#1023437 (last
visited: December 2002).
[JNDI], Executive Summary, JNDI Specification 1.2. ftp://ftp.javasoft.com/docs/j2se1.3/jndiexecsumm.pdf (last
visited: December 2002).
[JWSU – Haines] Java Web Services Unleashed, Chapter 12, 13. ISBN 0-672-32363
[JWSU – Morrison] Java Web Services Unleashed, Chapter 15. ISBN 0-672-32363
[Kassem], Kassem N., Designing Enterprise Applications with the Java™ 2 Platform, Enterprise Edition.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/ (last visited: December 2002).
[MSMQ],          White      Paper,     Message        Queuing      in      Windows        XP:     New       Features.
http://www.microsoft.com/msmq/default.htm (last visited: December 2002).
[MWC], The Middleware Company, J2EE vs. Microsoft.NET – A Comparison of building XML-based web
services. http://www.theserverside.com/resources/pdf/J2EE-vs-DotNET.pdf (last visited: December 2002).
[MS Remoting], Srinivasan P., An Introduction to Microsoft .NET Remoting Framework, Microsoft Corporation®.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp     (last    visited:
December 2002).
[MVC], The model-view-controller (MVC) design pattern, Computers Science Department, University of Indiana.
http://www.cs.indiana.edu/~cbaray/projects/mvc.html (last visited: December 2002).
[Pullara], Pullara S., Using XML and WAP with J2EE™ Technology, Senior Software Engineer, BEA Systems,
Inc.http://shannon.informatik.fh-wiesbaden.de/jsp/jsp/download/TS-841.pdf (last visited: December 2002).
[RMI-IIOP], Java TM RMI over IIOP. http://java.sun.com/products/rmi-iiop/index.html (last visited: December
[Sessions], Sessions, R., Final J2EE and .NET, Object Watch. http://www.objectwatch.com/our_position.htm (last
visited: December 2002).
[Stanhope], Stanhope, J., J2EE Connector Architecture Promises to Simplify Connection to Back-End Systems.
http://java.sun.com/j2ee/connector/giga/RPA-112000-00018.html, http://java.sun.com/j2ee/connector/ (last visited:
December 2002).
[Srinivasan], Srinivasan P., An Introduction to Microsoft .NET Remoting Framework, Microsoft Corporation.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp     (last    visited:
December 2002).
[SVG], Definition of Scalable Vector Graphics. http://www.xml.com/pub/a/2001/03/21/svg.html (last visited:
December 2002).
[Swing JFC], Java™ Foundation Classes. http://java.sun.com/products/jfc/ (last visited: December 2002).
[Ty], Ty, P., A comparison between J2EE/EJB and Microsoft .NET, Developer Evangelist - .NET and Developer
Group. www.microsoft.com/hk/msdn/download/msdn_011012.ppt (last visited: December 2002).
[Van Zyla], Van Zyl J., A perspective on service based architecture. http://www.jayvanzyl.com (under resources)
(last visited: December 2002).
[Van Zylb], Van Zyl J., Product Line Architecture and the Separation of Concerns. http://www.jayvanzyl.com
(under resources) (ast visited: December 2002).
[W3C WSDL], Word Wide Web Consortium, Web Service Description Language. http://www.w3.org/TR/wsdl (last
Visited: December 2002).

[W3C XSL], Word Wide Web Consortium - The Extensible Stylesheet Language (XSL).
http://www.w3c.org/Style/XSL/ (Last visited: December 2002).
[.NET              Mobile],         Microsoft          Mobile           Internet            Toolkit          1.0.
files/027/001/817/msdncompositedoc.xml (last visited: December 2002).
[.NET Remoting], .NET remoting overview, Microsoft Visual Studio .NET: Enterprise Architect MSDN
distribution. http://ms-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconnetremotingoverview.htm.
[.NET             Framework],         The         .NET          Framework              Product         Overview.
http://msdn.microsoft.com/netframework/productinfo/overview/default.asp (last visited: December 2002).
Appendix A       J2EE and .NET Configuration Specifications
   Sun’s Reference version of J2EE:
    Package includes:
    Java™ 2 Runtime Environment, Standard Edition, version 1.4.0.
    Java™ 2 Runtime Environment, Enterprise Edition, version 1.3.1.
    Jakarta Ant version 1.3 (http://jakarta.apache.org).
   Microsoft Visual Studio .NET
    Microsoft® Development Environment 2002, version 7.0.9466
    Enterprise Architect Edition
    Microsoft® .NET Framework 1.0 .3705
   Operating System
    Microsoft Windows XP
    Version 2002


To top