1. Seth Freeman, Phil Griffith and Frank Manni
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

2. Outline of Presentation
Introduction
Project Changes
.NET Material
J2EE Material
CORBA Material
Experiments
Future Research

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

4. Project Scope Determine Components Involved.
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.

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

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

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

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

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

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

11. Web Services Components1
Directory Service
Client 2 3.
Web Service 4.

12. Web Service Components
1. Directory- Client Contacts a Directory Service Server (UDDI- 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.

13. 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 (JAX-RPC) to Support Cross Platform Communication

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

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

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

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

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

19. CORBA Overview Common Object Request Broker Architecture
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.

20. CORBA: Simple View

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

22. CORBA Model with Database
CORBA Referencing a Database.

23. 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)

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

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

26. Questions?
Any Questions?