J2EE Platforms and Microsoft .NETTechnologies in Perspective

Cobus Smita John Mullerb Dr. Jay van Zylc Prof. Judith Bishopd

aDepartment of Computer Science, University of Pretoria, Pretoria 0002, South Africa, cobus.smit@cs.up.ac.za

bDepartment of Computer Science, University of Pretoria, Pretoria 0002, South Africa, john.muller@cs.up.ac.za

cDepartment of Computer Science, University of Pretoria, Pretoria 0002, South Africa, jay@systemiclogic.com

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

1

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:

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.

2

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 ap-plications that are very different in nature [Van Zyla]. The integration of these silos can be complex. Differ-ent 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 com-ponents. 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.

Figure 2: J2EE Logic Tier Model

3

Service A User Tier

Workspace Tier

Enterprise Tier

Resource Tier

User Tier

Workspace Tier

Enterprise Tier

Resource Tier

User Tier

Workspace

Enterprise

Resource

Proc

ess M

anag

er

Service B

Loose coupling via standard transport technologies

Business Components consisting of distributed components

User Tier

Workspace Tier

Enterprise Tier

Resource Tier

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 be-yond the 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 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 at -tributes 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

4

ii. User interface controllers (User/Workspace Tier) - The controller manages the behavior of the in-terfaces 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 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

D

C

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

Shared TechnologiesDiffering Technologies

J2EE .NET

HTMLXMLWMLDHTML

Swing / JFCJava BeansApplets

Web FormsWindow FormsMFCActiveX

5

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

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.

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

6

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:

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 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). [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:

7

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 frame-work 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 han-dling 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]

8

4.2 Interface Controller

J2EE .NET

Thin Client Thick Client Thin Client Thick Client

ServletsJSPJavaServer Faces

JFC ApplicationsApplets

ASP.NET MFC ApplicationsWindows Forms

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 pat -tern 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]

User

Interface

View Interface Controller

Model spanning back-end tiers

Uses

Modifies Update

s

Displays

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

9

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.

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

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

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:

10

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

11

4.3 Business Logic

J2EE .NET

Enterprise Java Beans (EJB)Java stored proceduresServletsJSPJFC ApplicationsApplets

COM and COM+ as Enterprise ServicesStored ProceduresMFC ApplicationsWindows FormsActiveX

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.

12

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

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

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.

13

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]

14

4.4 Connections

Shared Technologies Differing Technologies

Connection Protocols: Messaging Protocols: J2EE .NET

HTTPTCP/IP

SOAP JDBC RMI-IIOP JNDI JMS JCAJAX-RPCJDO

.NET RemotingDCOMMSMQADO.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 con-tained 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 tech-nologies

Loosely coupled connection technologies - This includes internet and web service based technologies.

15

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 applica-tion protocol. Web servers contain HTTP daemons that handle HTTP requests. Requests are com-monly generated from a browser environment where a request is built and sent over the Internet Proto-col (IP) indicated by Universal Resource Locaters (URLs). [Def HTTP]. 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 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 ex -changed by the application at each end have been exchanged. [Def TCP]. This is also a physical net-work transport protocol and can be considered the base on which all internet and web services connec-tions 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.

16

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.

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

17

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.

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

18

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

19

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]

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 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 focuses on preserving the exact semantics of the common language runtime,

20

and so is the best used when the remote system is also running the .NET Framework. ASP.NET fo -cuses 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 (), 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 Figure22 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.

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

21

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 - 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 con-structed in different programming languages) to communicate over the Internet. IIOP is part of an in-dustry 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 imple -ment 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 lan-guage. 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 in-terface 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 cre-ate, 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 tech-nology connects different systems via its messaging system.

Mechanisms provided allow binding of destinations and connection factories into a JNDI names-pace. JMS clients can look up administered objects and then establish a logical connection to the same objects through the JMS provider.

22

Figure 28: Taken from [JMS]

Figure 28 illustrates the basic JMS architecture. The JMS [JMS] application elements can be de-scribed as follows:

- A JMS provider is a messaging system that implements the JMS interfaces and provides ad-ministrative 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 es -tablished to hold their messages. Queues retain all messages sent to them until the messages are con-sumed 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 ap-plications clients address messages to a topic. Publishers and subscribers are generally anony-mous 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 sub-scribers. Topics retain messages only as long as it takes to distribute them to current subscribers (Figure 30)

23

Figure 30: Taken from [JMS]

Resource Adapters - Resource adapters are system-level software components [Herzum, Sims] that im-plements network connectivity to external resource managers. A resource adapter can extend the func-tionality 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. Re-source 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 connec-tivity between the many application servers and Enterprise Information Systems (EIS) already in exis-tence. JCA enables all vendors that conform to JCA to eliminate the creation of custom code when re -quired 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.

24

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

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

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

25

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.

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

Managed/Unmanaged

.NET Web Services SOAP/XML HTTP

.NET ComponentUnmanaged Classic COM Component

NDR (Network Data Representation)

DCOM

Unmanaged Classic COM Component

.NET Component NDR DCOM

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 pro-cessing and sends the result back to the caller of the procedure. Results can (depending on the struc -ture of the tier interaction) pass results to a client for viewing.

26

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 be-tween systems. [Def DCOM]

Microsoft Message Queuing (MSMQ) - MSMQ enables applications running at different times to com-municate across diverse networks and systems that may be temporarily offline. Applications send mes-sages to queues and read messages from queues. MSMQ provides guaranteed message delivery, rout -ing, security, and priority-based messaging. It can be used to implement solutions for both asynchro-nous 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 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 [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 net-work 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.

27

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 com-plementary 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 lan-guage 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 repre-sented 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 com-ponents 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].

28

4.5 Data

Similar TechnologiesDifferent Technologies

J2EE .NET

Various databases are supported IBM Cloudscape Microsoft SQL ServerTable 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 ). 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.

29

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, con-nection and data technologies of J2EE and the .NET framework are similar because many of the tech-nologies provided, use the same protocols and communication patterns as well as implementation con-cepts.

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 sep-aration 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 to-wards more loosely coupled technologies to increase interoperability, Service Based Architectures be-come 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 contin-uum. 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 deployment of business solutions. The assembly and deployment includes the automation and inte-gration 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 frame-work.

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.

30

6 Table of Comparison

User Interface Technologies

Shared TechnologiesDiffering Technologies

J2EE .NET

HTMLXMLWMLDHTML

Swing / JFCJava BeansApplets

Web FormsWindow FormsMFCActiveX

User Interface Control Technologies

J2EE .NET

Thin Client Thick Client Thin Client Thick Client

ServletsJSPJavaServer Faces

JFC ApplicationsApplets

ASP.NET MFC ApplicationsWindows Forms

Business Logic Technologies

J2EE .NET

Enterprise Java Beans (EJB)Java stored proceduresServletsJSPJFC ApplicationsApplets

COM and COM+ as Enterprise ServicesStored ProceduresMFC ApplicationsWindows FormsActiveX

Data Technologies

Similar TechnologiesDifferent Technologies

J2EE .NET

Various databases are supported IBM Cloudscape Microsoft SQL Server

Connection Technologies

Shared Technologies Differing Technologies

Connection Protocols: Messaging Protocols: J2EE .NET

HTTPTCP/IP

SOAP JDBC RMI-IIOP JNDI JMS JCAJAX-RPCJDO

.NET RemotingDCOMMSMQADO.NET

31

7 References

[ADO.NET], .NET Framework Developer's Guide, Microsoft Visual Studio .NET: Enterprise Architect MSDN distribution, ADO.NET Architecture. http://ms-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconadonetarchitecture.htm.[ASP.NET Developer Guide], .NET Framework Developer's Guide, Introduction to ASP.NET. http://ms-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconintroductiontoasp.htm[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-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpovrintroductiontonetframeworksdk.htm.[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-help://MS.VSCC/MS.MSDNVS/cpguide/html/cpconregisteringservicedcomponents.htm. [ECMA-335], Standard ECMA-335. http://www.ecma.ch/ecma1/STAND/ecma-335.htm (last visited: De-cember 2002).[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 Com-ponent 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 2002).

32

[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 Cor-poration®. 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 Sys-tems, 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: Decem-ber 2002).[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 Sys-tems. 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 Corpora-tion. 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 vis-ited: 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 De-veloper Group. www.microsoft.com/hk/msdn/download/msdn_011012.ppt (last visited: December 2002).

33

[Van Zyla], Van Zyl J., A perspective on service based architecture. http://www.jayvanzyl.com (under re-sources) (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. http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-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 .NETMicrosoft® Development Environment 2002, version 7.0.9466 Enterprise Architect EditionMicrosoft® .NET Framework 1.0 .3705

Operating SystemMicrosoft Windows XP ProfessionalVersion 2002

34