J2EEPlatformsandMicrosoft007

Version 007-2/17/2003 (11:14 PM) SystemicLogic © 1
J2EE Platforms and Microsoft .NET
Technologies in Perspective
Cobus Smita
John Mullerb
Dr. Jay van Zylc Prof. Judith
Bishopd
a
Department of Computer Science, University of Pretoria, Pretoria 0002, South Africa, cobus.smit@cs.up.ac.za
b
Department of Computer Science, University of Pretoria, Pretoria 0002, South Africa, john.muller@cs.up.ac.za
c
Department of Computer Science, University of Pretoria, Pretoria 0002, South Africa, jay@systemiclogic.com
d
Department of Computer Science, University of Pretoria, Pretoria 0002
Abstract
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 im-
plementation 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 di-
mensions 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 archi-
tectures 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 docu-
ment currently focuses on the Sun Microsystems standard specification as described in Appendix A. The
technologies will be mapped to a separation continuum [45] 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 fo-
cus 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 indus-
try-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 [45] (section 3) requires a
clearer understanding of what each of the separate entities represent. This can be accomplished through ba-
sic definitions:
API - An Application Programming Interface is a mechanism that allows a programmer to program-
matically request a defined interface service from an application or library [5].
Framework - Frameworks (libraries) are designed for application by a wide range of programming lan-
guages 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 [16]

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 [37].
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 inter-
preted 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 con-
tains 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 [13].
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 iden-
tical when conceptualizing large solutions. Before introducing service based architecture, it is worth illus-
trating 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 [18]
User tier - The user tier is the visual representation of the business component. The user tier is respon-
sible 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 ena-
bling 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 ba-
sic 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 ap-
plications that are very different in nature [44]. The integration of these silos can be complex. Different lay-
ers 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 differ-
ent 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 [44]. Service based architecture
(SBA) [44] 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) [18]. When SBA is used, the
concept of deploying software to a specific infrastructure (as in CEE) is no longer required [44]. The SBA
does not attempt to replace the business component model, but rater place it in a SBA perspective.
Application
Clients
Dynamic
HTML
JSP/ASP.NET
Enterprise
Beans/COM
DatabaseDatabase
Enterprise
Beans/COM
Client
tier
Web Tier
Business
Tier
Information
System
Figure 2: J2EE Logic Tier Model

Service A
ProcessManager
Service B
Loose coupling
via standard
transport
technologies
Business Components consisting of
distributed components
Figure 3: Service Based Architecture, adopted from [44]
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 func-
tions required to provide the actual service are coupled via standard transport technologies. Service B illus-
trates 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 of this paper. Rather than venturing beyond the scope, it is more important to analyze the rela-
tionships between the tiers presented in
Figure 1: Taken from Figure 1 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).
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.”[44].
Figure 4: The Separation Continuum [44]

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:
? User interfaces (User tier) - This is the interface used by the user to interact with a system
? User interface controllers (User/Workspace Tier) - The controller manages the behavior of the inter-
faces that connect to the business logic layer.
? 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.
? Business logic (Workspace/Enterprise Tier) - Business logic refers to the ability to have a cluster of
services exposed to the user interface.
? Data (Resources and applicable tiers) - The data layer refers to the ability to reliably store data used in
the business logic layer [44].
The horizontal continuum and its elements are illustrated in Figure 5. As the continuum moves horizon-
tally 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 in-
terconnect the separate tiers. Not all tier interactions are applicable to every solution. Standalone applica-
tions and distributed architectures utilize the interconnections between the indicated tiers as best suited to
the business solution.
UI UIC BL DC
Figure 5: The horizontal continuum (adapted from [45])
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
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).
UI
Figure 6: The User Interface. Adopted from the [45]
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). [23]
and [2].
Client
Server
Browser
Shared UI Controller
Technologies
Logic
boundary
Mobile
Device
Other elements of
the horizontal
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.

UI
HTML
XML + XSL
WML
DHML
Figure 8: The User Interface. Adopted from [45]
4.1.2 J2EE Interface technologies
J2EE provides the following user interface technologies:
UI
Java Foundation
Classes
(AWT/Swing)
Applets
Java Beans
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 graph-
ics API without directly relying on the native windowing system. This is achieved by a Java Runtime Envi-
ronment (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) [42].
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 interchange-
able [19].
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:

UI
Window Forms
Microsoft
Foundation
Classes
ActiveX
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 (win-
dows, 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 [10]
ActiveX - An ActiveX control is an embeddable object that can be re-used by many application pro-
grams 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 Macin-
tosh 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 app-
let [4].

4.2 Interface Controller
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 gener-
ates/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).
UIC
Figure 11: The User Interface Controller in the Horizontal Continuum. Taken from [45]
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 pat-
tern implementations (MVC, MVC2). In the Model View Controller (MVC) the controller can be seen as
handling model state updates and view changes. [36] and [20].
User
Interface
View Interface
Controller
Model spanning
back-end tiers
Uses
Modifies
Update
s
Display
s
Figure 12: Graphic description of the User Interface Controller using MVC. Adopted from [36]
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.

V
M
C
Model and controller
technologies are provided
by servlets, JSP and
JavaServer facesHTML
Figure 13: Logic view of Model-View-Controller (Adopted from [34])
Two major separations can be made when considering, controller technologies – thin, thick and stand-
alone clients:
Thick Clients or Standalone
JFC/Swing - A thick client can make use of JFC/Swing applications to implement controller logic. Ap-
plets can be used in the browser environment, where the interface controller is embedded within the appli-
cation 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 con-
structs 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 [21].
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 pre-
sented 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:

V
M
C
Model and controller
technologies are
provided by ASP.NET.
HTML
Figure 14: Logic view of Model-View-Controller with .NET controller technologies. (Adopted from [34])
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 lan-
guage 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 inter-
face in standalone applications.
Thin client
ASP.NET Webforms - Webforms are constructs that are hosted on the server side of enterprise applica-
tions. Web forms can contain web or html controls. These controls can be run on the server and accord-
ingly 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 con-
cept. The interface controllers can also contain logic to ultimately access the business logic dimension of
the horizontal continuum.

4.3 Business Logic
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 [45]. The business logic includes core business as-
pects like business rules, validation and interaction among components. Business logic can also be imple-
mented on standalone applications that bypass the business tiers and communicate directly with the re-
source tier.
BL
Figure 15: Business Logic dimension in the Horizontal Continuum. Adopted from [45].
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 con-
tained 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 con-
cept is simplistically illustrated in Figure 16.
Enterprise Java
Beans
JSP, Servlets and
JavaServer Faces
Business
Logic
Business
Logic
(Optional)
Figure 16: Access of Business across logic Tiers. Adopted illustration using [34] and [45].

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 re-
lated operations through the EJB container illustrated in Figure 16.
Stored procedures - Stored procedures are procedures that could contain program flow, logic and que-
ries against databases. EJBs work tightly with the data dimension in the horizontal continuum and can dele-
gate logic to the data dimension.
4.3.2 .NET Business Logic
Several technologies exist that can be used to implement the business logic aspect within .NET applica-
tions. The Component Object Model (COM and COM+) is one such technology that defines the fundamen-
tal structure for technologies (using COM) to implement business logic. Certain interoperability and migra-
tion possibilities exist between .NET and COM+, enabling COM+ to function within the .NET environ-
ment. COM+ is called Enterprise Services within the .NET framework. The following business logic op-
tions 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 [3]. ASP.NET logic can access
business logic though Enterprise Services interoperability.
ASP.NET Enterprise
Services
Business
Logic through
assemblies
Business
Logic through
managed
components
Figure 17: Business Logic in the UIC and BL dimensions in .NET. Adopted from [44]
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) de-
scribed in section 1. Component Object Model (COM+) components that contain business functionality are
by nature unmanaged. To ensure interoperability, .NET requires Common Language Specification compli-

ance - 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. [15] and [37].
Stored Procedures - When considering business-logic implementation on the back-end tiers, stored pro-
cedure 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 busi-
ness logic [3].

4.4 Connections
Connections function like “glue” between different logical and physical distribution tiers. Figure 18 indi-
cates 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:
C
Figure 18: The Connections Dimension in the Horizontal Continuum [45]
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 con-
nection technologies are typically used between the business logic and data dimension as illustrated in the
horizontal continuum (Figure 5). Service Based Architectures (SBA) [44] 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) [45]. The connection technologies can be further subdivided using addi-
tional coupling categories:
? Tightly coupled connection technologies - This includes database and infrastructure connection tech-
nologies
? 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 [44]
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 gener-
ated from a browser environment where a request is built and sent over the Internet Protocol (IP) indicated
by Universal Resource Locaters (URLs) [7] The HTTP protocol is used to connect distributed clients (the
user interface dimension).
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 con-
trols 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 [12]. 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 20.
Server
HTTP
connection
Routed using
TCP/IP or
UDP/IP
Figure 20: HTTP using TCP/IP routing
Simple Object Access Protocol (SOAP) - SOAP can be described as a method of communication be-
tween 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. [11]. 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 [46] 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.
Organization A
J2EE
UDDI
Organization B
.NET
Services A Services B
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 sys-
tems 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 trans-
act 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 compa-
nies 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.

Figure 22: J2EE internet/web service connections [37]
ebXMLcompliant
system
Business Profiles
Business Scenarios
ebXML
Registry
XML
RequestBusinessDetails
1
BuildLocalSystem
Implementation
RegisterImplementationDetails
RegisterCOMPANYAProfile
3
2
5
AgreeonBusinessArrangement
4
Q
ueryaboutC
O
M
PA
N
Y
A
pro
file
D
ow
nload
S
cenariosand
P
rofiles
DO
BU
SIN
ESS
TR
A
N
SA
C
TIO
N
S
6
COMPANYA
COMPANYB
ebXMLcompliant
system
Business Profiles
Business Scenarios
ebXML
Registry
XML
1
BuildLocalSystem
Implementation
3
2
5
4
Q
ueryaboutC
O
M
PA
N
Y
A
pro
file
D
ow
nload
S
cenariosand
P
rofiles
DO
BU
SIN
ESS
TR
A
N
SA
C
TIO
N
S
6
COMPANYA
COMPANYB
ebXMLcompliant
system
Business Profiles
Business Scenarios
ebXML
Registry
XML
1
BuildLocalSystem
Implementation
3
2
5
4
Q
ueryaboutC
O
M
PA
N
Y
A
pro
file
D
ow
nload
S
cenariosand
P
rofiles
DO
BU
SIN
ESS
TR
A
N
SA
C
TIO
N
S
6
COMPANYA
COMPANYB
Figure 23: High level overview of the interaction of two companies conducting eBusiness using ebXML
(taken from [14]).
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 ar-
chitecture level communication.
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, de-
scribe and export a web service as an RPC based service. WSDL (described earlier) specifies an XML for-
mat 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 gen-
eration 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 [24]. JAXR eliminates the dependence of specific registry implementations [32].
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 con-
tain sufficient document type definitions (DTD), root and sub-elements as well as comments and process-
ing instructions (when more than one host is used in communications) [32].
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 [32].
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 [33].
.NET specific Internet and web service connection technologies
Figure 24 similarly explores internet and web service based connection technologies for .NET [37].

Figure 24: .NET Internet and Web Services Connection Technologies
Specific technologies inherent to the internet and web service connections for .NET basically include
BizTalk server.
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 extensions.
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 fo-
cuses 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) 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 [44]
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 im-
plementations which justifies describing the standard specification technologies only. The term server ex-
plained here refers to the underlying infrastructure that components exist in. J2EE server provides differs
containers for different type of software components. Figure 26Figure 25 illustrates J2EE container infra-
structures.
J2EE Server
Web Container EJB ContainerApplet
Container
Application
Container
Applets EJBs
Application
Client
Servlets,
JSP
Additional Container APIs
J2SE
Figure 26: J2EE Server and Containers. Adopted from [24]
As Figure 26 illustrates, J2EE Containers are built on the Java 2 Standard Edition (J2SE). The addi-
tional APIs in the separate containers enable J2EE functionality. The additional APIs will be described in
the context of component and inter-component connections.
IIOP (Internet Inter-Orb Protocol) - Applets are downloadable applications with JFC/Swing support.
Browser technologies normally use HTTP to connect, while standard application or applets can use IIOP.
IIOP is a connection protocol that enables different technologies (different programs constructed in differ-
ent programming languages) to communicate over the Internet. IIOP is part of an industry standard, the
Common Object Request Broker Architecture (CORBA) [8].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 Ob-
ject Request Broker Architecture (CORBA) distributed computing capabilities to J2EE. RMI over IIOP en-
ables 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 stan-
dard extension to the Java platform, providing Java technology-enabled applications with a unified inter-
face to multiple naming and directory services. As part of the Java Enterprise API set, JNDI enables seam-
less connectivity to heterogeneous enterprise naming and directory services.
Figure 27: JNDI taken from [31]
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 [31].
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 con-
nects 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 illustrates the basic JMS architecture. The JMS [30] application elements can be described as
follows:
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 Pub-
lish/Subscribe Messaging Domain.
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 mes-
sages 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 dy-
namically publish or subscribe to the content hierarchy. The system takes care of distributing the mes-
sages 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)

Message-driven Beans - Message-driven beans act as Java Messaging System (JMS) listeners that aid
J2EE application in asynchronous message processing. These messages can also be sent by any J2EE com-
ponent. A major difference between message-driven beans and session and entity beans is that message-
driven beans are not accessed via interfaces. Message-driven beans do resemble stateless session beans in
some regards. The main motivation behind using message-driven is asynchronous messaging [23].
Resource Adapters - Resource adapters are system-level software components [18] 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 imple-
menting 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) [24].
JCA (J2EE Connector Architecture)- The J2EE Connector architecture provides a solution of connec-
tivity 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.

.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.
Windows OS
.NET Framework
ASP.NET
Applications
Remote objects
IIS
Clients
Figure 32: IIS Server framework and .NET
Servers - .NET includes many Enterprise servers to enable communication with legacy and other sys-
tems. A brief description of these servers is given below:
? 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.
? Host Integration Server 2000 - provides access to selected legacy systems running on other platforms.
? BizTalk Server 2000 - is an XML-based collaborative e-business solution for integrating applications,
trading partners and business processes via the Internet.
.NET Remoting - .NET remoting can be simplistically described using Figure 33.
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 [41] .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 chan-
nel.

IIS
Client
Firewall
Remoting
Object
HTTP/S
OAP
Figure 34: .NET Remoting using HTTP/SOAP. Taken from [41]
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. Bi-
nary encoding can be used as an alternative.
IIS
Client
Firewall
Remoting
Object
TCP/
Binary
Figure 35: .NET Remoting using HTTP/SOAP. Taken from [41]
Typical .NET Remoting scenarios:
Client Server Payload Protocol
.NET Component .NET Component SOAP/XML HTTP
.NET Component .NET Component Binary TCP
Managed/
Unmanaged
.NET Web Services SOAP/XML HTTP
.NET Component
Unmanaged
Classic COM
Component
NDR
(Network Data
Representation)
DCOM
Unmanaged
Classic COM
Component
.NET Component
NDR DCOM
Table 1: Taken from [41]
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 [3]

Processing can be done on separate and more specialized servers using DCOM interfaces. DCOM inter-
faces 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 inter-
action) 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
[6].
MSMQ (Microsoft Message Queuing) - MSMQ enables applications running at different times to com-
municate 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 synchro-
nous scenarios [35].
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 pro-
vides 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 [28]
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 [28].
? 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 middle-
ware 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 proto-
col used directly by DBMSs, allowing a direct call from the client machine to the DBMS server and
providing a practical solution for intranet access.
JDO (Java Data Objects) - 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 [29].
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 compo-
nents of ADO.NET that accomplish this: the DataSet, and the .NET data provider, which is a set of compo-
nents 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 de-
fined 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 [1].

4.5 Data
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. 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).
D
Figure 38: Data dimension on the Horizontal Continuum. Adopted from [45]
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, ser-
vices 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 frame-
work.
J2EE and .NET according to the continuum - The interface, interface controller, business logic, connec-
tion 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 catego-
rization and distribution of technologies over n-tier applications and when viewed using the separation con-
tinuum. J2EE service architecture based technologies are APIs part of the specification, and .NET tech-
nologies are integrated into one large API.
Service Based Architecture and Component Architecture Perspectives - As the industry is moving to-
wards 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 technolo-
gies) 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 ad-
dress 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 de-
ployment 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 rap-
idly. Earlier editions of J2EE relied on extension packages to enhance J2EEs capabilities. Most of the ex-
tension 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 solu-
tions 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
XML
WML
DHTML
Swing / JFC
Java Beans
Applets
Web Forms
Window Forms
MFC
ActiveX
User Interface Control Technologies
J2EE .NET
Thin Client Thick Client Thin Client Thick Client
Servlets
JSP
JavaServer
Faces
JFC Applica-
tions
Applets
ASP.NET MFC Applica-
tions
Windows
Forms
Business Logic Technologies
J2EE .NET
Enterprise Java Beans (EJB)
Java stored procedures
Servlets
JSP
JFC Applications
Applets
COM and COM+ as Enterprise Services
Stored Procedures
MFC Applications
Windows Forms
ActiveX
Data Technologies
Different Technologies
Similar Technologies
J2EE .NET
Various databases are supported IBM Cloud-
scape
Microsoft SQL Server
Connection Technologies
Shared Technologies Differing Technologies
Connection
Protocols:
Messaging
Protocols:
J2EE .NET
HTTP
TCP/IP
SOAP JDBC
RMI-IIOP
JNDI
JMS
JCA
JAX-RPC
JDO
.NET Remoting
DCOM
MSMQ
ADO.NET

7 References
[1] [ADO.NET], .NET Framework Developer's Guide, Microsoft Visual Studio .NET: Enterprise Ar-
chitect MSDN distribution, ADO.NET Architecture.
http://mshelp://MS.VSCC/MS.MSDNVS/cpguide/html/cpconadonetarchitecture.htm.
[2] [ASP.NET Developer Guide], .NET Framework Developer's Guide, Introduction to ASP.NET.
http://ms-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconintroductiontoasp.htm
[3] [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=/li-
brary/enus/dnbda/html/bdadotnetarch001.asp (last visited: December 2002).
[4] [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).
[5] [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).
[6] [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).
[7] [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).
[8] [Def IIOP] Supportive definition of Internet Inter-ORB Protocol (IIOP).
http://whatis.techtarget.com/definition/0,,sid9_gci214019,00.html, web site:
http://www.whatis.com (last visited December 2002).
[9] [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).
[10][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.)
[11][Def SOAP], Supportive definition of Simple Object Access Protocol (SOAP).
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214295,00.html, web site: http://
[12][Def TCP], Supportive definition of Transfer Control Protocol (TCP).
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214172,00.html, web site: http://
[13][Developer Guide - Overview], NET Framework Developer's Guide, Overview of the .NET
Framework, Microsoft Visual Studio .NET: Enterprise Architect MSDN Distribution. http://ms-
help://MS.VSCC/MS.MSDNVS/cpguide/html/cpovrintroductiontonetframeworksdk.htm.
[14][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).
[15][Enterprise Services COM+], Enterprise Services and COM+ in .NET. http://ms-
help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconregisteringservicedcomponents.htm.
[16][ECMA-335], Standard ECMA-335. http://www.ecma.ch/ecma1/STAND/ecma-335.htm (last vis-
ited: December 2002).
[17][Farley], Farley J., Picking a winner: J2EE vs. .NET.
http://www.sdmagazine.com/documents/s=733/sdm0103a/0103a.htm (last visited: December
2002).
[18][Herzum, Sims], Herzum P., Sims O., Business Component Factory: A comprehension Overview
of Component based development for the Enterprise. ISBN 0-471-32760-3.
[19][Java Beans], Java Beans.
http://developer.java.sun.com/developer/onlineTraining/Beans/Beans1/simpledefinition.html (last
visited December 2002).

[20][Java Blueprints], Model-View-Controller Architecture.
http://java.sun.com/blueprints/patterns/MVC-detailed.html (last visited: December 2002).
[21][JavaServer Faces], J2EE Technologies: Java Server Faces.
http://java.sun.com/j2ee/javaserverfaces/ (last visited: December 2002).
[22][J2EE Overview], Java 2 Enterprise Edition Overview. http://java.sun.com/j2ee/overview.html
(last visited: December 2002).
[23][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).
[24][J2EE 1.4 Specification], J2EE 1.4 Specification Public draft.
http://java.sun.com/j2ee/download.html#platformspec (last visited: December 2002).
[25][JAX-RPC], Java API for XML based RPC (JAX-RPC).
http://java.sun.com/xml/jaxrpc/primerarticle.html (last visited: December 2002).
[26][JCA], J2EETM
Connector Architecture. http://java.sun.com/j2ee/connector/ (last visited: Decem-
ber 2002).
[27][JCA Sharma], Sharma R, J2EETM
Connector Architecture, Specification Lead,
http://www.darknight.com/dark/JCA/JCA_SUN.html (last visited December 2002).
[28][JDBC], The JDBCTM
API Universal Data Access for the Enterprise.
http://java.sun.com/products/jdbc/overview.html (last visited: December 2002).
[29][JDO], Java Data Object (JDO). http://java.sun.com/products/jdbc/related.html (last visited: De-
cember 2002).
[30][JMS], Basic JMS API Concepts. http://java.sun.com/products/jms/tutorial/1_3_1-
fcs/doc/basics.html#1023437 (last visited: December 2002).
[31][JNDI], Executive Summary, JNDI Specification 1.2.
ftp://ftp.javasoft.com/docs/j2se1.3/jndiexecsumm.pdf (last visited: December 2002).
[32][JWSU – Haines] Java Web Services Unleashed, Chapter 12, 13. ISBN 0-672-32363
[33][JWSU – Morrison] Java Web Services Unleashed, Chapter 15. ISBN 0-672-32363
[34][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).
[35][MSMQ], White Paper, Message Queuing in Windows XP: New Features.
http://www.microsoft.com/msmq/default.htm (last visited: December 2002).
[36][MVC], The model-view-controller (MVC) design pattern, Computers Science Department, Uni-
versity of Indiana. http://www.cs.indiana.edu/~cbaray/projects/mvc.html (last visited: December
2002).
[37][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 vis-
[38][RMI-IIOP], Java TM
RMI over IIOP. http://java.sun.com/products/rmi-iiop/index.html (last vis-
[39][Sessions], Sessions, R., Final J2EE and .NET, Object Watch.
http://www.objectwatch.com/our_position.htm (last visited: December 2002).
[40][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).
[41][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).
[42][Swing JFC], Java™ Foundation Classes. http://java.sun.com/products/jfc/ (last visited: December
2002).
[43][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).
[44][Van Zyla], Van Zyl J., A perspective on service based architecture. http://www.jayvanzyl.com
(under resources) (last visited: December 2002).

[45][Van Zylb], Van Zyl J., Product Line Architecture and the Separation of Concerns.
http://www.jayvanzyl.com (under resources) (ast visited: December 2002).
[46][W3C WSDL], Word Wide Web Consortium, Web Service Description Language.
http://www.w3.org/TR/wsdl (last Visited: December 2002).
[47][.NET Remoting], .NET remoting overview, Microsoft Visual Studio .NET: Enterprise Architect
MSDN distribution. http://ms-
help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconnetremotingoverview.htm.
[48][.NET Framework], The .NET Framework Product Overview.
http://msdn.microsoft.com/netframework/productinfo/overview/default.asp (last visited: Decem-
ber 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
Professional
Version 2002

J2EEPlatformsandMicrosoft007

More Related Content

What's hot

Viewers also liked

Similar to J2EEPlatformsandMicrosoft007

More from Jay van Zyl

J2EEPlatformsandMicrosoft007