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 srf04001@engr.uconn.edu phil.griffith@gmail.com uconnfrank@yahoo.com

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

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.

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.

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.

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.

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

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.

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.

.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

Web Services Components 1 Directory Service Client 2 3. Web Service 4.

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.

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

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

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

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

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

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

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.

CORBA: Simple View

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.

CORBA Model with Database CORBA Referencing a Database.

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)

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.

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.

Questions? Any Questions?