Transcript DOCMT - University of Connecticut

Enterprise Component Comparison:
An Examination of J2EE, CORBA, and .NET
presented by
Seth Freeman, Phil Griffith and Frank Manni
Semester Project- Midterm Presentation
CSE333 – Distributed Component Systems (FALL 2005)
Instructor
Prof. Steven A. Demurjian
Department of Computer Science and Engineering
University of Connecticut
[email protected]
[email protected]
[email protected]
Enterprise Component Comparison--1
Outline of Presentation







Introduction
Project Changes
.NET Material
J2EE Material
CORBA Material
Experiments
Future Research
Enterprise Component Comparison--2
Project Description



Compare and Contrast the 3 Technologies J2EE,
.NET, and CORBA.
Evaluate the Three in These Four Areas:
 Database Connectivity
 Security
 Web Services
 Interoperability
GOAL: To Analyze Which Areas in J2EE or .NET
is Better Suited to Be Used for Application
Development. Also to Determine in Which Areas
CORBA Can Be Beneficial.
Enterprise Component Comparison--3
Project Scope

Database Connectivity




Determine Components Involved.
Examine the Underlying Functionality of
Establishing a Connection to a Database.
In the End We Will Also Compare the Performance
of J2EE and .NET in Updating and Querying a
Real World Database.
Web Services



Analyze the Techniques to Develop and Deploy
Web Services for the Three Technologies.
Observe the Ease of Use
Determine the Support of Each for Web Services.
Enterprise Component Comparison--4
Project Scope


Security
 The Goal Here is to Determine the Built-in
Capabilities of Authorization, Authentication, and
Encryption.
 Then Analyze the Functionality of These
Primitives Within the Framework.
Interoperability
 The Final Part of the Project is to Investigate the
Middleware Interoperability of .NET/J2EE
Components.
 More Specifically the Focus Will Be on Remote
Communication in .NET vs. RMI/RPC (J2EE).
 And Also Observe How Components Interact With
Heterogeneous Components.
Enterprise Component Comparison--5
Project Changes




Changed the Multi-threading Section to
Interoperability, Focusing on the Previously
Mentioned Concepts.
Updated the Database Interoperability Section to
Database Connectivity.
Added Experimentation to Database Connectivity
and Web Services.
Refined What We Are Examining for Security and
Web Services.
Enterprise Component Comparison--6
.NET Overview

The .NET Architecture is Very XML Oriented and is
Mostly Comprised of 2 Main Components.


Common Language Runtime (CLR)-Responsible for
Providing the Run Time Environment The CLR Consists of
Many Components Including the Garbage Collector, Class
Loader, Thread Support, Security Engine, Etc.
The Class Library Provides a Common Type System Shared
Among All of the Languages.

ADO.NET is the Interface That Allows for Database
Connectivity. The New Dataset Class Coupled With XML
is the Backbone for .NET Database Interaction.

The Language ASP.NET is Used to Develop Web Services.
In Addition .NET Contains Tools for Deploying and
Publishing Web Services.
Enterprise Component Comparison--7
ADO.NET Overview




ADO.NET is the New Database Technology of
the .NET Platform.
ADO is a Language Independent Model That is the
Major Benefit of Microsoft's Universal Data Access
Strategy.
.NET Includes Data Providers for Several Types of
Databases Including Oracle, OLE, and SQL Server.
The Underlying Technique of ADO.NET is the Dataset
Which Promotes a Disconnected Technique Where
Data Will be Represented in Local Memory.
Enterprise Component Comparison--8
ADO.NET –DataSet and other
Components

The DataAdapter is
Responsible for Filling in the
Data Set Object With Data and
Schema Information. The
DataAdapter Works in
Conjunction With the
DataReader Class to Fill the
DataSet Object.

The DataReader Class Can
Only Read From a Database.
The Object Contains One Row
of Data. Must Reconnect to
Get the Subsequent Rows.

The DataSet Is Broken Down
Into 2 Subcomponents the
DataTable Class and a
Collection of Relationships for
the Corresponding Tables.
Enterprise Component Comparison--9
.NET and Web Services



Microsoft Makes Use of XML (Over the SOAP and HTTP
Protocols) in its .NET Framework for Implementing Web
Services. The Main Reason is That With XML the Client
Does Not Need to Know the Language the Web Services
Are Implemented in.
The Client Just Needs to Know the Location and Available
Methods of the Web Service to Use It.
There Are 4 Components in the .Net Infrastructure That
Allow Clients to Find and Use Web Services.
 Directory
 Discovery
 Description
 Wire format
Enterprise Component Comparison--10
Web Services Components
1
Directory
Service
2
Client
3.
Web
Service
4.
Enterprise Component Comparison--11
Web Service Components




1. Directory- Client Contacts a Directory Service Server
(UDDI- http://uddi.microsoft.org). The Server Will Return
the URL of the Discovery Document of the Web Service.
2. Discovery- Uses the URL to Fetch the Discovery
Document of the Web Service. This is an XML Document
With Information About the Web Service Description.
3. Description- The Client Requests the Description
Document is a WSDL File Which Contains the SOAP
Format of Messages When the Client Wants to Call a
Method of the Web Service.
4. Wire Format- The Protocols Any System Will Know
Like HTTP and SOAP. This Allows the Communication to
Occur Between Both Sides of Any Type Since They Will
Know of Such Protocols.
Enterprise Component Comparison--12
J2EE Overview


J2SE consists of rich programming API running on
top of Java Virtual Machine
J2EE Extends J2SE by Adding Support for





Enterprise Java Beans
Server-side Components That Encapsulate the Business
Logic of an Application
Java Servlets
Java Programs That Extend Functionality of a Server
Java Server Pages
HTML Documents Embedded With Java Code
XML Technologies
Packages such as Java API for XML Processing (JAXP)
to Facilitate Transfer of Data
Web Services
Packages such as Java API for XML-based RPC (JAXRPC) to Support Cross Platform Communication
Enterprise Component Comparison--13
JDBC





J2EE Applications Interact With Databases
Through Java Database Connectivity (JDBC) API
JDBC Supports Four Types of Drivers
 JDBC-ODBC Bridge
 Native-API Partly Java Bridge
 JDBC-NET Pure Java Driver
 Native-protocol Pure Driver Java
Drivers Return a Connection Object Which
Represents a Connection to the Database
Statement Objects Contain Methods to Pass SQL
Statements to Database and Return Results
ResultSet Objects Contain the Results of SQL
Queries
 Scrollable, Updateable, Holdable
Enterprise Component Comparison--14
JDBC Features


Prepared Statements Objects Allow You to Send to
the Database SQL Commands That Contain
Placeholders (Variables)
 The Placeholders Must Be Set Before
Execution
 They Can Be Reset to Different Values
Transactions Ensure the Database Always Remains
in a Consistent State
 By Default, Each Statement Object is its Own
Transaction
 You Can Explicitly Handle Transaction
Management by commit and rollback Methods
 Savepoints in JDBC 3.0 Allow You to Save the
State at a Given Point, Which at a Later Point
the Database Can Be Rolled Back to
Enterprise Component Comparison--15
J2EE – Web Services




Web Services are created in J2EE using the
following:
 Java API for XML-based RPC (JAX-RPC)
 SOAP with Attachments API for Java (SAAJ)
 Java API for XML Registries (JAXP)
 Java API for XML Processing (JAXP)
JAX-RPC is the most commonly used
JAX-RPC is basically Java RMI over SOAP
JAX-RPC is used to
 Implement J2EE Web Service clients that can
connect to Web Service endpoints on other
platforms
 Implement Web Service endpoints for clients to
connect to
Enterprise Component Comparison--16
J2EE – Web Service Client




Three ways for a client to invoke a Web Services
methods are
 Static stubs
 Dynamic proxy
 Dynamic invocation interface (DII)
Static Stubs (Generated Stubs) are created at
development time
Dynamic Proxy – stub classes are created at
runtime
Dynamic Invocation Interface – Client can call web
services which it has no Service Definition
Interface or stubs
Enterprise Component Comparison--17
J2EE – Web Services Endpoint

JAX-RPC Defines Two Ways to Create J2EE Web
Service Endpoints
 JAX-RPC Endpoints
 Enterprise Java Beans (EJB) Endpoints

JAX-RPC Endpoints Are a Type of Java Servlet
That Have Been Adapted for Use As a Web
Services Component
 Easy to Implement
EJB Endpoint is an EJB Component That Provides
the Same Functionality of an EJB, but Is
Specifically Designed to Handle SOAP Requests
 Provides Large Amount of Functionality

Enterprise Component Comparison--18
CORBA Overview
Common Object Request Broker Architecture
1.
2.
3.
4.
5.
6.
Middleware That Facilities Communication Across
Different Software Platforms.
Object-Oriented — User Defines Objects and
Methods on Those Objects.
Objects Have Interfaces That Are Used to Directly
Reference the Object.
Object Request Broker (ORB) — Manages
Requests to the Various Objects.
Interface Definition Language (IDL) — Directions
on How to Reference an Object.
Stubs vs. Skeletons — Client Calls a Stub.
Skeletons Reference the Implementation.
Enterprise Component Comparison--19
CORBA: Simple View
Enterprise Component Comparison--20
CORBA and Databases



Generally, the Implementation of an Object in
CORBA is What Connects to a Database.
That Implementation Depends on What Platform
You Use (JDBC If You Use Java, ADO.NET If
You Use C#)
Databases Are Somewhat Irrelevant to CORBA
Itself — CORBA Applications Do Use Databases
But They Aren’t a Part of CORBA — They Are a
Part of the Object Itself.
Enterprise Component Comparison--21
CORBA Model with Database

CORBA Referencing a Database.
Enterprise Component Comparison--22
CORBA and Web Services


Merging the Two Has Become Straightforward:
 CORBA Manages the Implementations of the
Objects.
 Can Take an IDL and Define a WSDL From
it.
 Client Takes the WSDL, and is Ready to Go.
Some Backend Work That Needs to Be Done:
 SOAP is Text-based, Needs to Be Converted
Into Binary. (CORBA Uses Binary Messages)
 Certain Messages Can’t Be Sent Easily
Through CORBA (pdf documents, .doc, Etc)
Enterprise Component Comparison--23
CORBA vs. Web Services







But Which One is Better?
CORBA and Web Services Provide Similar Functionality.
Both Deal With Remote Methods Across Platforms.
CORBA Has Done What Web Services Does for Years.
But CORBA Can’t Easily Go Across the Internet. Web
Services Can and Do.
Web Services Data is Easy to Understand—text Based.
But Lots of Competing Protocols for Web Services?
Web Services Tend to Be Slower—need to Parse XML,
More Data to Send, Congestion at Port 80…
Need to Do More Research to Answer This Question…if
There is an Answer.
Enterprise Component Comparison--24
Future Work



Continue Our Research About Security and
Interoperability
More About Web Services vs. CORBA
Experimentation:
 Compare J2EE/.NET in Terms of Database
Performance and Web Services
 Compare CORBA Invocation With Web
Services Invocation for Performance
 Test Ease of Development for Security
 Remote Method Tests for All Three Platforms.
Enterprise Component Comparison--25
Questions?
Any Questions?
Enterprise Component Comparison--26